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.


Re: Feature Demo

Author: Rob De Almeida

Very nice! I also liked the idea of using vim as a REST client. :)

Re: Feature Demo

Author: Bryan

Nice stuff. Couldn't make google maps do it's business, but did engage with the server just fine ... I much appreciate you putting these sorts of ideas up.

Re: Feature Demo

Author: Sean

Pasting http://zcologia.com:8081/features.kml into the http://maps.google.com search field doesn't work for you? It is a fun idea. Now I need a better client. I'd like to see Google Earth support POST (better yet, PUT) of KML to arbitrary URLs. In my mind, that's more generally useful than implementing the client side of WFS-T.

Re: Feature Demo

Author: Guillaume

Nice toy actually. pasting http://zcologia.com:8081/features.kml into googleMaps is ok, but not with the http://zcologia.com:8081/features.atom. Any idea why ? I'm greatly interested in the REST approach, but I have some misunderstanding about it. As a web service giving access to ressources, I think I get it. But how can a full application be build around that ? imagine a map, with a legend, and a query/info tool. If I click into a legend checkbox to hide a layer on the map, must I "GET" both map and legend services ? how to synchronize them ? When I click with info tool on the map, I need as a result both a new map with the selected object highlighted on it, and a text stream giving information about it. Same question : how can I build that in a restfull way ? Thanks

Re: Feature Demo

Author: Kristian

Guillaume, "When I click with info tool on the map, I need as a result both a new map with the selected object highlighted on it, and a text stream giving information about it." For instance by having https://example.com/getInfo/${id} return { info: 'Info text here', map: 'http://example.com/getMap/${bbox}/${id}' } or somesuch.

Re: Feature Demo

Author: Sean

I'm not sure why the Atom feed isn't rendered. It is valid. Make it easier, Guillaume. Your info tool could query a resource like GET /map/featureinfo?x=-100.0&y=40.0 which could return information to be displayed in a table, and a shape to be rendered in a transparent overlay. Keep the current map (tiles) unmodified.

Re: Feature Demo

Author: Guillaume

ok, it's getting clearer. Thanks for these clues.