[Requests] OGC 07-057r6 (WMTS) comments

[Arne Kepp]

PART A

1. Evaluator:
         Arne Kepp
         GeoWebCache developer for OpenGeo
         ak at opengeo.org


2. Submission: OGC 07-057r6


PART B.1

1. Requirement: [General ]

2. Implementation Specification Section number: 7.1

3. Criticality: Major

4. Comments/justifications for changes:

The matrix definition does not make a distinction between the grid and 
data extents

Examples:
a) Use a well-known scaleset, such as GoogleMapsCompatible, but not 
serve tiles for the entire world. For example, you may have one tileset 
for each country.
b) You may start with a relatively small dataset, but later expand to 
new areas.

GeoWebCache currently deals with these cases by serving transparent PNGs 
to requests that fall outside of the covered areas, but it would be 
better if the client had some way of knowing in advance. One way to do 
that would be to have the getcapabilities document (optionally) include 
information about min/max row/column. This information is already 
available through the Lat/Long bounds, but it would be better to specify 
it directly in the layer description.

This can of course also be solved, like the document suggests, by not 
reusing grid definitions, and relying on the client to determine whether 
a matrixset corresponds to a subset of a well known set. But it is 
normally easier to do this on the server than on the client, and it 
greatly enhances the usability of the well known matrixsets.


PART B.2

1. Requirement: [General ]

2. Implementation Specification Section number: 7.1

3. Criticality: Major

4. Comments/justifications for changes:

Matrixset definitions should be referenced through URLs

If WMTS becomes popular then it is likely that authorities, such as 
national mapping agencies, will mandate specific matrixsets for their 
data. It would be good to reference these through URLs, perhaps in the 
same way that we use namespaces in XML. The alternative appears to be 
replication through cut and paste, which is a bit like comparing WKT 
definitions for projections instead of using EPSG codes.


PART B.3

1. Requirement: [General ]

2. Implementation Specification Section number: 8.3.1, 10.3.3

3. Criticality: Minor

4. Comments/justifications for changes:

KVP HTTP error messages difficult to recognize

It would be helpful to clients if the KVP service, like the RESTful one, 
set an HTTP error code when an exception is encountered. The "inimage" 
format is possibly the best way to forward a WMS error message to the 
client, but it's undesirable to do if the client has no way of telling 
that this is an error. (The same problem exists in WMS.)


PART B.4

1. Requirement: [General ]

2. Implementation Specification Section number: 8,9,10

3. Criticality: Minor

4. Comments

Including KVP, SOAP and RESTful interfaces as equal citizens may reduce 
interoperability or force developers to implement all three. Initially I 
wanted to suggest that the RESTful would be emphasized, to include 
static solutions like Apache, but Sean Gillies appears to have pointed 
out some problems with the current approach. I think IETF has had a lot 
of success with defining core standards and then expanding them with 
additional, optional profiles.




Overall, I think there are lots of good points in these specifications. 
Well done.

-Arne

-- 
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers