Well-known scale sets Change Requests | OGC

Copyright © 2010 Open Geospatial Consortium Inc. 11 WMTS client will be unable to perform coordinate-system transformations or rescaling of tiles, the ability for a WMTS client to overlay tiles from one server on top of tiles from other servers will be limited unless there are some general agreements among WMTS servers as to what constitutes a common coordinate reference system and a common set of scales. Thus, this standard defines the concept of well-known scale sets. In order to increase interoperability between clients and servers it is recommended that many layers use a common set of scales in the same CRS that the target community agree to use. A well-known scale set is a well-known combination of a coordinate reference system and a set of scales that a tile matrix set declares support for. Each tile matrix set references one well-known scale set. A client application can confirm that tiles from one WMTS server are compatible with tiles from another WMTS server merely by verifying that they declare a common well-known scale set. It may also be the case that a client application is limited to supporting a particular coordinate system and set of scales e.g. , an application that overlays WMTS tiles on top of Google Maps tiles. In this situation, a client application can accept or reject a WMTS as being compatible merely by verifying the declared well-known scale set. Furthermore, the existence of well-known scale sets provides incentive for WMTS servers to support a well-known scale set, increasing the odds of compatibility with other WMTS sources. The informative Annex E provides several well-known scale sets and others could be incorporated in the future. A tile matrix set conforms to a particular well-known scale set when it uses the same CRS and defines all scale denominators ranging from the largest scale denominator in the well-known scale set to some low scale denominator in other words, it is not necessary to define all the lower scale denominators to conform to a well-known scale set. NOTE 1 Well-known scale sets are technically not necessary for interoperability, since a client application can always examine the actual list of coordinate systems and scales available for each layer of a WMTS server in order to determine its level of compatibility with other WMTS servers. Well-known scale sets are merely a convenience mechanism. 7 WMTS Implementation model This clause describes the WMTS resources that can be requested by a client from a server in either the procedure oriented architectural style or in the resource oriented architectural style. It also describes the procedure oriented architectural style operations in an abstract way; for KVP encoding, see clause 8 and for SOAP encoding, see clause 9. Resource oriented architectural style description and a RESTful implementation can be found in clause 10.

7.1 Service metadata

This subclause describes the ServiceMetadata document and the way in which it may be obtained using either a procedure oriented architectural style or a resource oriented architectural style. 12 Copyright © 2010 Open Geospatial Consortium Inc.

7.1.1 ServiceMetadata document

The ServiceMetadata document is the response document of a GetCapabilities request in procedure oriented architectural style or of a standard request to the right endpoint in a resource oriented architectural style. It is the entry point resource that represents the resources available on the service and communication requirements for the service.

7.1.1.1 ServiceMetadata document description

The ServiceMetadata document contains all the sections specified in Table 2, but partial documents can be requested containing only a subset of these sections. Depending on the values in the Sections parameter of the GetCapabilities operation request in the procedure oriented architectural style see subclause 7.1.2.1, any combination of these sections can be requested and SHALL be returned when requested except if the service does not support requests for sub-sections of the ServiceMetadata document. Figure 4 — ServiceMetadata UML model ServiceIdentification from OWS Service Identification +serviceIdentification 0..1 1 Capabilities Abstract from OWS Get Capabilities + version : CharacterString + updateSequence [0..1] : CharacterString + wsdl [0..1]: URL + serviceMetadataURL [0..1]: URL OperationsMetadata from OWS Operations Metadata +operationsMetadata 0..1 1 1 1 ServiceProvider from OWS Service Provider +serviceProvider 0..1 Contents from OWS contents +contents 0..1 Themes from WMTS GetCapabilities +themes 0.. 1