Conceptualizing AtomPub for Map services

I have written about some of the advantages that a REST API can bring to exposing GIS data. This is not just for delivering map images but also for delivering and managing vector data. We have been building a RESTful API to not only expose vector GIS data, but to perform all of the CRUD operations on the data as required. Since most of our mapping applications are built using the ESRI JS API, the REST API makes it a breeze to access those functionalities through URL endpoints.

Not to revisit the topic again but the idea behind REST is to use HTTP as an ‘application protocol’ rather than as a transport protocol like SOAP web services do. One protocol that uses HTTP the way it is meant to be used is the AtomPub protocol. I am not going to go into details about the AtomPub protocol here since there a lot of documentation available online that do a good job of explaining the AtomPub protocol. But in brief terms,

The Atom Publishing Protocol is an application-level protocol for publishing and editing Web Resources using HTTP [RFC2616] and XML 1.0 [REC-xml].

AtomPub is both a format and a protocol. And I think that the AtomPub is a natural way to expose data especially also GIS data. I am going to go over how in my opinion GIS data exposed as map services seamlessly falls into the AtomPub data container structure. The figure below illustrates a simplified data container structure in AtomPub.

As you can see from the above figure, an AtomPub service document contains a list of ‘Workspaces’ which in turn contains a list of ‘Collections’. The ‘Collections’ are represented by Atom Feed documents. The Atom Feed document contain a list of ‘Entrys’. In my opinion, here is how the ‘Service Document’ in the AtomPub protocol relates to a map service. (I am only referring to ESRI Map services below).

Service Document – The Map Service itself – The entry point that describes the location and capabilities of collections

 

Workspace – Data Frames or Group Layers – A logical grouping of collections

 

Collection/Atom Feeds – Feature Layers – A Resource that contains a set of Member Resources. Collections are represented as Atom Feeds.

 

Entry – Feature – Represents an individual piece of content/Data

 

Categories Document/Categories Element – Feature Type – Provides metadata to describe an Atom entry. Categories Document describe Categories that are allowed in collections.

The AtomPub ‘Category’ element can also be used to represent feature types like ‘LinearRing’, ‘Polygon’, ‘LineString’, ‘MultiLineString’, ‘MultiPoint’ and be attached to Atom entries to provide metadata. They can also be used to represent the domain entity represented by the Feature Layer like National Forest etc…

 

Service Document Sample:

<?xml version=“1.0” encoding=‘utf-8’?>

<service xmlns=“http://www.w3.org/2007/app&#8221; xmlns:atom=“http://www.w3.org/2005/Atom&#8221;>

  <workspace>

    <atom:title>Transportation</atom:title>

    <collection href=“http://vishcio.us/NationalHighways&#8221; >

      <atom:title>National Highways</atom:title>

      <categories href=“http://vishcio.us/NationalHighways&#8221; />

    </collection>

    <collection href=“http://vishcio.us/Rivers&#8221; >

      <atom:title>Rivers</atom:title>

      <accept>image/json</accept>

      <accept>image/xml</accept>

    </collection>

  </workspace>

  <workspace>

    <atom:title>Water Bodies</atom:title>

    <collection href=“http://vishcio.us/Lakes&#8221; >

      <atom:title>Lakes</atom:title>

      <accept>application/atom+xml;type=entry</accept>

      <categories fixed=“yes”>

        <atom:category scheme=“http://vishcio.us/geometry/polygon&#8221; term=“polygon” />

        <atom:category scheme=“http://vishcio.us/Lakes&#8221; term=“Lakes” />

      </categories>

    </collection>

  </workspace>

</service>

 

Atom Feed Document:

<?xml version=“1.0” encoding=“utf-8”?>

<feed xmlns=“http://www.w3.org/2005/Atom&#8221;>

 

  <title>Example Feed</title>

  <subtitle>A subtitle.</subtitle>

  <link href=“http://example.org/feed/&#8221; rel=“self”/>

  <link href=“http://example.org/&#8221;/>

  <updated>2003-12-13T18:30:02Z</updated>

  <author>

    <name>John Doe</name>

    <email>johndoe@example.com</email>

  </author>

  <id>urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6</id>

 

  <entry>

    <title>Atom-Powered Robots Run Amok</title>

    <link href=“http://example.org/2003/12/13/atom03&#8221;/>

    <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>

    <updated>2003-12-13T18:30:02Z</updated>

    <summary>Some text.</summary>

  </entry>

 

</feed>

 

Categories Document:

<?xml version=“1.0” ?>

<app:categories xmlns:app=“http://www.w3.org/2007/app&#8221; xmlns:atom=“http://www.w3.org/2005/Atom&#8221; fixed=“yes” scheme=“http://example.com/cats/big3&#8221;>

  <atom:category term=“animal” />

  <atom:category term=“vegetable” />

  <atom:category term=“mineral” />

</app:categories>

 

The above is just my take on how the AtomPub elements can relate to map services. I think this is the next logical step in making map services more resource oriented and will allow for dynamic discoverability and ease in application development. ESRI map services already have the concept of a service document that can be accessed at the links below.

http://sampleserver1.arcgisonline.com/arcgis/rest/services

http://sampleserver1.arcgisonline.com/arcgis/rest/services?f=pjson

Supporting the AtomPub output format for that service document should be pretty simple.