Exciting times for FOSSG

For those that know me you should know that i like to think i am impartial to geospatial solutions. I’m not a “fanboi” of opensource or commercial solutions … i really do tend to use the best available product. I have been getting the distinct impression lately that the quality and features starting to be developed in the OSGEO / FOSS4G realm is peaking particular interest in the commercial sector. More and more demonstrations i see by vendors are implementing some or all foss and customising it to their needs which is an interesting shift for the industry. Probably the most common project used in this respect is Openlayers. Just about everyone has used, touched, smelt or developed on OL and is really a testament to the hard work the contributors have put in (particularly the metacarta guys).

Take a look at some of the upcoming features in the stack. Anyone in the web mapping space has got to be excited about these …

  1. “Look into my lines” … AGG support in the new Mapserver 5.0 beta! Its incredible how much difference high quality antialiasing makes to web mapping applications. G/Y/M tiles raised the bar in that respect and Mapserver is certainly catching up to that quality. Mapnik is another choice, but is feature lacking in comparison.
  2. anti_aliased.gif


  3. DMSolutions Mapguide Fusion. Wow, such a powerful tool for deploying quick apps. It kinda reminds me how i felt after first seeing the ArcIMS website publisher, although obviously the similarities end there. Customising the old Mapguide clients was a fairly painful experience modifying 20 frames for the layout. Hoping Fusion improves this 10 fold.
  4. Geoserver‘s move to 1.6 adds the WFS1.1 implementation and GeoJSON output plugins. Although Deegree and Featureserver have offered these for a while, im always partial having a flexible single application rather than supporting multiple.

Now the hard part for me is deciding which one to start playing with first!

Geoserver testing ..

If you havent already heard, GS1.5 has been released and offers lots of little goodies hidden amongst the changelog. After lurking in the #geoserver channel picking up tidbits here and there i wanted to run some quick tests to confirm these magical WFS improvements. Refer to the following threads re: performance,

FYI, the test interface is php/Curl (local) -> geoserver 1.5 (local) -> ArcSDE (remote). Curl just allows finer control of the WFS POST requests


15k Cadastral features
Tomcat 5.5 + …

* JDK 1.4.2

ZIP: 40.33sec (775kb)
GML: 6.85sec (11.5mb)
GML-GZ: 24.52sec (618kb)


15k Cadastral features
Tomcat 5.5 + …

* JDK 1.4.2

ZIP: 36.43sec (775kb)
GML: 6.52sec (11.5mb)
GML-GZ: 24.11sec (618kb)

* JDK 1.6u1

ZIP: 34.31sec (775kb)
GML: 5.88sec (12.0mb)
GML-GZ: 19.32sec (618kb)


Unfortunately i did not see a significant improvement in my testing of both the JDK and new Service strategies. Perhaps the bottleneck is in the I/O to the SDE datastore and not Geoserver itself. No time to test further on local datastores, but i promise i’ll post a followup comment with these later…

Whats surprising is the time required to create the zip’s. Everyone knows there is a cost involved with saving and writing the zip (instead of streaming the gml) but i didnt realise it was that much. Its a shame GML is not as common place as the old shapefile otherwise i would certainly be pushing gml2-gzip or even better, native “accept-encoding: gzip” headers when requesting GML2 output to the containers. In my experience as soon as you tell anyone that you can output a shapefile from Geoserver WFS, you can forget them ever considering GML again. These numbers may sway some of them at least

Further testing to come ..