Update (2007-09-20): Hammock is evolving.

Update (2007-04-13): coordinates attribute has been reformatted from [x, y] to [[x, y]] to keep up with the evolving GeoJSON RFC. If you're curious about the source code, see the following post.

This evening I cobbled together a demo of a feature service inspired by Joe Gregorio's Robaccia. It's a toy model of something not unlike a RESTful WFS-T, based on the Python wsgiref, selector, elementtree, and simplejson packages.

The root resource is at http://sgillies.net:8081/features, and the default view is a JSON array of links to objects. (Note: Douglas Crockford has proposed the application/json content type, and I've only used text/plain here to make it easier for people to follow the links in their browsers.) The URLs http://sgillies.net:8081/features.atom and http://sgillies.net:8081/features.kml return GeoRSS (Atom) and KML representations respectively.

Over the course of several images, I'm going to walk through the process of getting representations of feature resources, and posting new resources to the system.

The first image shows all the features in the system as seen using KML in Google Maps [link]. More features may have been posted to the system by the time you click on that link, so you may see more points. It's also possible that these particular features here may have popped off, as I've capped the number of features in the system at 30. Like I said, it's just a toy. Only 288 lines of Python.

Now, fire up your RESTful feature service client, and follow my instructions to add a new feature to the system. You've probably got several such clients on your system already. My favorite is good ole vim. Seriously.

You can obtain a representation of any of the system's features by reading the output of a curl command into an empty buffer:

:r ! curl -s --url http://sgillies.net:8081/features/1

The -s option prevents capture of download rate stats. Use any feature URI that you find in http://sgillies.net:8081/features. The resulting JSON text will be a template for a new feature.

Edit the coordinates (this toy service is currently restricted to points), title, and summary. Any value you provide for id will be overridden, as will any timestamps.

Now, post this data to the features resource by piping the buffer contents back through curl:

:% ! curl -s --url http://sgillies.net:8081/features -d @-

If you typed carefully, you'll get a result like:

Go ahead and browse to the resultant URL and admire the shiny new feature.

Reload the Google Maps page, and you'll see be able to see your new feature. If you're a careful typist, do play around with this as much as you want. I'll keep the service running as much as I can, though the features may come and go. If need be, I'll apply my blog comment policy to features posted by visitors and delete any obnoxious crap.

With luck, I'll add the capability to PUT and DELETE features next week.

I'll continue to tweak this toy and use it to explore Pleiades use cases: posting KML files created with Google Earth (would be nice to do it directly), and creating new features via GE and WebDAV are a few of the things we're looking at. Vim as a feature service client is fun for a while, but gets old quickly, and is a harrowing experiencing for a non-hacker. Still, the fact that you can use vim shows the enormous potential flexibility of this kind of system architecture.

GeoDRM proponents have argued the necessity of geospatial digital rights management partly by analogy to the entertainment industry. So, it seems that Apple, Microsoft, and their digital music partners pulling out of DRM also pulls the rug out from under GeoDRM. Geodata users don't want digital rights management any more than do users of digital music. Does this mean the end for GeoDRM? Maybe yes, and maybe no (Mark Shuttleworth):

There are some ideas that are broken, but attractive enough to some people that they are doomed to be tried again and again.

On the other hand, work on rights expression is useful to all of us, and even more so in the light of recent revelations that Creative Commons doesn't want to get into the geodata business.

Update (2008-01-21): See http://pypi.python.org/pypi/Shapely/1.0.

An older, slightly outdated, post of mine about Python geometry packages is getting read enough to warrant an update.

Geometries from mapscript.py and ogr.py haven't changed in the past year. The GeoDjango developers are finding that the geometry API in geos.py isn't so bad -- perhaps because they're doing the bulk of their operations and transforms within the database -- but the fact remains that the GEOS project is trying to deprecate use of the C++ API, and that this puts geos.py in some peril.

