Atom and Web Mapping Charlie Savage MapBuzz, Inc. Charlie Savage MapBuzz, Inc. Slides at

Page 1 Atom Will Change Mapping Atom is a better platform for exchanging geospatial data then existing standards By “Atom” I mean both the syndication format and publishing protocol Atom offers a surprisingly deep platform well suited for building web applications We're witnessing the birth of the next great technology standard

Page 2 Exchanging Geospatial Data Its fairly easy to share maps on the web – Google, Microsoft, Yahoo, WMS But what about other geospatial information – features, events, histories, etc?

Page 3 What do We Need? A standard identification system A standard interaction protocol Standard data exchange formats Standard way of handling state

Page 4 How Does the Web Do It? Identification system – URIs Interaction protocol - HTTP Formats - xhtml, png, jpeg, etc. State – session state is embedded in formats (xhtml) via links Let’s clients and servers evolve independently “Engineer for Serendipity” – Roy Fielding

Page 5 Web Feature Server (WFS) An Open Geospatial Consortium (OGC) standard Lets clients view, query, lock, create, update and delete features

Page 6 WFS Is Deeply Flawed for the Web Identification – Features do not have URIs Interaction – Uses a proprietary API (GetCapabilities, GetFeature, etc.) Format – uses GML State – GML supports links (via XLink), but it is rarely used

Page 7 GML Is Moderately Flawed for the Web GML was not designed for the web – it was designed for the Enterprise GML requires the creation of custom schemas - which is great for the Enterprise and terrible for the Web Theoretically everyone could agree on a single GML profile such as the Simple Feature Profile

Page 8 WFS/GML Will Fail on the Web No URIs means no linking, page rank, etc Proprietary interface requires custom clients that are tightly coupled to servers Incorrect use of HTTP as a transport protocol throws away the benefits of the web infrastructure (caching, load balancing) Lack of common GML schema causes information to be segregated by organization, industry type, problem domain No serendipity – how many WFS mashups do you see?

Page 9 Enter Atom – Built for the Web Identification – everything has a URI Interaction – Specified by Atom Publishing Protocol, based on HTTP Formats – Atom syndication format, service documents, category documents State - Full support for linking and therefore session state Fully utilizes web infrastructure

Page 10 Atom Syndication Defines a small set of the most useful attributes, such as name, published date, etc. Direct overlay with the Dublin Core attributes Applicable to many problem domains Extensible through XML namespaces

Page 11 Atom Publication Protocol (APP) APP = Atom + REST Application protocol that defines how clients and servers interact Deftly leverages HTTP:  Uses GET, POST, PUT and DELETE  Uses HTTP response codes for error handling  Enables HTTP caching mechanisms Built in support for arbitrary media types – locations, pictures, podcasts, etc.

Page 12 A Simple Data Model Image courtesy of Dave Johnson

Page 13 Built-in Aggregation Search items Victoria - Foss4G Conference Maps

Page 14 Extensible GeoRss – Locations Feed Paging and Archiving – retrieve subset of entries Threading – Comments and discussions Atom Ranking Extensions – Any type of ordering information such as user ratings

Page 15 Amazing Uptake Browser support - Opera, Firefox, Internet Explorer Corporate support – Microsoft, Google, Amazon, SixApart, MapBuzz (Facebook, LinkedIn, MySpace next?) OpenSource support – OpenLayers, Lucene, Apache Abdera

Page 16 A Great Web Service Platform Atom syndication provides a base level of understanding across problem domains Atom publishing protocol makes it easy to build REST base services Its much easier to extend Atom then start from scratch Atom will become the lingua franca of web services

Page 17 Using Atom to Replace WFS Simple - Atom + GeoRss Complex - Atom + GML

Page 18 Atom + GeoRss Simple, grass roots standard, for specifying location Advantages  Easy to implement  Indexed by Google  Covers a large number of applications Disadvantages  Not all atom attributes are applicable  No custom attributes  No topology, measurements, coverages

Page 19 Atom + GeoRss Example Brown Palace Hotel

Page 20 Atom + GML Advantages  Custom attributes Disadvantages  Harder to implement  Not indexed by Google  Very limited client support

Page 21 Atom + GML Example Let’s find an example of Simple Feature Profile Google around…hmmm…where are they?

Page 22 What About Queries (Filters)? OGC Filter Specification defines spatial query language Difficult to use with GET  Need to URL encode xml request  GET query length limited by Internet Explorer Often used with POST but this is WRONG:  Breaks linkability  Breaks cacheability

Page 23 Query Example request=getfeature& service=wfs& version=1.0.0& typename=states& filter= the_geom , ,

Page 24 Queries Are Resources Treat queries as resources – they become “part of the web” Create, update, delete queries via Atom of course (treat the queries as a media resource) Neatly solves the GET/POST dilemma Makes it possible to track the number of times a query is executed, total amount of time, etc. Also allows queries to be reused across servers (probably of dubious value, but…)

Page 25 Open Issues Custom attributes – is GML going to play in this area – if so what profile? Multiple flavors of GeoRss Minor – non-applicable Atom attributes (author, title, category, updated)?

Page 26 Reaching Consensus OGC has finally noticed REST – just starting to talk about “RESTifying” WFS and other standards OGC is a standards organization – most likely won’t move quickly OGC’s focuses on the traditional GIS market and large organizations so expect membership pushback In the meantime, join us on the GEO-REST discussion group where we talk about these issues Participate in our next interoperability day where we make sure our clients and servers really work together