Feature Demo

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.