Charlie Savage writes:

In my view, the fundamental premise of GML is wrong. The ability to create custom data models is an anti-feature that makes integration between different computer systems impossible because it assumes that those systems can actually understand the data.

I read, in a very recent GeoRSS mailing list thread, the assertion that GML is the lingua franca of geospatial information on the Web. It's just not true anymore, if it ever was.

Update: Bryan Lawrence has a rebuttal.

Tom Kralidis points us to a new book, and I was struck by how few of the authors I know by name. Am I not getting out enough, or are these folks not taking their ideas to the web like they should?

MapServer revision 6064 (my first contribution in quite a while) has an example of loading a mapfile from a string: fragments.txt. We're getting very close to the point where we can practically stop using mapscript. Users, feel free to add comments to this feature's story.

I just finished one the most challenging and rewarding 8 days of my life as the single parent of an 18 month-old. Whew. Single moms and dads of the world, I salute you!

I too think so. Dear geospatial community, please do not propose yet another special protocol until you can demonstrate that Atom won't work.

In a discussion of restful features the other day, a good question came up: where's the back button? POST and PUT are easy to understand, but how about rolling back or undoing changes? I have a simple solution which is going to look pretty familiar to Subversion users.

Let's beginning by modifying a feature:

PUT /features/1
{ ... }

The curly braces and ellipsis stand in for a JSON object, the details of which aren't important now. From a versioning feature resource, I'd want to get a response like:

200 OK
feature: http://example.org/features/1
revision: http://example.org/features/1/revisions/1

Representations of the feature and its most recent revision are identical. Want to rollback this change? First, let's get the previous revision:

GET /features/1/revisions/0
{ ... // revision 0 }

and then put it back:

PUT /features/1
{ ... // revision 0 }

With the response:

200 OK
feature: http://example.org/features/1
revision: http://example.org/features/1/revisions/2

That's the restful equivalent of:

$ svn merge -r 1:0 http://example.org/features
$ svn commit

OSM, by the way, has node history, but no URIs for node revisions.

I've just been hand-waving, but Chris Holmes is getting ready to blaze a trail for GeoServer from WFS to restful features. He, more than anyone, has clued me into the significance of paging links for GIS applications, and his post has a good introduction to the concept.

Feature paging should let us reduce the latency in some web GIS applications. Break a huge query response -- and I've seen the GeoServer bloggers mention gigabytes of GML -- into chunks of N (hundreds? thousands?) features, and you can render or analyze chunk i while chunk i+1 is coming through the intertubes.

Paging helps on the server end as well. An intriguing MapServer development proposal to allow XSL transformation of outgoing features was just ditched because WFS doesn't accomodate chunked responses, and it seemed too expensive and slow to build and transform an entire, potentially huge XML document before even beginning to send it. XSLT of reasonably-sized chunks, each with a link to the next, is rather more feasible.

The only thing in Chris's post that I'll dispute is his exaggeration of my credentials. I'm just an HTTP enthusiast, but I do see a huge potential for REST in the geospatial community and I'd like to help realize it.

Christopher Schmidt is exactly right:

(Note that I did this before I even saw posts about it -- I think this is just more evidence that all the things we're talking about here are well understood and not novel, though it is interesting that we're all implementing them at the same time.)

Being the first geospatial project to jump on an already filling bandwagon, 6-7 years after the publication of RFC 2616, is really no big deal. The interesting question is why it took us (the industry and community) so long. Personally, I didn't get what REST was about until I started reading about atompub and Rails.