OGC WMTS gets some "style"

We were testing the draft OGC WMTS Interface in .NET last Tuesday and noticed a quirk in REST WMTS. But CubeWerx and Universitat Autonoma de Barcelona were already on it - enhorabuena al equipo! Here's the deal - when trying to get tiles from OGC WMTS using the following syntax...

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

...we noticed the {style} path element is vital for providing addressable units of information. But the wording of the draft interface makes the {style} path element optional - that's a bit of a problem. Folks agreed this needs to change - and comments to OGC were submitted two weeks ago - nice job! Here are the key arguments from the RFC comment for making the {style} path element required -

a. It's the only part of the KVP GetTile request that can allow multiple parameter-set representations for the same tile. Every other parameter of the GetTile request is required and has a fixed set of possible values where each value results in a different document being requested. This strictness of parameters is by design - and one of the reasons for defining things this way is to make it easy for server-side tile caches to determine request equivalences.

b. Making the {style} path element optional adds unnecessary complexity and a potential point for implementation errors. Requiring it reduces complexity.

c. The optionality rules for the STYLE parameter in the SOAP and KVP encodings are different from those of the REST encoding (in SOAP and KVP WMTS, the parameter is optional, whereas in REST WMTS the parameter is required if the layer declares more than one style and ambiguously optional otherwise). This is another area of unnecessary complexity.

d. The REST-encoding rule for the STYLE parameter is: If the layer has zero or one style you should not include {style} level in paths and the default style will be returned - but there's no such thing as a layer with zero styles. The capabilities schema requires each layer to indicate at least one style. The main argument here is that this rule shouldn't exist.

e. Even if the REST-encoding rule for the STYLE parameter said "SHALL" rather than "SHOULD", it would make it very difficult for a WMTS service to interpret incoming REST-encoded GetTile requests. In order for it to know whether or not a style parameter is part of the request, it would have to perform a lookup of the layer to count how many styles it has. This can be an expensive operation. Even for a filesystem-only approach this is a problem. Imagine defining a layer with one style and pregenerating the tiles into the appropriate directory structure (or even generating and caching on the fly). Now imagine at some point in the future wanting to add a second style. Instead of just adding a new subdirectory representing that style, you'd have to rearrange the existing directory structure.

f. All this would make WMTS clients unnecessarily brittle. If a second style is added to a layer, existing REST-encoded tile URLs to that layer will become incorrect. Not good!

All this is solved simply by making the STYLE parameter required for all encodings of the GetTile and GetFeatureInfo requests. With this change, the WMTS can support RESTful encodings of tile requests that are really the address of the tile resource, with the operation (GET) being specified at the HTTP level - the RESTful encoding of a tile request consists of all nouns, and the HTTP operation indicates what operation is being performed on the addressed resource. Kudos to OGC for getting this done early. Stay tuned, much more to come...

- Jeff