NSDI 2.0, REST and the OGC WMTS

As folks discuss emerging technology for the National Spatial Data Infrastructure (NSDI) it's healthy consider the feasibility of different approaches as emergent solutions. It's important to note that recent "NSDI 2.0" grassroots coalitions didn't identify a particular technology platform in the initial concept paper - unlike Google, Microsoft and Oracle that said "SOA". Why? Because our consensus process identified this as an area where community discussion and exploration of emergent approaches was needed - and also because we knew there were multiple approaches available.

With that said, technology approaches for building online SDIs range from proprietary to interoperable and everything in between - and there are two basic Client-Server architectures to apply, ROA and SOA (Service Oriented Architectures and Resource Oriented Architectures). Note - folks will need both in an "SDI 2.0" because there will be information exchange, transaction services and collaboration requirements that can be supported better by SOA standards and KVP OGC Web Services like WFS. We'll take a look at Peer-to-Peer (p2p) architectures in the future.

SOA and ROA are both client-server design patterns and the corresponding distributed programming paradigms that provide conceptual methodologies for developing distributed architectures. In the cases of ROA and SOA the distributed components are called resources and services, respectively. I've discussed SOA already so lets look at ROA quickly - and use the draft OGC WMTS Interface Standard edited by CubeWerx, CREAF and the Autonomous University of Barcelona as an example.

From the candidate OGC WMTS Interface Standard - "The first step in the resource oriented architecture style is to identify the resources and the relations between the resources. Then the RESTful approach gives us a way to manipulate these resources via standard HTTP requests. In this specification only HTTP GET will be used to download resources that are equivalent to the ones that can be retrieved by the GetCapabilities, GetTile and GetFeatureInfo operations in the procedure oriented architecture style."

and...

"The RESTful encoding for WMTS consists in a set of canonical URLs to the service metadata document, to the tiles, and to the FeatureInfo documents (one for each pixel)."

So the URL referencing a capabilities document should have the following syntax...

{WMTSBaseURL}/{version}/WMTSCapabilities.{format_extension}

where format_extension is an extension compatible with the text/xml MIME type and version refers to the version of the capabilities document requested.

To request a WMTS capabilities document from a WMTS server that implements geospatial ROA, a client could issue the following RESTful URL...

http://www.maps.cat/1.0.0/WMTSCapabilities.xml

If a client requests a document version or a format extension that's not available on a particular server, the server returns an HTTP Error 404 (File Not Found). Sweet.

To continue, the ServiceMetadata document of WMTS in the RESTful architecture style contains a description of a resource with the name "Tile". The “Get” element of the GetResourceRepresentation operation has an xlink:href attribute that advertises the URL to retrieve tiles.

So the URL referencing a tile map image should have the following syntax...

{WMTSBaseURL}/{layer}/{style}/{firstDimension}/{...}/{lastDimension}/{TileMatrixSet}/{TileMatrix}/{TileRow}/{TileCol}.{format_extension}

If the layer has zero or one style, don't include the {style} level in paths and the default style will be returned. If there are no dimensions don't include /{firstDimension}/{...}/{lastDimension}/ levels in paths.

So then a client could issue the following RESTful Tile URL for a resource representation...

http://www.maps.cat/etopo2/WholeWorld_CRS_84/10m/1/3.png


So there you go, geospatial ROA 101 for the web engineers. As an overarching concept what is key is interoperability - the shared agreements of our community. As consensus ROA standards advance in the future, and can be combined with SOA and used for access to geospatial and environmental data, this is positive. In the end, a key concept is providing an open, standards-based framework so geospatial data and environmental data can be maintained locally, closest-to-source, and then shared with the Nation through an online information network. Stay tuned, much more to come...

- Jeff