[Requests] comment #2 on candidate OGC WMTS Simple Profile (OGC 13-082)

Keith Pomakis pomakis at cubewerx.com
Tue Jun 17 12:00:29 EDT 2014


PART A
------

1. Evaluator:
         Keith Pomakis <pomakis at cubewerx.com>
         CubeWerx Inc.
         815 boulevard de la Carrière, bureau 202
         Gatineau, Québec, Canada
         J8Y 6T4
         Tel: 819-771-8303, ext. 202

2. Submission: candidate OGC WMTS Simple Profile (OGC 13-082)


PART B
------

1. Requirement: General

2. Implementation Specification Section number: 7.4, 7.5 and 7.6

3. Criticality: Major

4. Comments/justifications for changes:

Section 7.4 and 7.6 requires the declaration of a styles and tile-matrix
sets with blank identifiers, and section 7.5 allows the declaration
of a layer with a blank identifier.  I'm not sure this is a good idea.
Technically the schemas of the OWS Common specification don't disallow
it, but I suspect that many implementations will treat an empty value
for the Style and TileMatrixSet parameters as being equivalent to the
parameter not being present and throw an exception.  It all comes down to
the fundamental question of whether or not the empty string is considered
a valid identifier.  I'm not sure it's wise to tread these waters.

Furthermore, Section 7.5 requires clients and servers to support the
{/variable} syntax in URL templates, which the core WMTS specification
forbids.  This violates the first stated requirement, that "a WMTS
service implementing this profile SHALL conform with WMTS 1.0".
Any generic WMTS client that points to a simple-profile WMTS is sure
to fail because it won't expect this syntax in the URL templates.

It also makes it difficult if not impossible for a server to actually
interpret the request cleanly and unambiguously.  In a RESTful URL
request, the variables of the request are at least partially determined
by their location in the URL path.  If two or more path elements are
optional, it becomes very tricky to determine what the request variables
are.  For example, in a request of the form "[path]/A/B/C/D/1/2.png",
it is clear exactly what A, B, C and D represent.  But what about
a request of the form "[path]/A/B/1/2.png"?  What is A?  The layer?
The style?  The tile-matrix set?  In some situations it may be possible
to determine what is meant, but there's no general solution.

A simple solution to these issues is to NOT use blank identifiers.
Instead, require that a style with an identifier of "default" and a
GoogleMapsCompatible tile-matrix set with an identifier of "smerc"
be present.  Therefore, the required fixed URL template can be

[path]/[layer]/{style}/{TileMatrixSet}/{TileMatrix}/{TileCol}/{TileRow}[.file_extension]

where

[path]/[layer]/default/smerc/{TileMatrix}/{TileCol}/{TileRow}[.file_extension]

can be assumed to exist.

(Note that I use square brackets around layer and .file_extension to
distinguish them from actual URL-template variables.  They can't be
URL-template variables because the core WMTS specification doesn't list
them as possible URL-template variables.)

I recognize that this may preclude certain "current mass market
implementations" from being considered simple-profile-WMTS compliant.
So an alternate solution would be to leave the specification of the tile
URL templates as-is, and add a third URL-template resource type called
"simpleProfileTile" which assumes the default style and a global-coverage
GoogleMapsCompatible tile-matrix set.  It could be of the form:

[path]/[layer]/{TileMatrix}/{TileCol}/{TileRow}[.file_extension]

(Technically URL templates of this type could contain
the extended {/variable} syntax of RFC6570 because they'll be ignored
by generic WMTS clients.  However, the issue of the request being
ambiguous would still exist.)

(Technically this violates the resourceType enumeration restriction in
the core WMTS schema, but I think this is a minor violation in comparison
to the addition of the {/variable} syntax in "tile" URL templates.)

-- 
Keith Pomakis <pomakis at cubewerx.com>
Senior Software Developer, CubeWerx Inc.


More information about the Requests mailing list