[Requests] Comments on Candidate Web Map Tiling Standard

Keith Pomakis pomakis at cubewerx.com
Fri Mar 6 09:24:24 EST 2009


1. Evaluator:
       Keith Pomakis <pomakis at cubewerx.com>
       Senior Software Developer, CubeWerx Inc.
       15 rue Gamelin, Gatineau, Québec J8Y 3B5
       Phone: 819-771-8303 x202, FAX: 819-771-8388

2. Submission:
       Candidate OpenGIS Web Map Tiling Service Implementation Standard 


1. Requirement:
       STYLE parameter should be required for all encodings

2. Implementation Specification Section number:
       minor changes throughout document 07-057r6

3. Criticality: Major

4. Comments/justifications for changes:

While reviewing the candidate WMTS standard, I was surprised by the fact
that the STYLE parameter is optional in the GetTile operation request.
I think this is a very bad idea for a number of reasons:

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.
   It's very easy for even the most basic software to see the
   equivalence of "LAYER=BOB&STYLE=JIM" and "style=JIM&layer=BOB",
   but far more difficult to see whether or not "LAYER=BOB&STYLE=JIM"
   and "layer=BOB" (without a STYLE element present) are equivalent,
   because a potentially-expensive lookup would have to be performed in
   order to determine what the default style of the layer is.  This is
   acceptible in the WMS world because the unbounded nature of WMS GetMap
   requests make caching a hit-and-miss optimization at best anyways.
   But the ability to effectively cache tiles is a fundamental property
   of the WMTS, so we have to make sure that there's nothing in the
   WMTS specification that makes it difficult.

b. It creates an ugly and unnecessary exception in the specification,
   thus adding unnecessary complexity and a potential point for
   implementation errors.  Even if the server only has one layer, the
   client still needs to specify the layer name.  There's no such thing
   as a default layer.  Even if a layer only has one tile matrix set, the
   client still needs to specify the tile matrix set name.  There's no
   such thing as a default tile matrix set.  Repeat this for every other
   parameter of the GetTile request.  Why should STYLE be any different?

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, the parameter is optional, whereas in REST the parameter is
   required if the layer declares more than one style and ambiguously
   optional otherwise.)  This is another area of unnecessary complexity,
   and is a disaster waiting to happen because it makes translation
   between the different encodings very difficult.  Unless there's
   a good reason for deciding otherwise, the optionality rules for
   each parameter should be consistent between the different request

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.

   (BTW, there's a typo in the specification; it says "one one style".)

   (Also, there's no such thing as a layer with zero styles.
   The capabilities schema requires each layer to indicate at least
   one style.)

   My main argument is that this rule shouldn't exist, but if I fail
   to convince you of this, then you should at least agree that the
   rule should say "SHALL" and not "SHOULD".  Since the parameters of
   a REST-encoded request are not named but are identified by their
   position in the path, there should be no room for the server to
   have to guess whether or not the style parameter has been included.
   It makes file-system-only implementations difficult as well, since
   every tile of every single-style layer would have to have two
   distinct paths.

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 server 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. This in turn would makes WMTS clients unnecessarily brittle.  If a
   second style is added to a layer, all existing REST-encoded tile URLs
   to that layer will immediately become incorrect.  That's not good!

All of this can be solved simply by making the STYLE parameter required
for all encodings of the GetTile and GetFeatureInfo operation requests.

This in turn would (for the most part) obsolete the requirement for the
"isDefault" attribute of the <Style> element.  My own personal opinion
on this attribute is that it should stay, but with a different meaning.
Rather than it being "the style that's used when no style is specified"
(which no longer makes sense if the STYLE parameter is required), I
think it should have the definition "the style that a client should
request for this layer by default".  This would give the server the
ability to provide a hint to the client application as to what style
should be selected by default.  But I'd be just as happy to see this
attribute disappear completely.

Keith Pomakis <pomakis at cubewerx.com>
Senior Software Developer, CubeWerx Inc.
15 rue Gamelin, Gatineau, Québec J8Y 3B5
Phone: 819-771-8303 x202, FAX: 819-771-8388

More information about the Requests mailing list