Since the Python Cartographic Library's 0.11 release, geometries are now a part of the PCL-Core component's cartography.geometry package. Howard Butler added pickle support, and we've fixed a number of bugs since the start of 2006. We've also reduced the dependencies of PCL-Core, as you can see in INSTALL.txt. Remember, "zope" is now a namespace package, and you can install zope.interface [Cheeseshop] separately from any other piece of Zope 3.

I have nothing to report about FDO's brand new geometries for Python. My understanding is that they are also based on GEOS.

Sam Ruby is using GeoRSS, and the emergence of new feed based applications from Google and Microsoft, as an example of what non-elite web programmers can accomplish without XML schemas (or SOAP). The uptake of GeoRSS (and RSS more generally) demonstrates once again how worse is often better. People are typically generating GeoRSS feeds using tools that are completely ignorant of XML Schema, validating them via web sites, and processing fetched feeds using the DOM or XPath capabilities of their browser's JavaScript engine (GeoRSS.js). That the Geo-Web is forming out of GeoRSS and KML -- initially released without a schema -- rather than GML is yet another indictment against XSD.

The James Clark post to which Ruby replies is also a good read. Something like TEDI would come in handy at times, maybe even for the Python feature protocol I'm working on.

For the FOSS4G 2007 organizers: wireless lessons from PyCons 2006 and 2007.

Update (2007-06-04): More search help, but no details, from Google.

Update: Paul Ramsey reports that the game-changing impact of spatial search was brought up in the CalGIS conference keynote.

Ed Parsons, a few weeks ago, was befuddled by the GIS industry's almost-imperceptible response to Google's spatial search news. There hasn't been any new tide of interest since, and there are 3 primary reasons.

First and foremost, there's no public API for the spatial search, and no access other than via Google Earth or Maps (example here). What's a geospatial developer to do? Navigate GMaps to a location, search, and then scrape the page for results? Ugh.

Next, there's very little information from Google about the steps geo-webmasters should take to be spatially indexed. One scant blog post about KML in sitemaps and a handful of quotes in Directions don't add up to much. I'd like to see some simple spatial tools integrated with Google's Webmaster Central. Maybe this will be a part of Ed's new job?

I'm not going to trot out the famous Upton Sinclair quote here, but it can not be denied that geospatial search offerings from Google (and soon, I'm sure, from other search engines) are disruptive to the mainstream GIS industry. Many of us are catalog programmers or catalog salespersons, and there's a bit of ducking and covering going on. Hoping that the disruption goes away without altering the business isn't going to work. Over the next few years, the relevance of sites like the Geospatial One-Stop, or projects like OGC Web Catalog Service, will evaporate just like the relevance of Yahoo's web catalog did in the late 1990s.

REST gets a mention from Sebastian Good, though his post is more about the current REST-less state of enterprise GIS.

Update: And this from Keyur Shah.

Me, again: enterprisey, business-to-business services will continue to use SOAP, but if there is going to be a Geo-Web, it will be based on REST.

In a comment on my last post, I pointed out that content negotiation is low on my priorities because there aren't enough smart user agents yet. In a related (and better) post, Dave Thomas explains how dumb the browser is, and how you might dumb down your applications. His idea is immediately relevant to anyone developing a RESTful GIS; when we're constrained to the same small handful of verbs (GET, POST, PUT, etc), it's easy to transfer and share architectural concepts.

Via Simon Willison.

Interesting, but Google's JSON, literally transcribed from Atom, is almost exactly as cumbersome as XML (example here). Apparently, it's all about evading the browser's same origin policy. Google should throw its weight behind Douglas Crockford's JSONRequest proposal.

Recent events, summarized by Tim O'Reilly here, have prompted me to spell out a policy for comments on this blog. I encourage people to write critically about our community, industry, and media, but I reserve the right to remove pointless flamebait or personal attacks as well as spam. If an email address accompanies extremely poor commentary, I'll contact the author personally about making sensible edits or retractions. If not, I'll simply delete it. Fair enough?

Update: changed the wording a bit so as not to point at anyone. The comments I get here provide much, if not all, of my blog's value. I won't delete non-spam comments lightly, but I have no obligation to give jerks a voice here.