Flame Bait

Why end the evening on a high note, when I can end it rancourously and full of bile!

On the postgis-users mailing list, Stephen Woodbridge writes:

Can you describe what dynamic segmentation is? What is the algorithm? I guess I can google for it ...

As with many things, the terminological environment has been muddied by the conflation of specific ESRI terms for particular features with generic terms for the similar things. Call it the "Chesterfield effect".

• ESRI "Dynamic segmentation" is really just "linear referencing of vectors and associated attributes".
  
• ESRI "Geodatabase" is "a database with a bunch of extra tables defined by and understood almost exclusively by ESRI"
  
• ESRI "Coverage" is a "vector topology that covers an area" (ever wonder why the OGC Web Coverage Server specification is about delivering raster data, not vector topologies? because most people have a different understanding of the word than us GIS brainwashees).
  
• ESRI "Topology" is a "middleware enforcement of spatial relationship rules"
  

ESRI rules the intellectual world of GIS people so thoroughly that they define the very limits of the possible. Just last week someone told me "oh, editing features over the web? the only way to do that is with ArcServer".

The only way, and said with complete certainty. You don't want to argue with people like that, it seems almost rude, like arguing with people about religion.

Tiles Tiles Tiles

One of the oddball tasks I came home from the FOSS4G conference with was the job of writing the first draft of a tiling specification. My particular remit was to do a server capable of handling arbitrary projections and scale sets, which made for an interesting design decision: to extend WMS or not?

I mulled it over at the conference, and talked to some of the luminaries like Paul Spencer and Allan Doyle. My concern was that the amound of alteration required to WMS in order to support the arbitrary projections and scales was such that there was not much benefit remaining in using the WMS standard in the first place -- existing servers wouldn't be able to implement, and existing clients wouldn't be able to benefit.

On top of that, a number of the client writers wanted something a little more "tiley" in their specification than WMS. Rather than requests in coordinate space, they wanted requests in tile space: "give me tile [4,5]!"

So, I originally set off to write either a GetTile in WMS or a Tile Server using the Open Web Services baseline from the Open Geospatial Consortium.

But then I had an Intellectual Experience, which came from reading Sean Gillies' blog on REST web services, and his thoughts on how Web Feature Server (WFS) could have been implemented more attractively as a REST interface. I was drawn in by the Abstract Beauty of the whole concept.

So I threw away the half-page of OWS boiler-plate I had started with and began anew, thinking about the tiling problem as a problem of exposing "resources" ala REST.

The result is the Tile Map Service specification, and no, it is not really all that RESTful. That's because tiles themselves are really boring resources, and completely cataloguing a discovery path from root resource to individual tile would add a lot of scruft to the specification that client writers would never use. So I didn't.

That was the general guiding principle I tried to apply during the process -- what information can client writers use. Rather than writing for an abstract entity, I tried to think of the poor schmuck who would have to write a client for the thing and aim the content at him.

I have put up a reference server at http://mapserver.refractions.net/cgi-bin/tms and there are other servers referenced in the document. My colleague Jody Garnett is working on a client implementation in Java for the GeoTools library, for exposure in the uDig interface. Folks from OpenLayers and WorldKit have already built reference clients. It has been great fun!