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!

MapServer users: you all owe Howard a beer.

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.

When considering the commoditization of GIS software, you can't ignore the impact of the open source movement. The MapServer user and developer community accelerated the cycle and tipped web mapping towards commodity status even before Google Maps landed.

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.

body_html_template

Raj Singh is working hard on WFS Simple, but I think it is still going to miss the "mass market" boat by a few steps.

Goodwill towards XSD is almost gone, for good reasons, and probably won't be coming back. XML Schemas will hinder adoption of WFS Simple.

We're only just beginning to see RPC-style services fall out of favor. Web architects and developers are more and more interested in RESTful APIs like the Atom Publishing Protocol than they are in SOAP lite. The OSM API, the OSGeo Tile Map Service, and MetaCarta's FeatureServer are only some of the first functional examples of the RESTful, web-friendly, geo services of the future. This is where we're headed. Eventually, WxS will be used almost solely for interoperation with legacy GIS applications.

By the way, I also still think the "mass market" term smacks too much of GIS elitism and exceptionalism. The geospatial industry and communities have a lot to learn from the Web and IT.