GetResourceRepresentation exception FeatureInfo resource optional in resource oriented architectural style

Copyright © 2010 Open Geospatial Consortium Inc. 69 A WMTS client SHOULD support both KVP and RESTful. SOAP support is optional. A WMTS server SHOULD support KVP andor RESTful. SOAP support is optional.

11.2 A standard set of scales

It is strongly recommended that WMTS servers offer their Layers using, where possible, the well-known scale sets defined in the Annex E and reference them in the service metadata document in the TileMatrixSetDef section. This would aid interoperability between systems and allow users to mash-up suitable services.

11.3 A standard image format and FeatureInfo document response

It is recommended that servers offer Tiles in the imagepng and imagejpeg file formats. The imagepng image format is good for categorical maps and imagejpeg is better for imagery but since imagejpeg does not support transparency, imagepng may be used for images. It is recommended that WMTS Clients support both. Since a GetTile operation can serve only one tile at a time, it is important that clients have the ability to support transparency and also be able to overlap tiles from the same geographical area. It is recommended that FeatureInfo documents be offered in the MIME type format applicationgml+xml; version=3.1 and to follow GML Simple Features Profile [06- 049r1]. See subclause 7.3.1.

11.4 Number of TileMatrixSets and TileMatrixSetLimits

In a server where all layers cover almost the same area, or layers can cover the same area in the future it is recommended to use the same TileMatrixSet for all layers and to use TileMatrixSetLimits to inform clients about the tile matrix indices currently available. This will avoid changing all tile indices if some future change extends the area covered.

11.5 Cacheble resources

One of the main goals of this standard is to provide a better cache support for repetitive requests, helping WMTS servers to save resources and perform better. Web caching occurs at several levels, but for caching to occur at any of these levels caching mechanisms need to know that resources are cachable. Servers should include appropriate caching information expiration date in the WMTS server responses to avoid impacting performance. In a RESTful file based server where tiles are pre-rendered and stored in directories that are directly accessed by generic internet servers, the expiration date of the data can be configured as a property of this directory. Internally this is achieved by means of the proper HTTP control headers: HTTP 1.0, uses the Expires header. This header indicates an expiration date. If your data is guarantied to be static, or you know when the data is going to be updated, you can use a convenient future date in the Expires header.