Bravo .. Sebastian’s post. You made me chuckle and i don’t really know why :) I had actually not seen the projection render call, that is damn nice work Chris and Howard. Sebastian lists a few suggested improvements to the “service” which i whole heartedly agree. Geodesy/datums/projections/geoids/coordinate systems need not be some magical black art done only by PhD’s, or alternatively some magical program that you insert numbers in, get stuff out, but having no idea what just happened. Let there be light …

Second bravo goes to Flamingo mapping components, a new (i think) dutch GPL mapviewer. I happened to stumble onto these guys’ Flash based WMS client the other day and all i can say is hooray! Finally a flash client which is separated into components, has a neat interface and is actually configurable WITHOUT requiring Flash CS3 just to change the stupid service URI.

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!

From the other side of the fence …

Like all good arguments, there are other sides. In what seems to be a two part OGC mini-series on Charlie Savage’s blog RE: problems with the OGC, I noticed a comment by Shane asking …

I’m surprised at the lack of outburst by the pro-standards community. This makes me think they are humbled by your views. I’d expect somebody out there to stick up for OGC and the other standards you mentioned. It would be intriguing to hear someone from DM Solutions or Ionic, for instance.

Even though i am not Ionic, DMsolutions … here are some thoughts from someone who thinks the OGC has created some pretty darned useful standards.

A retort to one of Charlie’s post if you will .. :)

Rendering Maps. The argument i often see with the WMS bashing goes something like, “WMS is slow. Who uses it in an Enterprise architecture. G/Y/M dont use it, therefore by my intelligent calculations, WMS must be useless”. Lets back up a second. If you want a high performance, slippy interface that can be easily cached, tiling is certainly your best bet. I get the distinct feeling that a lot of people forget the disadvantages of a tiled mapping cache,

  1. Fixed scales. The amount of people i see who simply generate their zoom levels based on GMaps is crazy. What about what your users want? If there are any papers detailing why splitting the world into 18 distinct zoom levels is ideal, please tell me. I’m yet to find one. One size will never fit all.
  2. Redundant data storage. Active caching mechanisms whereby caches are only populated once browsed is nifty, but it also negates somewhat the advantage of using a cache. Conversely, if you pregenerate your entire cache you are more than likely storing 80% (number plucked from the sky) more data than you need. We also arent even touching the storage of the source data either here, or considering the time required to maintain the cache when you are using volatile datasets.
  3. Lack of integration across clients. The whole benefit of standards it to enable cross-use, cross-communication amongst clients and servers. This is non evident amongst tile servers (beyond of course worldkit and openlayers). Sure, WMS-C / TMS are hopefully gathering steam at the moment, but if you are considering integration right now across a gamut of applications, nothing is better than WMS for transferring maps over the interweb to multiple clients. People seem to be losing sight of this purpose every day.
  4. And the kicker for me … Absolutely no customisation. Dont want that road layer? You better hope they duplicated the cache and removed them otherwise you’re in trouble. Want the map in a useful cartographic projection? Duplicate again! Hmmm, can you colour the cadastre yellow instead of red? No, but i can duplicate the cache again for you. I could go on, but you should get the idea ..

And finally, “Arbitrary bounding boxes” are your friends Mr Charlie! Let your users decide their output scale, not the magical we-chose-18-scales-coz-google-wanted-a-nice-single-square-tile-at-zoom-level-0 :)

Summing up, WMS is your friend regardless. Don’t toss it out with the bathwater just because you are using a cache with a slippy map. Implementing WMS and whatever tiling scheme you can easily abstract *AROUND* WMS will give you and your users the best of both worlds. The fact that you can quite easily use any random WMS server inside a tiling scheme surely highlights that the standard does have flexibility.

Time is at a premium at the moment so i wont reply to all Charlie’s points (especially sharing data because we could be here forever). All in all i can see his point of view however we need to remember that we can only work with what we have at the moment, despite their flaws. GeoRSS/Atom/OWS Context/KML ratifying are all coming, its just up to the rest of us to pick up the ball and keep running with it so this will never be true again,

Web mapping standards are going through a transitional state and haven’t kept up with GIS technology breakthroughs over the last few years.


WFS Feature paging … yes please

Sean posted his thoughts in response to Chris’ and all i can say is, yes please!

My random thoughts,

  • Why this functionality was never embedded into WFS i will never know. After playing with CSW for the last 6 months where similar “pagination” is available … it just makes sense. How the average Jo Blogs will ever understand what maxFeatures should be set to is irrelevant if the user cannot even determine how many *total* features are available given his query. OGC CS-W handles this quite nicely, almost identical to how Chris H. described it. If i search for “hydro”, it will give me a numberOfRecordsMatched=”340″ but then also tell me that i’m just viewing the first 10 records.
  • Paging has been linked to server performance, particularly caching a set number of features. This imo, would only hold true if the given features are retrieved in the same manner. How this would handle filters i’m a little unsure of (beyond the simple bbox). Just because search engines index doesn’t mean that the same features will appear in the same page 10 days later, for example. Checksum? HTTP Last-modified? *shrug*

Looks like i need to pay more attention to the OGC boards :)

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 ..