jump to navigation

FOSS4G2008 coming to the Southern Tip August 28, 2007

Posted by grimmeister in Geoinformatics.
add a comment

A couple of weeks ago, South Africa was awarded the Free and Open Source Software for Geospatial Conference for 2008. It will be hosted in Cape Town in September. This is really good news and, I feel, a bold decision from OSGEO. I believe, for the first time, they will be moving the conference away from the core developer community of FOSS4G.

However, the timing is great to bring it to SA because of rapidly increasing interest and investment in FOSS, driven by stated government policy to prioritise its usage. There seem to be three drivers for this: a perception of reduced cost; the importance of FOSS in bridging the ‘Digital Divide’; and FOSS’s role in increasing innovation and ICT literacy.

To me, the latter two are the themes that will enliven FOSS4G2008 in Cape Town, though there will without a doubt be much carping about costs. South Africa has a little bit of a tradition of innovation in the geoinformatics/ GIS space – off the top of my head I can point to Danie Krige of kriging fame, PlanetGIS and the ReGIS software, parts of which were later incorporated into Autodesk’s products. It would be interesting to know of other GI innovaters/innovations originating from SA.

The general reality on the ground in SA is the strong dominance of ESRI. This in and of itself is not a *bad thing* exactly, as the ESRI software is pretty darn good, but one effect has been the creation of a nation of ‘ArcView jockeys’, who know what buttons to press without necessarily understanding anything of what is happening under the hood. With exceptions, of course, it is really a mentality of “let ESRI understand what needs to be done and we will just buy the software/extension/script/service pack”. Convenient, yes; innovative, no; expensive, certainly – the dollar stretches a long way in SA. Well, hopefully FOSS4G2008 should help to perk up a few minds locally to the ocean of potential lying in the FOSS4G stacks.

As for the FOSS4G2008 overseas punters , well Cape Town is really rather nice. The effect of such a statement on a Capetonian is a bit like the effect of telling a Vancouverite the same thing. Cue spluttering indignation… Whatever. There will certainly be some interesting sights, sounds and experiences to be enjoyed. I hope it turns out to be a very hands-on, fun and enriching conference.



Two pairs of eyes August 14, 2007

Posted by grimmeister in Geoinformatics.
add a comment

I am writing some Python code using the OGR libary. It essentially ingests text files dropped onto a filesystem and turns them into features amongst other things. The data provided are x and y coordinates and some attributes. So, no problem, turn them into points. Trouble is, I needed to turn the points into square buffers of size 3km. I built a buffering routine but it was behaving oddly, generating buffers for all text files in a given directory on one pass, but only generating buffers for one text file on another pass. Eventually, the problem emerged: segmentation fault. I had been pulling my hair out for days trying to understand the problem.

The thing is, one gets commited to one’s code, trying to adjust it in tiny bits and pieces, rather than trying something new. This is where a second pair of eyes comes in. A second person overlooking your work does not have any emotional?? attachment to it and can happily suggest throwing code out and trying a new approach. End result: no more segmentation fault and a program that runs much more efficiently. Thanks Shriram!


More hair-pulling out! As my colleague Lee points out, if you want to know what is really going on in your code, don’t use wrappers! It took me hours to figure out that OGR (admittedly, a rather older version thereof), when used with its Python bindings, does not seem to enjoy having too many OGR objects used within a single method/routine. Thusly, in my method that ultimately buffers a point geometry and stores the new polygon geometry in a shapefile, I was unable to do a ‘contains’ test on the point geometry without getting weird and woolly segmentation faults and glibc double-linked list errors. This geometry test had to be done in a completely different part of the application.

Now, Lee suggested I rewrite the geometry testing code. The heresy of it!! I still like OGR and put it down to my own inexperience with the libraries. There is more chance of our *illustrious* President firing our unspeakable Health Minister than there is of me writing a usable geometry library. Those of you in the know about current SA politics will agree on the futility of it…


Setting up an Open Geospatial Consortium Service server August 8, 2007

Posted by grimmeister in Geoinformatics.


