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

Keith Pomakis pomakis at cubewerx.com
Tue Jun 17 12:12:33 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: General

3. Criticality: Major

4. Comments/justifications for changes:

This simple profile seems to be attempting to address two different
classes of simple-profile WMTS client - those that read WMTS
ServiceMetadata documents to figure out how to make tile requests and
those that don't.

For those clients that *do* read WMTS ServiceMetadata documents, wouldn't
simply adding the extra requirement that tile-matrix sets declared
to be GoogleMapsCompatible have a topLeftCorner of 20037508.3427892
20037508.3427892 and a tile size of 256x256 suffice to address the
calculation-complexity issues?  How does the introduction of a fixed
URL template that still requires variable substitution (and in a more
complex way, allowing {/variable} syntax) make things any easier or
more compatible?

For those clients that *don't* read WMTS ServiceMetadata documents,
they still somehow need to know how to formulate tile-request URLs to
the server.  I see only three possibilities here:

   a) The WMTS Simple Profile needs to require support for tile-URL
      templates that are *exactly* [baseUrl]/{TileMatrix}/{TileRow}/
      {TileCol}[.suffix] for exactly one or two fixed suffixes.
      This seems way overly restrictive.

   b) A pre-known tile-URL template (perhaps with known layer, style and
      tile-matrix-set names already filled in) needs to be fed to the
      client application.  Then it's trivial for the client to fill in
      the {TileMatrix}, {TileRow} and {TileCol} variables accordingly
      when making tile requests.  Again, the only extra requirement here
      is the knowledge that it's dealing with a GoogleMapsCompatible
      tile-matrix set that has a topLeftCorner of 20037508.3427892
      20037508.3427892 and a tile size of 256x256.  It isn't necessary to
      place a restriction on the order of the variables in the template.

   c) The client is a special-purpose client that has built-in knowledge
      of the tile-matrix sets and tile-URL templates of a specific type
      of server.  This is more or less the equivalent of the client
      knowing the service metadata of the server.

In summary, it seems that all this business of requiring the server to
declare fixed tile-URL templates and have layers, styles and tile-matrix
sets with empty-string identifiers and support the extra RFC6570 syntax
for resolving the tile-URL templates seems a bit pointless.  In my
opinion, all the WMTS Simple Profile specification needs to say is this:

   Req 1 - (as is)

   Req 2 - (as is, minus the CRS84 extension)

   Req 3 - (as is)

   Req 4 - (not necessary)

   Req 5 - (not necessary)

   Req 6 - (not necessary)

   Req 7 - A WMTS service implementing this profile shall provide layers
     which support the urn:ogc:def:wkss:OGC:1.0:GoogleMapsCompatible
     well-known tile-matrix set.  This well-known tile-matrix set shall
     have the following extra restrictions:

     a) a global coverage, with a topLeftCorner of
        (-20037508.3427892, 20037508.342789), and

     b) a TileWidth and TileHeight of 256.

   Req 8 - When the URI used to declare the profile is
     http://www.opengis.net/spec/wmts-simple/1.0/conf/simple-profile/CRS84,
     a WMTS service implementing this profile shall additionally provide
     layers which support the urn:ogc:def:wkss:OGC:1.0:GoogleCRS84Quad
     well-known tile-matrix set.  This well-known tile-matrix set shall
     have the following extra restrictions:

     a) a global coverage, with a topLeftCorner of (-180.0, -90.0), and

     b) a TileWidth and TileHeight of 256.

It could then go on to state that this allows for a class of clients that
can interact with the server merely by being fed a pre-known tile-URL
template (perhaps with known layer, style and tile-matrix-set names
already filled in), and that such clients would also be able to interface
with other types of tile servers that serve Google-Maps-compatible
tile sets.

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


More information about the Requests mailing list