Atompub, KML and Google Earth

With Google Earth, one can browse the web of KML documents and author new KML documents. It's nearly the ideal client for a read-write "GeoWeb". The one missing feature: publishing KML documents and placemarks to the Web. I've written previously about this missing feature and now I'm going to explain exactly how it should be done. Andrew, consider this a little free legwork for your Agile Geography effort.

Google Earth (GE) already allows you to POST KML documents to a Keyhole website. I am simply proposing more of the same using a simple and effective RESTful protocol that has already been implemented on a large scale within Google (see GData): the Atom Publishing Protocol (aka Atompub). Nevermind transactional OGC Web Feature Services -- WFS is a sorry compromise between interests who really, in their hearts, want SOAP and more pragmatic interests who want to at least be able to GET features with their web browser -- the future of GIS web services is RESTful.

The Google Earth team already recognizes this, even if not overtly. Consider the new behavior toward description hypermedia links that is proposed for KML 2.2. Links to KML documents found in placemark descriptions will be dereferenced by GE itself. In other words, GE will use hypermedia as the engine of application state, one of the tenets of REST. A RESTful approach to publishing data to the Web would complement the new geo-browsing feature perfectly.

So, how would one use Atompub with KML and Google Earth? Interestingly (maybe coincidence, maybe not), KML 2.2 is already paving the way by adding atom:link. There are three main classes of links in Atompub: to a Collection URI, to a Member URI, and to a Media Resource URI. Add such links to KML elements and Atompub interoperability is in hand. More specifically, every KML Document SHOULD specify an Atompub Collection URI:

<Document>
  <atom:link rel="self" href="http://gis.example.com/places/"/>
  ...
</Document>

The URI specified in the href attribute is the one to which a client (such as the future KML-publishing version of Google Earth) would POST a new placemark, and thereby insert new data into the collection that is providing the current KML document. Likewise, every Placemark that one may edit SHOULD specify Member URI and Media Resource URIs:

<Placemark>
  <atom:link rel="edit" href="http://gis.example.com/places/1"/>
  <atom:link rel="edit-media" href="http://gis.example.com/places/1.kml"/>
  ...
</Placemark>

The URI in the "edit" link is the one to which metadata updates (attribution, etc) would be PUT by the client. The URI in the "edit-media" link is the one to which the client would PUT an updated KML representation.

That's it. It's mind-bogglingly simple. The catch for implementors, of course, is authentication. Most sites/services won't (for good reason) accept anonymously posted placemarks or allow drive-by editing and deletion of existing data. This means that Google Earth would need to implement many of the security features that we usually take for granted in our web browsers. Still, authentication is no more a problem for this RESTful approach using Atompub than it is for WFS-T.

Atompub + KML == agile, read-write geography.

Update: I just remembered that Andrew Turner almost made the Atompub connection here. His proposal for linking to KML from Atom entries fits perfectly with what I've outlined above.