Today I am stepping outside of my happy little comfort zone of programming. Why you ask? I am setting up a server for the FOSS4G conference; so I can write some workshop/tutorial material. Having data services available is going to be very important at this year’s FOSS4G conference; just like in South Africa international visitors will find that connectivity to other continents can be slow.
This year data services are being handled as part of a wider “Climate Change Integration Plugfest” project that the Open Geospatial Consortium (OGC) is organizing for the event (and other events).
Data
Mark Leslie has been kindly bashing his head against VMware; and has installed an experimental version of PostGIS for me to work against. Setting up GeoServer and MapServer on this machine is the next step.
Because this is going to be a public showcase; and PostGIS implements an OGC standard here are the connection details (for read-only access as shown below – use the credentials readonly/readonly):
Mark has loaded up some example datasets from GeoScience Australia:
And Open Street Maps:
(The Australian Bureau of Meteorology data is mostly raster so we will need to cover that when we set up GeoServer in a later blog post).
Mark has gone above and beyond the call and duty; for details on these datasets please see the table description. This is so rare that one of the first things I am going to have to do is patch uDig to show me the table descriptions.
Documentation
One of the first steps to take when stepping out of your comfort zone is a quick search; looking for docs and so on.
I was able to find this: GeoServer in Production Environment
The second step is to check the date of the documentation; in this case Chris had made a change on Feburary 11th which sounds recent enough to trust.
Developers
The third step was to jump on the IRC channel and let people know what I was up to; in order to tease out any "gotcahs" that only the developers (or email list) know about.
Our happy GeoWebCache maven "arneke" was able to point out two bits of wisdom:
do not trust the tomcat that comes with the distribution; you should download your own tomcat; or
"configure it" the default tomcat to work
In this case configure it refers to the following bug report: GEOS-1567
And the easiest workaround in the list is to edit the webapps policy.d file and add the following line: “permission java.security.AllPermission;” This line grants geoserver the same permissions as a desktop application allowing it to check environmental variables (it uses this to locate the geoserver data directory where all the configuration information is stored).
Leasons Learned – use Tomcat Manager
Next up for me is the question; where do I drop the war? This is the kind of "basic" question that is hard for documentation to answer - since they assume you know that part already.
In Tomcat on windows (or indeed many application servers) there is a webapps folder you can drop your war into and it will be unpacked and executed.
In debian there were three candidate locations:
/etc/tomcat6 - this is where the configuration on logging settings are kept; no sign of a webapps folder
/var/lib/tomcat6/webapps - this has a single entry "ROOT"
/usr/share/tomcat6/webapps
So what is going on? It looks like they are separating out the application container; from the various web applications.
Andrea recommended using /var for external data directory. It was at this point that I found the War-File install page. And then a series of good blog posts:
These blog posts seem to be serving as unofficial documentation on the subject right now.
Turns out the answer to my question was - to use the Tomcat Web Applicaiton Manager; which will unpack things ... into /var/lib/tomcat6.
And a bit of Work
Tomorrow I will talk about configuring GeoServer; you can learn about the dangers of uding an Experimental PostGIS; and I will let you know where you can try out the final result.
No comments:
Post a Comment