Our web server that we were using for OGC WFS and SOS decided to die on Monday – two disks in the RAID 5 array went to disk heaven (where I presume there is no I/O, after all, one does not expect to work in a heaven). We received this event with mixed emotions. All our services went down (big headache), but this was the long-needed opportunity to get off of Gentoo and on to Ubuntu. Gentoo is great, but the extra understanding and attention needed to maintain it is lacking in our workgroup. So, for better or for worse, it was decided to rebuild the server with Ubuntu Feisty, hoping that the extra attention that Ubuntu pays to Sun Java would pay off when it came to running Java-based webservices. While on the topicof ubuntu, I just love this xkcd irreverance:

xkcd genius again!

So, we got Ubuntu, Sun’s JDK 1.5 and Tomcat 5.5 installed easily. Of course, Tomcat did not immediately run. That would be too simple.

Enlisting the help of a few good websites (http://www.kintespace.com/rasxlog/?p=468;


http://ubuntuforums.org/showpost.php?p=2611681&postcount=1), I managed to get Tomcat grafting in a shortish time. This is significant, ‘cos I am clearly not what could be called a skilled sysadmin, and frankly, Tomcat fills me with fear 🙂

sun jdk
tomcat 5.5

1)Given that sun jdk installed, make sure its jvm is the default jvm
sudo update-alternatives --config java
choose the sun option

I also added the var JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun/ to the /etc/profile file but no idea if it has any useful effect

2)Tomcat is a bit quirky on Ubuntu

2.1)if not installed, do:
sudo apt-get install tomcat5.5 tomcat5.5-admin tomcat5.5-webapps

2.2)Configure Tomcat for the Java JDK. Edit /etc/default/tomcat5 uncommenting this line:

2.3)Set some permissions:
cd /var/lib/tomcat5.5/
sudo chown -R tomcat55:tomcat55 logs work
sudo chown tomcat55:tomcat55 /usr/share/tomcat5.5

2.4)Change service port to 8080 (default is 8180) in /etc/tomcat5.5/server.xml

2.5)Change the users and passwords for working with tomcat, tomcat admin and tomcat manager in /var/lib/tomcat5.5/conf/tomcat-users.xml
Advice seems to be to get a separate admin user with roles {admin, manager,tomcat}

2.6) Fix the catalina.out problem – it is trying to set the logfile as a pipe, rather make it a regular file to get tomcat to start
cd /var/log/tomcat5.5/
sudo rm catalina.out
sudo touch catalina.out
sudo chown tomcat55:nogroup catalina.out
sudo chmod uo-wrx catalina.out

/etc/init.d/tomcat5.5 start -> Tomcat now runs as a daemon

So, now to the OGC use cases!

1) We need to have the ability to serve OGC standard WFS, WMS and potentially WCS. We know the Geoserver tool, we like it, and dammit, I have just taken the time to install Tomcat, so sure as anything I am going to be using a servlet…

2) We need to serve Sensor Observation Service Offerings. There are now a number of implementations of the SOS, some richer than others at this early stage. We are familiar with the 52North SOS implementation and have worked with 52North developers on several occasions.

I’ll save my experiences with installing the SOS for another day, when I am feeling strong. Geoserver, however, is pretty easy to install and run.

1.1) Download the .war file in a zip file from the Geoserver website. We are using 1.5.1. Extract .war file

1.2) Deploy the .war file from the Tomcat Manager page. This will take place okay, but Geoserver will not be able to start, for Tomcat on Ubuntu is by default tightly locked down.

1.3) Follow the instructions at http://docs.codehaus.org/display/GEOSDOC/4+GeoServer+in+Production+Environment, which tell one to create a file called, in our case, ‘geoserver.policy’ in the /etc/tomcat-5.5/policy.d directory and populate it as follows:
grant codeBase "file:/var/lib/tomcat5.5/webapps/geoserver/WEB-INF/classes/-" {
permission java.security.AllPermission;
grant codeBase "file:/var/lib/tomcat5.5/webapps/geoserver/WEB-INF/lib/-" {
permission java.security.AllPermission;

This is supposed to get Geoserver working after Tomcat is restarted, but it does not. Instead a ServletException is thrown when one tries to access the Geoserver servlet. The key is to open the /etc/tomcat5.5/policy.d/04webapps.policy document and add a line to it granting looser security permissions:
permission java.security.AllPermission;

Then restart Tomcat and voila! the joys of Geoserver are yours to experience. I find the administration of Geoserver almost ridiculously intuitive once the servlet is running. It just takes a bit of time to set your spatial data hosting environment up