Open Geospatial Consortium Inc.
Date: 2010-04-06
Reference number of this document: OGC 07-057r7
Version: 1.0.0
Category: OpenGIS®

Implementation Standard

Editors: Joan Masó, Keith Pomakis and Núria Julià

OpenGIS® Web Map Tile Service Implementation Standard

Copyright © 2010 Open Geospatial Consortium Inc.
To obtain additional rights of use, visit http://www.opengeospatial.org/legal/.

Warning
This document is an OGC Member approved international standard. This document isavailable on a royalty free, non-discriminatory basis. Recipients of this document are
invited to submit, with their comments, notification of any relevant patent rights of which
they are aware and to provide supporting documentation..

Document type:
Document subtype:
Document stage:
Document language:

OpenGIS® Standard
OGC Standard
Approved for release
EnglishLicense Agreement
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below,
to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property
without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish,
distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to
do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual
Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above
copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTSTHAT MAY BE IN FORCE ANYWHERE IN THE WORLD.
THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULARPURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDEDIN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILLMEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE
UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT
THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OFINTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY
DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTINGFROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH
THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all
copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except asprovided in the following sentence, no such termination of this license shall require the termination of any third party end-user
sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual
Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent,
copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license
without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy orcause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual
Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without
prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may
authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any
LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United
Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of thisAgreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable,
and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be
construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported inviolation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction
which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any
regulations or registration procedures required by applicable law to make this license enforceableii

Copyright © 2012 Open Geospatial Consortium

OGC 07-057r7

Contentsi.

Page

Preface................................................................................................................................... viii

iii. Submitting organizations ...................................................................................................... viii
iv. Document contributor contact points .................................................................................... viii
v.

Revision history ...................................................................................................................... ix

vi. Changes to the OGC Abstract Specification ............................................................................ xvii. Changes to OpenGIS® Implementation Standards ................................................................... xviii. Future work .............................................................................................................................. x
Foreword ........................................................................................................................................ xi
Introduction ................................................................................................................................... xii

1

Scope ........................................................................................................................1

2

Compliance ..............................................................................................................1

3

Normative references ...............................................................................................1

4

Terms and definitions ..............................................................................................2

5
5.1
5.2
5.3
5.4
5.5

Conventions .............................................................................................................3
Abbreviated terms ...............................................................................................3
UML notation ......................................................................................................4
Used parts of other documents ............................................................................4
Platform-neutral and platform-specific standards ...............................................4
UML graphical and table representations ...........................................................4

6.1
6.2

WMTS overview ......................................................................................................6
Tile matrix set – the geometry of the tiled space ................................................7
Well-known scale sets .......................................................................................10

6

7

WMTS Implementation model ..............................................................................11
7.1
Service metadata................................................................................................11
7.1.1
ServiceMetadata document ...........................................................................127.1.1.1 ServiceMetadata document description .....................................................127.1.1.2 ServiceMetadata document XML schema .................................................30
7.1.1.3 ServiceMetadata document example .........................................................31
7.1.2
GetCapabilities operation (mandatory in procedure oriented
architectural style) .........................................................................................36
7.1.2.1 GetCapabilities operation request ..............................................................36
7.1.2.2 GetCapabilites exceptions in procedure oriented architectural style .........38ii

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

7.1.3

ServiceMetadata resource request (mandatory in resource oriented
architectural style) .........................................................................................39
7.2
Tile.....................................................................................................................39
7.2.1
Tile resource..................................................................................................40
7.2.2
GetTile operation (mandatory in procedure oriented architectural style) .....40
7.2.2.1 GetTile operation request ...........................................................................40
7.2.2.2 GetTile exceptions in procedure oriented architectural style ....................43
7.2.3
Tile resource request (mandatory in resource oriented architectural
style) ..............................................................................................................44
7.3
FeatureInfo ........................................................................................................44
7.3.1
FeatureInfo document ...................................................................................44
7.3.2
GetFeatureInfo operation (optional in procedure oriented architectural
style) ..............................................................................................................45
7.3.2.1 GetFeatureInfo operation request ..............................................................45
7.3.2.2 GetFeatureInfo exceptions in procedure oriented architectural style ........47
7.3.3
FeatureInfo resource request (optional in resource oriented
architectural style) .........................................................................................49
7.4
Operation request encoding ...............................................................................49
8

WMTS using HTTP KVP encoding ......................................................................49
8.1
GetCapabilities ..................................................................................................50
8.1.1
GetCapabilities request HTTP KVP encoding .............................................50
8.1.2
GetCapabilities request HTTP KVP encoding example ...............................50
8.1.3
GetCapabilities HTTP KVP encoding response ...........................................50
8.1.4
GetCapabilities HTTP KVP encoding response example ............................50
8.2
GetTile ...............................................................................................................51
8.2.1
GetTile request HTTP KVP encoding ..........................................................51
8.2.2
GetTile request HTTP KVP encoding example............................................51
8.2.3
GetTile HTTP KVP encoding response ........................................................52
8.2.4
GetTile HTTP KVP encoding response example .........................................52
8.3
GetFeatureInfo...................................................................................................52
8.3.1
GetFeatureInfo request HTTP KVP encoding ..............................................52
8.3.2
GetFeatureInfo request HTTP KVP encoding example ...............................53
8.3.3
GetFeatureInfo HTTP KVP encoding response ...........................................53
8.3.4
GetFeatureInfo HTTP KVP encoding response example .............................53
8.4
Exceptions in HTTP KVP encoded operations .................................................54

9

WMTS using SOAP encoding ...............................................................................54
9.1
GetCapabilities ..................................................................................................54
9.1.1
GetCapabilities request SOAP encoding ......................................................54
9.1.2
GetCapabilities request SOAP encoding example ........................................54
9.1.3
GetCapabilities SOAP encoding response ....................................................54
9.1.4
GetCapabilities SOAP encoding response example .....................................55
9.2
GetTile ...............................................................................................................55
9.2.1
GetTile request SOAP encoding ...................................................................55
9.2.2
GetTile request SOAP encoding example ....................................................55
9.2.3
GetTile SOAP encoding response ................................................................56
9.2.4
GetTile SOAP encoding response example ..................................................56
9.3
GetFeatureInfo...................................................................................................57

Copyright © 2010 Open Geospatial Consortium Inc.

iii

OGC 07-057r7

9.3.1
GetFeatureInfo request SOAP encoding .......................................................57
9.3.2
GetFeatureInfo request SOAP encoding example ........................................57
9.3.3
GetFeatureInfo SOAP encoding response ....................................................57
9.3.4
GetFeatureInfo SOAP encoding response example ......................................58
9.4
Exceptions in SOAP encoding ..........................................................................59
10
WMTS using RESTful...........................................................................................60
10.1
ServiceMetadata resource (mandatory in resource oriented architectural
style) ..................................................................................................................61
10.1.1 GetResourceRepresentation request .............................................................61
10.1.2 GetResourceRepresentation request example ...............................................61
10.1.3 ServiceMetadata representation ....................................................................61
10.1.4 ServiceMetadata representation example .....................................................61
10.1.5 GetResourceRepresentation exception .........................................................61
10.2
Tile resource (mandatory in resource oriented architectural style) ...................62
10.2.1 GetResourceRepresentation request .............................................................62
10.2.2 GetResourceRepresentation request example ...............................................64
10.2.3 Tile representation ........................................................................................64
10.2.4 Tile representation example ..........................................................................64
10.2.5 GetResourceRepresentation exception .........................................................65
10.3
FeatureInfo resource (optional in resource oriented architectural style) ...........65
10.3.1 GetResourceRepresentation request .............................................................65
10.3.2 GetResourceRepresentation request example ...............................................68
10.3.3 FeatureInfo representation ............................................................................68
10.3.4 FeatureInfo representation as an XML document example ..........................68
10.3.5 GetResourceRepresentation exception .........................................................68
11
Recommendations to improve interoperability and performance. .........................68
11.1
Server and Client support for KVP, SOAP and RESTful .................................68
11.2
A standard set of scales .....................................................................................69
11.3
A standard image format and FeatureInfo document response .........................69
11.4
Number of TileMatrixSets and TileMatrixSetLimits ........................................69
11.5
Cacheble resources ............................................................................................69
Annex A (normative) Abstract test suite ..........................................................................71
A.1
Introduction .......................................................................................................71
A.2
Client test module ..............................................................................................72
A.3
Server test module .............................................................................................73
Annex B (normative) XML Schema Documents..............................................................86
Annex C (informative) UML model .................................................................................88
C.1
Introduction .......................................................................................................88
C.2
UML packages ..................................................................................................89
C.3
WMTS Service package ....................................................................................90
C.4
WMTS Get Capabilities, Contents and Themes packages ................................91
C.5
WMTS Get Tile package ...................................................................................94
C.6
WMTS Get Feature Info package .....................................................................96iv

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Annex D (informative) Example XML documents ..........................................................98
D.1
Introduction .......................................................................................................98
D.2
ServiceMetadata response example...................................................................98
Annex E (informative) Well-known scale sets ...............................................................102
E.1
GlobalCRS84Scale (urn:ogc:def:wkss:OGC:1.0:GlobalCRS84Scale) ...........102
E.2
GlobalCRS84Pixel (urn:ogc:def:wkss:OGC:1.0:GlobalCRS84Pixel) ............103
E.3
GoogleCRS84Quad (urn:ogc:def:wkss:OGC:1.0:GoogleCRS84Quad) .........104
E.4
GoogleMapsCompatible(urn:ogc:def:wkss:OGC:1.0:GoogleMapsCompatible) ...................................105
Annex F (normative) WSDL description of the service .................................................106
F.1
General ............................................................................................................106
F.2
WSDL Publication ..........................................................................................106
F.3
Abstract and concrete WSDL documents .......................................................107
F.4
Abstract WMTS WSDL document .................................................................107
F.5
Concrete WMTS WSDL document ................................................................109
F.6
Concrete WMTS WSDL document example ..................................................109
Annex H (informative) Pseudocode................................................................................112
H.1
From BBOX to tile indices ..............................................................................112
H.2
From tile indices to BBOX ..............................................................................112
Bibliography ................................................................................................................................ 114

FiguresPage

Figure 1 — WMTS interface UML diagram ................................................................................... 7
Figure 2 — Tile Space..................................................................................................................... 9
Figure 3 — Tile Matrix Set representation.................................................................................... 10
Figure 4 — ServiceMetadata UML model .................................................................................... 12
Figure 5 — Contents UML model................................................................................................. 16
Figure 6 — Layer UML model ..................................................................................................... 18
Figure 7 — Optional TileMatrix Limits ........................................................................................ 25
Figure 8 — TileMatrixSet UML model ........................................................................................ 25
Figure 9 — Themes UML model .................................................................................................. 29
Figure 10 — GetTile operation request UML class diagram ........................................................ 41
Figure 11 — GetFeatureInfo operation request UML class diagram ............................................ 46
Figure 12 — GetTile response example ........................................................................................ 52
Figure 13 — URLTemplate for tile UML class diagram .............................................................. 62
Figure 14 — URLTemplate for the FeatureInfo UML class diagram ........................................... 65

Copyright © 2010 Open Geospatial Consortium Inc.

v

OGC 07-057r7
Figure C.1 — WMTS interface UML diagram ............................................................................. 88
Figure C.2 — WMTS interface package diagram ......................................................................... 89
Figure C.3 — WMTS Service package class diagram .................................................................. 90
Figure C.4 — Get Capabilities package class diagram, part 1 ...................................................... 91
Figure C.5 — Get Capabilities package class diagram, part 2 ...................................................... 92
Figure C.6 — Get Capabilities package class diagram, part 3 ...................................................... 93
Figure C.7 — Get Tile package class diagram .............................................................................. 94
Figure C.8 — Get Feature Info package class diagram ................................................................. 96

TablesPage

Table 1 — Contents of data dictionary tables ................................................................................. 5
Table 2 —ServiceMetadata sections ............................................................................................. 13
Table 3 — Parts of the Capabilities data structure ........................................................................ 13
Table 4 — Values of OperationsMetadata section parameters ..................................................... 14
Table 5 — Parts of the Contents section ....................................................................................... 17
Table 6 — Parts of Layer data structure ........................................................................................ 19
Table 7 — Parts of Style data structure ......................................................................................... 20
Table 8 — Parts of LegendURL data structure ............................................................................. 21
Table 9 — Parts of Dimension data structure................................................................................ 22
Table 10 — Parts of TileMatrixSetLink data structure ................................................................. 23
Table 11 — Parts of TileMatrixSetLimits data structure .............................................................. 24
Table 12 — Parts of TileMatrixLimits data structure ................................................................... 24
Table 13 — Parts of TileMatrixSet data structure......................................................................... 26
Table 14 — Parts of TileMatrix data structure .............................................................................. 27
Table 15 — Parts of the Themes section ....................................................................................... 29
Table 16 — Parts of Theme data structure .................................................................................... 29
Table 17 — Parameters in GetCapabilities operation request ....................................................... 36
Table 18 — Meaning of section name values ............................................................................... 37
Table 19 — Implementation of parameters in GetCapabilities operation request ........................ 37
Table 20 — Exception codes for GetCapabilities operation ......................................................... 38
Table 21 — HTTP exception codes and meanings on GetCapabilities operation ........................ 39
Table 22 — Parameters in GetTile operation request ................................................................... 42
Table 23 — Exception codes for GetTile operation ...................................................................... 43
Table 24 — HTTP exception codes and meanings on GetTile operation ..................................... 43vi

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7
Table 25 — Parameters in GetFeatureInfo operation request ....................................................... 47
Table 26 — Exception codes for GetFeatureInfo operation.......................................................... 48
Table 27 — HTTP exception codes and meanings on GetFeatureInfo operation ......................... 48
Table 28 — Procedure oriented architectural style operation request encoding ........................... 49
Table 29 — GetTile operation request URL parameters ............................................................... 51
Table 30 — GetFeatureInfo operation request URL parameters................................................... 52
Table 31 — Parts of the URLTemplate data structure for tiles ..................................................... 62
Table 32 — URL template variables and possible values for tile ................................................. 63
Table 33 — Parts of the URLTemplate data structure for FeatureInfo ......................................... 65
Table 34 — URL template variables and possible values for FeatureInfo.................................... 66
Table C.1 — Mapping of UML TileRequest attributes and HTTP GetTile request parameters ... 95
Table C.2 — Mapping of UML FeatureInfoRequest attributes and HTTP GetFeatureInfo request
parameters .............................................................................................................................. 97
Table E.1 — Definition of Well-known scale set GlobalCRS84Scale ....................................... 102
Table E.2 — Definition of Well-known scale set GlobalCRS84Pixel ........................................ 103
Table E.3 — Definition of Well-known scale set GoogleCRS84Quad....................................... 104
Table E.4 — Definition of Well-known scale set GoogleMapsCompatible ............................... 105

Copyright © 2010 Open Geospatial Consortium Inc.

vii

OGC 07-057r7

i.

PrefaceThis document defines an OGC standard for a Web Map Tile Service (WMTS) interface
standard. A WMTS enabled server application can serve map tiles of spatially referenced
data using tile images with predefined content, extent, and resolution.
Suggested additions, changes and comments on this standard are welcome andencouraged. Such suggestions may be submitted using the online change request form on
OGC web site: http://portal.opengeospatial.org/public_ogc/change_request.php

ii.

Standard verbs and usages

This document uses the standard verbs defined in subclause 5.3 of [OGC 06-121r3],
which is based on the ISO/IEC Directives, Part 2. Rules for the structure and drafting ofInternational Standards that are also included in subclause 6.1 of [OGC 06-135r7] Policy
Directives for Writing and Publishing OGC Standards. In particular, the word "SHALL"(in capital letters and not "must") is the verb form used to indicate a requirement to bestrictly followed to conform to this standard.

iii.

Submitting organizations

The following organizations submitted this document to the Open Geospatial Consortium
Inc.
Autonomous University of Barcelona
CREAF
CubeWerx Inc.

iv.

Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:
Name

Organization

E-mail Address

Joan Masó

UAB-CREAF

joan.maso@uab.cat

Keith Pomakis

CubeWerx Inc.

pomakis@cubewerx.com

Núria JuliàUAB-CREAF

n.julia@creaf.uab.cat

viii

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

v.

Revision history
Date

Release

2007-05-08 07-057

EditorPrimary
clausesmodified

Description

2007-06-15 07-057r1

Joan Masó and
Núria Julià
Joan Masó

2007-08-14 07-057r2

Keith Pomakis

2007-11-13 07-057r3

Keith Pomakis

2008-03-25 07-057r4

Keith Pomakis

Several modifications proposed mainly by
Chuck Morris and Joan Masó.

2008-06-15 07-057r5

Joan Masó

Reformated as a Standards document.
GetLegendGraphic and GetAlternateSources
operations were removed. RESTful was
introduced. Major revisions by Benjamin
Chartier and Keith Pomakis.

2009-01-25

Joan Masó

Many considerations in Keith Pomakis OGC
09-006 OWS-6-DSS Engineering Report –SOAPXML and REST in WMTS have been
included.

2009-02-26 07-057r6

Joan Masó

Added WSDL annex F and general minor
corrections.

2009-08-11 07-057r7

Joan Masó

CRs in RFC period have been incorporated.
URL template has been introduced. Namechanges from "Web Map Tiling Service" to"Web Map Tile Service". Major revision by
Nuke Goldstein, Herve Caumont, Satish
Sankaran, Lacey Sharpe and Xavier Pons.

2010-02-01

Adrian Custer
and Joan Masó

Adrian Custer deeply detailed revision on
grammar and general consistency.

2010-02-14

Carl Reed

Additional edits in preparation for publication
as an OGC standard.

2010-03-09

Adrian Custer
and Joan Masó

Grammar and general consistency last details.
MIME type correction following 09-144r1.

Copyright © 2010 Open Geospatial Consortium Inc.

First draft as a discussion paper in the
WMS.RWG
Corrections proposed mainly by Dimitri Monieand Benjamin Chartier.
Merged OGC 07-057r1 and OGC 07-085r1
into a unified document.
Now proposes Web Map Tiling Service as aseparate service rather than as a profile of
WMS; introduced GetLegendGraphic and
GetAlternateSources operations.

ix

OGC 07-057r7

vi.

Changes to the OGC Abstract Specification

The OpenGIS® Abstract Specification does not require changes to accommodate thetechnical contents of this standard.

vii.

Changes to OpenGIS® Implementation Standards

This document defines an OGC implementation standard called "OpenGIS® Web Map
Tile Service Implementation Standard". This standard references the OGC Web Services
Common Specification, version 1.1.0 (with Corrigendum 1). No other implementation
standard should be affected.

viii.

Future work

Add support for OWS Common 1.2 (approved late 2009). Several additions planned in
OWS Common 1.2 [06-121r8] could potentially impact this standard and need to beevaluated.
Follow future guidance for resource oriented architectural (ROA) style that is expected to
be defined in future versions of OWS Common.

x

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Foreword
The Web Map Tile Service (WMTS) described in this standard builds on earlier efforts todevelop scalable, high performance services for web based distribution of cartographic
maps. WMTS is inspired by the OSGeo Tile Map Service Specification (available at
http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification). The team that workedon this standard also considered similar initiatives, such as Google maps and NASA
OnEarth. This OGC standard includes both resource (RESTful approach) and procedureoriented architectural styles (KVP and SOAP encoding) in an effort to harmonize thisinterface standard with the OSGeo specification.
WMTS complements earlier efforts to develop services for the web based distribution of
cartographic maps. The OGC WMTS provides a complementary approach to the OGC
Web Map Service (WMS) for tiling maps. WMS focuses on rendering custom maps andis an ideal solution for dynamic data or custom styled maps (combined with the OGC
Style Layer Descriptor (SLD) standard). WMTS trades the flexibility of custom map
rendering for the scalability possible by serving of static data (base maps) where thebounding box and scales have been constrained to discrete tiles. The fixed set of tiles
allows for the implementation of a WMTS service using a web server that simply returns
existing files. The fixed set of tiles also enables the use of standard network mechanisms
for scalability such as distributed cache systems.
This standard has been structured as a stand alone standard (relying on OpenGIS Web
Service Common Implementation Specification OGC 06-121r3 as a base document) but
shares many concepts with the WMS 1.3.0.
This document replaces any previous versions of OGC 07-057 that were released as OGC
Discussion Papers.
This document includes 7 annexes; Annexes A, B and F are normative, and Annexes C,
D E and G are informative.
Attention is drawn to the possibility that some of the elements of this document may be
the subject of patent rights. The Open Geospatial Consortium Inc. shall not be held
responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of
any relevant patent claims or other intellectual property rights of which they may beaware that might be infringed by any implementation of the standard set forth in thisdocument, and to provide supporting documentation.

Copyright © 2010 Open Geospatial Consortium Inc.

xi

OGC 07-057r7

Introduction
This Web Map Tile Service (WMTS) Implementation Standard provides a standard based
solution to serve digital maps using predefined image tiles. The service advertises thetiles it has available through a standardized declaration in the ServiceMetadata document
common to all OGC web services. This declaration defines the tiles available in eachlayer (i.e. each type of content), in each graphical representation style, in each format, ineach coordinate reference system, at each scale, and over each geographic fragment of
the total covered area. The ServiceMetadata document also declares the communication
protocols and encodings through which clients can interact with the server. Clients caninterpret the ServiceMetadata document to request specific tiles.
The WMTS standard complements the existing Web Map Service standard of the OGC.
The WMS standard focuses on flexibility in the client request enabling clients to obtain
exactly the final image they want. A WMS client can request that the server creates a
map by overlaying an arbitrary number of the map layers offered by the server, over anarbitrary geographic bound, with an arbitrary background color at an arbitrary scale, inany supported coordinate reference system. The client may also request that the map
layers be rendered using a specific server advertised style or even use a style provided by
the client when the WMS server implements the OGC Styled Layers Descriptor (SLD)
standard. However, all this flexibility comes at a price: server image processing must
scale with the number of connected clients and there is only limited potential to cache
images between the server and client since most images are different.
As web service clients have become more powerful, it has become possible to consider
an alternative strategy which forces the clients to perform image overlays themselves andwhich limits the clients to requesting map images which are not at exactly the rightposition thereby forcing the clients to mosaic the tiles obtained from the server and clip
the set of tiles into a final image. This restriction of image requests to a fixed, predefined
set allows for servers to scale based on communication processing abilities rather than
image processing abilities because servers can prerender some or all of their images andcan use image caching strategies. The fixed set of images also enables network providers
to cache images between the client and the server, reducing latency and bandwidth use.
Popular, non standardized, commercial implementations of this approach, such as Google
Maps, Microsoft Virtual Earth and Yahoo! Maps have already shown that there are clear
performance benefits to adopting this methodology.
Some WMS servers have already embarked on this road, developing their own tiling
structures built by constraining WMS GetMap requests to a fixed set and then advertisingthose constraints in their service metadata. Although this mechanism enables thoseservers to scale as just described, the tiling structure and the advertising and discovery
mechanisms are not standardized. That unfortunately limits interoperability and forcesdevelopers to build, for each server, special clients that can understand the server
advertised constraints and limit the WMS GetMap requests issued by the client to exactlyxii

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

the requests understood by the particular server. This WMTS standard offers astandardized approach to declaring the images which a client can request from a server,
enabling a single type of client to be developed for all servers. While developing a profile
of WMS was initially considered, limiting a WMS in the ways important to allow
efficient access to cacheable tiles proved awkward while forcing implementors to read
both a standard and a profile seemed less efficient than developing this stand alone
specification.
This standard specifies WMTS in two stages. First, an abstract specification describes thesemantics of the resources offered by the servers and requested by the client. This
abstract definition specifies the semantics of the ServiceMetadata document, of the Tile
images or representations, and of the optional FeatureInfo documents providing
descriptions of the maps at specific locations. Second, this standard specifies several
different concrete exchange mechanisms between clients and servers in two different
architectural styles. The standard defines the GetCapabilities, GetTile and optional
GetFeatureInfo operations for procedure oriented architectural style based approaches
using several different message encodings, including messages encoded using Key-Value
Pairs (KVP), XML messages, or XML messages embedded in SOAP envelopes. The
standard also defines the request mechanisms and endpoint publishing strategy to enable
a resource oriented architectural style based on web based URL endpoints allowing
clients to simply request the ServiceMetadata, Tile, and FeatureInfo resources as
documents.
This resource oriented architecture style is new to the OGC but offers key advantages inease of deployment, scalability and network effects of OGC web services. The RESTful
pattern provides the ability to set up conformant WMTS servers simply. If all the images
are prerendered, a WMTS server could even be created using no image processing logic
at all but relying only on a normal web server to return the static ServiceMetadata XML
document and provide the image tile files. This is important for deployment purposes as
many Internet service providers (especially the free ones) allow web pages and static
content hosting but do not allow using CGI, ASP, or more advanced applications forsecurity reasons. The RESTful approach therefore enables small organizations to provide
geographic data using readily available services or simple web server configurations.
This approach also scales dramatically since the issues of serving fixed resources in highvolumes have been continuously tackled over the past decades. Finally, this approach canbenefit from network scaling effects since the images are considered by the HTTP
protocol to be standard web resources and network providers can leverage their existing
technologies to improve the flow of those resources to requesting clients.

Copyright © 2010 Open Geospatial Consortium Inc.

xiii

OpenGIS® Implementation Standard

OGC 07-057r7

OpenGIS® Web Map Tile Service Implementation Standard

1

Scope

This OGC® document specifies an interface standard called "OpenGIS® Web Map Tile
Service Implementation Standard" (WMTS).
This OGC® document is applicable to servers and clients that can serve and consume
rendered tile maps. It can be combined with other OGC standards and also integrated
with the emerging RESTful applications and "mash-ups".
2

Compliance

Compliance with this standard SHALL be checked using all the relevant tests specified in
Annex A (normative).
3

Normative references

The following normative documents contain provisions that, through reference in thistext, constitute provisions of this document. For dated references, subsequent
amendments to, or revisions of, any of these publications do not apply. For undated
references, the latest edition of the normative document referred to applies.
ISO 19105:2000, Geographic information — Conformance and Testing
OGC 06-121r3, OpenGIS® Web Services Common Specification, version 1.1.0 withCorrigendum 1, Arliss Whiteside, ed.,NOTE This OWS Common Specification contains a list of normative references that are also
applicable to this Implementation Specification.

W3C SOAP Version 1.2 Part 1: Messaging Framework, W3C Recommendation 24 June
2003,
W3C SOAP 1.2 Attachment Feature, W3C Working Group Note 8 June 2004,
W3C Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001,
In addition to this document, this standard includes, as normative, several XML Schema
Document files as described in Annex B.

Copyright © 2010 Open Geospatial Consortium Inc.

1

OGC 07-057r7

4

Terms and definitions

For the purposes of this standard, the definitions specified in clause 4 of the OWS
Common Implementation Specification [OGC 06-121r3] and SHALL apply. In addition,
the following terms and definitions apply.
4.1

coordinate reference systemcoordinate system that is related to the real world by a datum
4.2

coordinate system
set of mathematical rules for specifying how coordinates are to be assigned to points
4.3

featureabstraction of a real world phenomenon
4.4

feature info
information related to a particular pixel of a map that refers to the geographic data
portrayed on that area
4.5

layer
basic unit of geographic information that may be requested as a map from a server
4.6

map
portrayal of geographic information as a digital image file suitable for display on acomputer screen
4.7

portrayal
graphical presentation of information to humans
4.8

procedure oriented architectural styleplatform-independent design approach that is focused on operations, their parameters andtheir results, that can be defined in an abstract level specification. Concrete platformdependent specifications can be derived from the abstract level, allowing, for example,
KVP or SOAP messaging.
4.9

resource oriented architectural styleplatform-independent design approach that is focused on resources, representations andactions, that can be defined in an abstract level specification. Concrete platformdependent specifications can be derived form the abstract level, allowing, for example, a
RESTful architecture.
2

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7
4.10

theme
a group layers that can be nested hierarchically
4.11

tile
a rectangular pictorial representation of geographic data, often part of a set of suchelements, covering a spatially contiguous extent and sharing similar information content
and graphical styling, which can be uniquely defined by a pair of indices for the column
and row along with an identifier for the tile matrix.
4.12

tile matrix
a collection of tiles for a fixed scale
4.13

tile matrix set
a collection of tile matrices defined at different scales
5

Conventions

5.1

Abbreviated terms

Most of the abbreviated terms listed in subclause 5.1 of the OWS Common
Implementation Specification [OGC 06-121r3] apply to this document, plus the following
abbreviated terms.
ASP

Active Server Pages

CGI

Common Gateway Interface

JPEG

Joint Photographic Experts Group (image format)

JPIP

JPEG 2000 Interactive Protocol

PNG

Portable Network Graphics (image format)

REST

Representational State Transfer

SLD

Styled Layer Descriptor

SOAP

Simple Object Access Protocol

WMTS

Web Map Tile Service

WSDL

Web Services Description Language

Copyright © 2010 Open Geospatial Consortium Inc.

3

OGC 07-057r7
5.2

UML notation

Most diagrams that appear in this standard are presented using the Unified Modeling
Language (UML) static structure diagram, as described in subclause 5.2 of OWS
Common [OGC 06-121r3].
5.3

Used parts of other documents

This document uses significant parts of document [OGC 06-121r3], herein referred to as"OWS Common". To reduce the need to refer to that document, this document copies
some of those parts with small modifications. In tables and figures, to indicate those parts
to readers of this document, the largely copied parts are shown with a light grey 15%
background.
5.4

Platform-neutral and platform-specific standards

As specified in clause 10 of OGC Abstract Specification Topic 12 ―OpenGIS Service
Architecture‖ (which contains ISO 19119), this document includes both Distributed
Computing Platform-neutral and platform-specific standards. This document first
specifies the resources in each operation request and response in platform-neutral fashion.
This is done using a table for each data structure, which lists and defines the parameters
and other data structures contained. These tables serve as data dictionaries for the UML
model in Annex C, and thus specify the UML model data type and multiplicity of eachlisted item.
NOTE 1

Platform-neutral standards are contained in clause 7.

The specified platform-neutral data could be encoded in many alternative ways, eachappropriate to one or more specific Distributed Computing Platform. This document
currently specifies encodings appropriate for HTTP GET transfer of operations requests(using KVP or RESTful encodings), and for HTTP POST transfer of operations requests(using XML or SOAP encodings). However, the same operation requests and responses(and other data) could be encoded for other specific computing platforms, including
HTTP POST transfer of raw XML requests.
NOTE 2 Platform-specific standards for KVP, SOAP and RESTful are contained in clause 8, 9 and 10
respectively.

5.5

UML graphical and table representations

The UML model data is specified herein in a series of tables, called data dictionary
tables. The contents of the columns in these tables are described in Table 1.

4

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Table 1 — Contents of data dictionary tables
Column title
Names(left column)

Definition(second column)

Data type and values(third column)

Multiplicity and use(right or fourthcolumn)Column contents
Two names for each included parameter or association (or data structure).
The first name is the UML model attribute or association role name.
The second name is the XML encoding of the parameter name. It is shown inmonospaced font.
Some names in the tables may appear to contain spaces, but no names containspaces.
Specifies the definition of this parameter (omitting un-necessary words such as―a‖, ―the‖, and ―is‖). If the parameter value is the identifier of something, nota description or definition, the definition of this parameter reads something
like ―Identifier of …‖.
The first item is the data type used for this parameter, using data types or a data
structure appropriate in a UML model, in which this parameter is a named
attribute of a UML class. Alternately, the first item can identify the data
structure (or class) referenced by this association, or references a separate
table used to specify the contents of that class (or data structure).
The second item indicates the source of values for this parameter, thealternative values, or other value information, unless the values are quite clear
from other listed information.
The first item specifies the multiplicity and optionally of this parameter in thisdata structure, either ―One (mandatory)‖, ―One or more (mandatory)‖, ―Zeroor one (optional)‖, or ―Zero or more (optional)‖.
The second item specifies how any multiplicity other than ―One (mandatory)‖
will be used.

When the data type used for this parameter, specified in the third column of such a table
is an enumeration or code list, all the values specified by this document are listed,
together with the meaning of each value. When this information is extensive, these values
and meanings are specified in a separate table that is referenced in the third column of thetable row where the parameter is defined.
NOTE
Several parameters have their data type specified in the third table column as ―Character String
type, not empty‖. In the XML Schema Documents specified herein, these parameters are encoded with thexsd:string type, an XML type which does not require that these strings not be empty. Nonetheless, theinjunction of the table SHALL prevail and the element SHALL not be empty

The contents of these data dictionary tables are normative, including any table footnotes.
Particularly, the ―Multiplicity and use‖ columns in Table 6 through Table 16 in OWS
Common [OGC 06-121r3], and in Table 2, 3 and Table 5 through Table 16 of thisdocument, specify the optionality of each listed parameter and data structure in theServiceMetadata document. Also, ―Multiplicity and use‖ columns of this document inTable 22 specify the optionality of each listed parameter and data structure in the GetTile
operation request and in Table 25 specify the optionality of each listed parameter anddata structure in the GetFeatureInfo operation request. All the ―mandatory‖ parametersand data structures SHALL be implemented by all WMTS clients, using a specified
value(s). Similarly, all the ―mandatory‖ parameters and data structures SHALL be
implemented by all WMTS servers, checking that each request parameter or data
structure is received with the specified value(s). All the ―optional‖ parameters and data
structures in the operation requests SHOULD be implemented by all WMTS clients using

Copyright © 2010 Open Geospatial Consortium Inc.

5

OGC 07-057r7

specified values, for each implemented layer to which that parameter or data structure
applies. Similarly, all the ―optional‖ parameters and data structures SHALL be
implemented by all WMTS servers, for each implemented layer to which that parameteror data structure is declared to apply by the server in the ServiceMetadata document.
6

WMTS overview

The goal of providing a WMTS enabled service is to be performance oriented andscalable. Therefore, servers must be able to return tiles quickly. A good way to achievethat is to use locally stored pre-rendered tiles that will not require any image
manipulation or geo-processing. Server developers will decide if pre-rendered tiles will
be generated in a previous tile-preparation process or generated on the fly utilizing acaching mechanism. With tile-based mapping it is important that the server will be able
to handle asynchronous access to tiles as most clients will simultaneously query for
multiple tiles to fill a single view.
The purpose of a WMTS service is to serve maps divided in individual tiles.
The WMTS interface allows a client to receive three types of resources either in response
to a resource request in the resource oriented architectural style or in response to an
operation in the procedure oriented architectural style. Those resources and operations
are:a) A ServiceMetadata resource (in response to a GetCapabilities operation for theprocedure oriented architectural style) (required implementation by servers) – It
describes the abilities and information holdings of the specific server
implementation. In procedure oriented architectural style this operation also supports
negotiation of the standard version being used for client-server interactions.
b) A tile resource (in response to a GetTile operation for the procedure oriented
architectural style) (required implementation by servers) – It shows a fragment of amap representation of a layer.
c) A FeatureInfo resource (in response to a GetFeatureInfo operation for the procedureoriented architectural style) (optional implementation by servers) – It provides
information about the features located at a particular pixel of a tile map, in a similar
way to the WMS GetFeatureInfo operation, by providing, for example, the thematic
attribute name and value pairs in textual form.
These operations have many similarities to other OGC Web Services (OWS), including
the Web Map Service (WMS), Web Feature Service (WFS), and Web Coverage Service(WCS). Many of the aspects of this WMTS interface that are shared in common withother OWSs are specified in the OpenGIS® Web Services Common Implementation
Specification [OGC 06-121r3]. Many of these common aspects are included normatively
by reference to that document, instead of being repeated in this standard.

6

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Figure 1 is a simple UML diagram summarizing the WMTS interface for the procedureoriented architectural style. This class diagram shows that the WMTS interface classinherits the getCapabilities operation from the OGCWebService interface class, and adds
the getTile and getFeatureInfo operations. (This capitalization of names uses the
OGC/ISO profile of UML.) A more complete UML model of the WMTS interface isprovided in Annex C (informative).

<<Interface>>
OGCWebService {Abstract}(from OGC Web Service)+ getCapabilities(request : GetCapabilities) : ServiceMetadata

WMTService+ getTile(request : GetTile) : Tile Response+ getFeatureInfo(request : GetFeatureInfo) : FeatureInfo Response

Each server instance conceptually instantiates only one objectof this class, and this object always exists while server isavailable

Figure 1 — WMTS interface UML diagram
NOTE
In this UML diagram, the request and response for each operation is shown as a single
parameter that is a data structure containing multiple lower-level parameters, which are discussed insubsequent clauses. The UML classes modeling these data structures are included in the complete UML
model in Annex C.

The WMTS serves a single tile of a single layer of a map. Unlike WMS, there is no
specified way to request a server to combine and return a map tile with information
coming from more than one layer in a single fetching process. WMTS clients that want toshow a combination of layers must make independent requests for the layer tiles and then
combine or overlay the responses. Also bounding boxes and scales of these WMTS tiles
are constrained to a discrete set of values.
6.1

Tile matrix set – the geometry of the tiled space

In a tiled map layer, the representation of the space is constrained in a discrete set ofparameters. A tile matrix set defines these parameters. Each tile matrix set contains one
or more "tile matrices" defining the tiles that are available for that coordinate reference
system. Each tile matrix specifies:

Copyright © 2010 Open Geospatial Consortium Inc.

7

OGC 07-057r7a) The scale of the tiles as a scale denominator.
The scale denominator is defined with respect to a "standardized rendering pixel size" of0.28 mm × 0.28 mm (millimeters). The definition is the same used in WMS 1.3.0 [OGC
06-042] and in Symbology Encoding Implementation Specification 1.1.0 [05-077r4].
Frequently, the true pixel size is unknown and 0.28 mm is a common actual size forcurrent displays.
b) The width and height of each tile in pixels.
c) The top left (minimum x, maximum y) corner of the bounding box of the tile matrix(i.e., the CRS coordinates of the top left corner of the top left pixel of the top left tile).
d) The width and height of the tile matrix in tile units (i.e., number of tiles).
The number of tile matrix sets that a WMTS server serves for a particular layer is:nTileMatrices × nTiledStyles × nTiledFormats
if no dimensions are defined or:nTileMatrices × nTiledStyles × nTiledFormats × nTiledDimensions
if dimensions are defined. The number of distinct tiles within each tile matrix of a tile
matrix set (i.e., for a particular scale within a tile-matrix set) is a product of:matrixWidth × matrixHeight
Each tile matrix set defines its own set of scale levels corresponding with the contained
tile matrices. Each layer references one or more tile matrix sets. Although each layer
could reference a different tile matrix set, it is likely that a server will offer many layerswith the same tile matrix set reference.
A tile matrix set is composed of a collection of tile matrices, each one with a resolution
optimized for a particular scale and identified by a tile matrix identifier (see figure 3).
Each tile matrix set has an optional approximated bounding box but each tile matrix has
an exact bounding box that is deduced indirectly from other parameters. Tile matrix
bounding boxes at each scale will usually vary slightly due to pixel alignment, and it isimportant for the client and server to take this variation into account. Given the top left
point of the tile matrix in CRS coordinates (tileMatrixMinX, tileMatrixMaxY), the widthand height of the tile matrix in tile units (matrixWidth, matrixHeight), the width andheight of a tile in pixels (tileWidth, tileHeight), the coefficient to convert the coordinate
reference system (CRS) units into meters (metersPerUnit) and the scale(1:scaleDenominator), the bottom right corner of the bounding box of a tile matrix(tileMatrixMaxX, tileMatrixMinY) can be calculated as follows:
pixelSpan = scaleDenominator × 0.28 10-3 / metersPerUnit(crs);
tileSpanX = tileWidth × pixelSpan;

8

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

tileSpanY = tileHeight × pixelSpan;
tileMatrixMaxX = tileMatrixMinX + tileSpanX × matrixWidth;
tileMatrixMinY = tileMatrixMaxY - tileSpanY × matrixHeight;
The tile space therefore looks like this:TileMatrixMinX
TopLeftCorner

Tile indices(TileCol,TileRow)

TileMatrixMaxX

TileMatrixMaxY

TileCol axis
0,0

1,0

...

MatrixWidth-1,0

0,1

1,1

...

MatrixWidth-1,1

...

...

...

...

...

MatrixWidth-1,
MatrixHeight-1

0,
TileMatrixMinY

1,

MatrixHeight-1 MatrixHeight-1

TileHeight(in pixels)

TileWidth(in pixels)

TileRow axis

Figure 2 — Tile Space
Each tile in a tile matrix is identified by its TileCol and TileRow indices that have their0,0 origin in the tile next to the top left corner of the tile matrix and that increases
towards the right and towards the bottom respectively, as shown in figure 2. Annex H inthis document includes pseudo code that illustrates the process for obtaining the tile
indices that cover a bounding box rectangle and also the computation to get the CRS
coordinates that bound a tile.
NOTE 1 Non-square pixels are not supported. This is different from WMS, which does allow nonsquare pixels (although many implementations fail to support this properly).

A tiled layer links to its tile matrix set through a tileMatrixSet URI that points to a
TileMatrixSet section that completely defines it as previously explained. A layer can use
a specific TileMatrixSet that describes a region adjusted to the actual content of thislayer. In this case, the optional tileMatrixSetLimits section will not be used and changes
in spatial extension of the layer can affect the minimum bounding box of the layer
forcing to redefine the TopLeftCorner of each TileMatrix and that will end up changing
the TileCol,TileRow indices thereby invalidating any previously cached tile. To

Copyright © 2010 Open Geospatial Consortium Inc.

9

OGC 07-057r7

overcome this problem a layer can optionally use a more generic TileMatrixSet thatcovers a bigger (or even global) area. In fact, that TileMatrixSet will define an area that
could be covered by the layer in a future and could easily be shared for many layers inthis server. To inform the client about the valid range of the TileCol and Tile Row indicesa layer definition can optionally use the tileMatrixSetLimits section that specifies aminimum and a maximum that are limits of these indices for each TileMatrix. Anyrequest outside these limits will result in a server exception (see Figure 6).

Coarse resolution
Highest scale denominator

Detailed resolution
Lowest scale denominator

Figure 3 — Tile Matrix Set representation
In some other standards, this way of dividing the space is called image pyramid like inclause 11.6 of the KML 2.2 [OGC 07-147r2]. JPEG2000 (ISO/IEC 15444-1) and JPIP
(ISO/IEC 15444-9) also use a similar division of the space called resolution levels.
Nevertheless, in those cases the pyramid is self defined starting from the more detailed
tile matrix that uses square tiles, and constructing tiles of the next scales by successively
aggregating 4 tiles of the previous scale and so on. That approach involves a more rigid
structure which has scales related by powers of two and tiles that perfectly overlap tiles
on the inferior scale denominators. Since WMTS is more flexible, KML superoverlays or
JPEG2000 based implementations can still use WMTS to describe their tile matrix sets
and to serve tiles. Annex E.3 and E.4 describe scale sets related by powers of two.
Each of the WMTS procedure oriented architectural style operations and resource
oriented architectural style resources are described in more detail in subsequent clauses.
NOTE 2 Clients and servers have to be careful when comparing floating numbers with tolerance (double
precision, 16 digit numbers, has to be used).

6.2

Well-known scale sets

Since a WMTS server will serve its data in a limited number of coordinate systems andscales (because, unlike a WMS, it serves only pre-defined tiles), and since some simple
10

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

WMTS client will be unable to perform coordinate-system transformations or rescalingof tiles, the ability for a WMTS client to overlay tiles from one server on top of tiles fromother 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 setof scales. Thus, this standard defines the concept of well-known scale sets. In order toincrease 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 verifyingthat 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, aclient 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 theodds 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 thewell-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 modelThis clause describes the WMTS resources that can be requested by a client from a serverin 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 inclause 10.
7.1Service metadataThis subclause describes the ServiceMetadata document and the way in which it may beobtained using either a procedure oriented architectural style or a resource oriented
architectural style.

Copyright © 2010 Open Geospatial Consortium Inc.

11

OGC 07-057r7
7.1.1

ServiceMetadata document

The ServiceMetadata document is the response document of a GetCapabilities request inprocedure oriented architectural style or of a standard request to the right endpoint in aresource oriented architectural style. It is the entry point resource that represents theresources 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 thevalues in the Sections parameter of the GetCapabilities operation request in the procedureoriented architectural style (see subclause 7.1.2.1), any combination of these sections canbe requested and SHALL be returned when requested except if the service does notsupport requests for sub-sections of the ServiceMetadata document.
Capabilities (Abstract)(from OWS Get Capabilities))+ version : CharacterString+ updateSequence [0..1] : CharacterString+ wsdl [0..1]: URL+ serviceMetadataURL [0..1]: URL
1+serviceIdentification

1

1

1

0..1

1
0..* +themes

ServiceIdentification

Themes(from OWS Service Identification)(from WMTS GetCapabilities)+operationsMetadata

0..1

0..1

+contents

OperationsMetadata

Contents(from OWS Operations Metadata)(from OWS contents)+serviceProvider

0..1

ServiceProvider(from OWS Service Provider)Figure 4 — ServiceMetadata UML model

12

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Table 2 —ServiceMetadata sections
Section nameContents
ServiceIdentification Metadata about this specific server. The schema of this section SHALL be
the same as for all OWSs, as specified in subclause 7.4.3 andowsServiceIdentification.xsd of OWS Common [OGC 06-121r3].
ServiceProvider
Metadata about the organization operating this server. The schema of thissection SHALL be the same for all OWSs, as specified in subclause 7.4.4
and owsServiceProvider.xsd of OWS Common [OGC 06-121r3].
OperationsMetadata Metadata about the operations specified by this service in procedureoriented architectural style and implemented by this server, including the
URLs for operation requests. The basic contents and organization of thissection is the same as for all OWSs, as specified in subclause 7.4.5 andowsOperationsMetadata.xsd of OWS Common [OGC 06-121r3].
Contents
Metadata about the data served by this server. For the WMTS, this section
SHALL contain data about layers and TileMatrixSets, as specified inTables 5 through 14 below.
ThemesMetadata describing a theme hierarchy for the layers, as specified in Tables
15 and 16 below.

The ServiceIdentification and ServiceProvider sections are described on subclause 7.4.4
and 7.4.5 of OWS Common [OGC 06-121r3]. The OperationsMetadata, Contents andThemes sections are described in subclauses 7.1.2.1, 7.1.2.2 and 7.1.2.3 of this document.
In addition to these sections, each service metadata document SHALL include themandatory "version" parameter and can optionally include "updateSequence" parameter
specified in Table 9 in subclause 7.4.2 of OWS Common [OGC 06-121r3] and copied
below. Finally, "WSDL" and "serviceMetadataURL" parameters are only needed forservers using specific encodings.
Table 3 — Parts of the Capabilities data structureNamesversionversionupdateSequence
updateSequence

WSDL
WSDL

Definition
Standard version for
operation, in this casefor GetCapabilities
operation response
Service metadata
document version, value
is ―increased‖ wheneverany change is made incomplete service
metadata document
Reference to a WSDL
resource

Copyright © 2010 Open Geospatial Consortium Inc.

Data type and values
Character String type, notempty.
Value is list of x.y.z―version‖ values.
SHALL be "1.0.0"
Character String type, not
empty
Values are selected byeach server, and arealways opaque toclients
URL type

Multiplicity and use
One (mandatory)

Zero or one(optional)
Omitted whenparameter notsupported by server
Zero or more
(optional)
Only for SOAP
encoding

13

OGC 07-057r7

Names
service
MetadataURL
Service
MetadataURL

serviceIdentification
Service
Identification

serviceProvider

operationsMetadata

contents

Data type and values
URL type

Metadata about thisspecific server

ServiceIdentification
section, see Table 11 of
OWS Common [OGC
06-121r3]
ServiceProvider section,
see Table 12 of OWS
Common [OGC 06121r3]
OperationsMetadata
section, see Table 13 of
OWS Common [OGC
06-121r3]
Contents section, see
Table 5

Metadata about theorganization operating
this server.

ServiceProvider

Operations
Metadata

Definition
Reference to a
ServiceMetadata
resource

Metadata about theoperations specified bythis service
Metadata about the dataserved by this server.

Contents

themesMetadata describing atheme hierarchy for thelayers

Themes

Themes section, see
Table 15

Multiplicity and use
Zero or more
(optional)
Mandatory inresource oriented
architectural style
Zero or one(optional)

Zero or one(optional)

Zero or one(optional)

Zero or one(optional)
Zero or more
(optional)

Parameters "version", and "updateSequence" are described in subclause 7.4.2 of OWS
Common [OGC 06-121r3]. Parameters "WSDL" and "serviceMetadataURL" aredescribed in Annex F2 and subclause 010.1.1 of this document.
7.1.1.1.1

OperationsMetadata section contents

The OperationsMetadata section is the same as for all OGC Web Services, as specified in
subclause 7.4.6 and owsOperationsMetadata.xsd of OWS Common [OGC 06-121r3]. It isonly relevant in the procedure oriented architectural style. The parameters are specified inTable 4 bellow. In Table 4, the ―Name‖ column uses dot-separator notation to identify
parts of a parent item. The ―Value‖ column references an operation parameter, in thiscase an operation name, and the meaning of including that value is listed in the rightcolumn.
Table 4 — Values of OperationsMetadata section parameters
Name

Value

Meaning of parameter value

Operation.name

GetCapabilities

The GetCapabilities operation is implemented by this server.

GetTileThe GetTile operation is implemented by this server.

GetFeatureInfo

The GetFeatureInfo operation is implemented by this server.

In addition to the values listed in Table 4, there are many optional values of the ―Name‖attributes and ―Value‖ parameters in the OperationsMetadata section, which MAY be

14

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

included when considered useful. Most of these attributes and parameters are forrecording the domains of various operation parameters and quantities.
The Operation data type allows specifying distributed computing platform (DCP)
parameters and the encoding of this DCP as a Constraint within the DCP parameter.
All WMTS servers operating in a procedure oriented architecture style and using HTTP
SHALL specify with an ows:Constraint parameter the encodings that MAY be sent using
HTTP GET or HTTP POST. Each operation can support more than one encoding and theset of supported encodings CAN be different for each operation (but this is discouraged
since it is not usually expected).
All WMTS servers operating in a procedure oriented architecture style and using HTTP
SHALL specify the message encodings that MAY be sent using HTTP GET transfer ofoperation requests. Specifically, an ows:Constraint parameter SHOULD be included,with ―GetEncoding‖ as the value of the ―name‖ attribute and specifying the values
allowed:a) The value ―KVP‖ indicates that KVP encoding is allowed, when using HTTP
GET transfer as specified in clause 8.
Also, all WMTS servers operating in a procedure oriented architecture style and using
HTTP SHALL specify the message encodings that MAY be sent using HTTP POST
transfer of operation requests. Specifically, an ows:Constraint parameter SHALL be
included, with ―PostEncoding‖ as the value of the ―name‖ attribute and specifying thevalues allowed:a) The value ―SOAP‖ shall indicate that SOAP encoding is allowed, as specified inclause 9.
b) The value ―XML‖ shall indicate that XML encoding is allowed (without SOAP
message encapsulation).
c) The value ―KVP‖ shall indicate that KVP encoding is allowed, when using
HTTP POST transfer.
If the HTTP connection point URL is different for different encodings of the operation
requests, the URL SHALL be specified in an ows:Constraint parameter in each Get or
Post section. If the connection point URL is the same for all encodings of all operation
requests, this ows:Constraint parameter SHALL be included in the OperationsMetadata
section. The constraint names and values presented in this subclause are the actual exact
names and values that SHALL be used for each encoding explained and are not justexamples.
Resource oriented architecture style HTTP encodings SHALL not be described in the
OperationsMetadata section. Instead, the service metadata document provided by servers
operating in a resource oriented architectural style SHALL use ResourceURL andServiceMetadataURL to indicate support for that architectural style, as is explained inclause 10.
Copyright © 2010 Open Geospatial Consortium Inc.

15

OGC 07-057r7
7.1.1.1.2

Contents section contents

The Contents section of a ServiceMetadata document contains metadata about the dataserved by this server. For the WMTS, this Contents section contains a general descriptionof the layers available and descriptions of the extra dimensions, styles, image formats andtile matrix sets that apply to each layer. The Contents section SHALL include parameters
as specified in Table 5 through Table 14.
Contents(from OWS Contents)+ otherSources [0..*] : URL
1

1

0..*

DatasetDescriptionSummary+layerLayer+tileMatrixSet

1..*

TileMatrixSet

Figure 5 — Contents UML model
Table 5 through Table 12 define the components of the layer section and Table 13
through Table 14 define the components of the tile matrix set section of theServiceMetadata document. The UML class diagram in Figure 5 provides a usefulgraphical view of the composition of the Contents section.
The Contents section, described in Table 5, contains a list of layers available on theserver and a list of tileMatrixSets. Each layer links to a particular tileMatrixSet using areference to a tileMatrixSet identifier. Layers are described in Table 6 with a name, atitle, an abstract description, keywords, a WGS84BoundingBox, a tileMatrixSet
reference, a supported image format list, an infoFormat list, a metadata URL document
link, and an optional dimensions list. In addition, a layer has one or more map portrayal
representations that are called styles. Each style is described with a Style section as
detailed in Table 7 with a name, a title, an abstract and a list of legendURLs described inTable 8. Each legendURL provides an iconic representation of the layer in its style,suitable for display in a legend; it specifies the URL of the icon image, and optionally thewidth and height of the icon image and the range of scales for which the icon isappropriate, as described in Table 8. Optional dimensions of the layer are described inTable 9. Dimensions are described by an identifier, a title, an abstract, units and unit
symbols, a list of possible values and a default value. Typical examples of dimension
identifiers are "time", "elevation" and "band", but the service can define any otherdimension property that exists in the multidimensional layer collection being served.

16

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Table 5 — Parts of the Contents section
Names
layer
Layer

otherSource
OtherSource

tileMatrixSet
TileMatrix
SetaDefinition
Data type and values
Metadata describing one top- Layer data structure, seelevel dataset available from
Table 6this server
Reference to another sourceof contents metadata
A description of thegeometry of a tile cut

See
CI_OnlineResource classin ISO 19115
TileMatrixSet data
structure, see Table 13

Multiplicity and use
Zero or more
(optional) a
One for each dataset
available
Zero or more
(optional)
Zero or more
(optional)

SHALL be included unless Other Source parameter(s) are included and all this metadata is available from those sources.

The OtherSource parameter may reference one or more catalogue servers from whichdataset metadata is available. This ability is expected to be used by servers with a verylarge number of datasets, for which searching a catalogue is more feasible than retrieving
and then searching a very large ServiceMetadata XML document. When there is no Layer
section in the Contents section of the ServiceMetadata document, the otherSource
parameter SHALL reference one or more catalogue servers that contain current metadatasummaries for all the datasets currently available from this WMTS server, with themetadata for each dataset referencing this WMTS server.
The UML class diagram in Figure 6 provides a useful graphical view of the Layer section
with its properties, complex data types and dependencies.

Copyright © 2010 Open Geospatial Consortium Inc.

17

OGC 07-057r7

Description(from OWS Data Identitfication)+ title [0..*] : LanguageString+ abstract [0..1]: LanguageString

Contents(from OWS Contents)

1+ abstract [0..*] : LanguageString0..*+keywords+ otherSources [0..*] : URL

MD_Keywords

1(from ISO 19115 subset)+ keyword [1..*] : LanguageString0..*

DatasetDescriptionSummary+layerLayer+ identifier : CodeType+ format [1..*]: MimeType+ infoFormat [0..*]: MimeType+ resourceURL [0..*]: ResourceURLType10..* +boundaryBox

BoundingBox(From OWS Contents)11..*+style

1..*

1

1

1
1 +tileMatrixSetLink

TileMatrixSetLink<<DataType>>
Style+ tileMatrixSet [1..*]: URI+ identifier : CodeType+ title [0..1]: LanguageString+ abstract [0..1]: LanguageString+ keywords [0..*]: MD_Keywords+ isDefault [0..1]: Boolean

0..*+dimensions<<DataType>>
Dimensions

1+legendÜRL

+ identifier : CodeType+ title [0..1]: LanguageString+ abstract [0..1]: LanguageString+ keywords [0..*]: MD_Keywords+ UOM : DomainMetadata+ unitsSimbol : CharacterString+ default: CharacterString+ current: CharacterString+ value [1..*] : CharacterString

0..*<<DataType>>
LegendURL+ format : CharacterString+ minScaleDenominator: double+ maxScaleDenomnator: double+ onlineResource: URL+ width: integer+ height: integer

0..1 +WGS84BoundingBox+ metadata

Metadata(from OWS Common)+ metadata [0..1]: Any+ link [0..1]: URL+ about [0..1]: URI+ lowerCorner : Sequence <Number, 2>+ upperCorner : Sequence <Number, 2>+ crs [0..1]: URI+ dimensions [0..1] PositiveInteger

0..*

WGS84BoundingBox(From OWS Contents)

1
0..1 +tileMatrixSetLimits<<DataType>>
TileMatrixSetLimits
1
0..* + tileMatrixLimits

TileMatrixLimits+ tileMatrix: URI+ minTileRow: integer+ maxTileRow: integer+ minTileCol: integer+ maxTileCol: integer
TileMatrixSetLimits+ lowerCorner : Sequence <Number, 2>+ upperCorner : Sequence <Number, 2>+ crs [0..1]: "urn:ogc:def:crs:CRS::84"+ dimensions [0..1] PositiveInteger=2

Figure 6 — Layer UML model

18

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Table 6 — Parts of Layer data structure
Names
identifier a
Identifier

title cTitle

abstract c
Abstract

keywords c
Keywords

wgs84
BoundingBox
WGS84
BoundingBox

boundingBox
BoundingBox

style
Style

formatFormatinfoFormat
InfoFormat

dimension
Dimension

Definition
An unambiguous reference
to this layer, normallyused by software f
Title of this layer, normallyused for display to ahuman

Data type and values
ows:CodeType, as
adaptation of
MD_Identifier class ISO
19115
LanguageString data
structure, see Figure 15 in
OWS Common [OGC 06121r3]

Brief narrative description ofthis layer, normallyavailable for display to ahuman

LanguageString data
structure, see Figure 15 in
OWS Common [OGC 06121r3]

Unordered list of one ormore commonly used orformalised word(s) orphrase(s) used to describe
this dataset

MD_Keywords class in
ISO 19115

Minimum bounding
rectangle surrounding
dataset, using WGS 84
CRS with decimal degrees
and longitude before
latitude b
Minimum bounding
rectangle surrounding thelayer, in the supported
CRS g
Description of the style thathas been applied to thislayer
Supported valid output
formats for a tile request

WGS84Bounding Box data
structure see subclause
10.2 of OWS Common[OGC 06-121r3]

Supported valid output
formats for a FeatureInfo
document request
Extra dimensions for a tileand FeatureInfo resource
requests

Multiplicity and use
One (mandatory)

Zero or more
(optional) Include
when available andusefulInclude one for eachlanguage
represented e
Zero or more
(optional) Include
when available andusefulInclude one for eachlanguage
represented
Zero or more
(optional)
One for eachkeyword authority
used
Zero or one(optional)

BoundingBox data
structure, see subclause
10.2 of OWS Common[OGC 06-121r3]
Style data structure, see
Table 7

Zero or more
(optional)

ows:MimeType

One or more(mandatory)

ows:MimeType

Zero or more
(optional) d

Dimension data structure,see Table 9

Zero or more
(optional)
One for each extra
dimension
available.

Copyright © 2010 Open Geospatial Consortium Inc.

One or more(mandatory)

19

OGC 07-057r7

Names
metadata

Data type and values
ows:Metadata

Metadata

Definition
Additional metadata about
this dataset

tileMatrixSet
Link

Reference to a tileMatrixSet
and limits

TileMatrixSetLink data
structure, see Table 10

URL template to a tile or a
FeatureInfo resource

URLTemplate data
structure, see Table 31

Multiplicity and use
Zero or more
(optional)
One for each useful
metadata object
One or more(mandatory)

TileMatrix
SetLink

resourceURL
ResourceURL

Zero or more
(optional)
Include one or morein resource oriented
architectural styleaThis has the same meaning as "name" in WMS but has been replaced by "identifier" to harmonize with OWS CommonbThis WGS84BoundingBox can be approximate, but SHOULD be as precise as practical.

c

The multilingual scoping rules in subclause 10.7.3 of OWS Common [OGC 06-121r3] SHALL apply.

d If no infoFormats are specified, then the layer is not queryable (i.e., a request for a FeatureInfo is not permitted for thislayer)e

If no Title is specified, client may display the Identifier value instead.

fLayer identifies SHALL be unique (different) for each layer of this server

g It represents the area where this layer is represented. It could seem redundant with the bounding box of the tile matrix
set but in complex cases that limits the area with data using tileMatrixLimits it is not so easy to calculate form the tile matrix
set parameters.

The list of output formats SHOULD be chosen carefully. A long list of formats will
improve interoperability with clients but will reduce the effectiveness of cachingmechanisms. As a general rule, servers should use a short list, should avoid including
redundant formats in the list and should use the formats recommended in subclause 11.3.
NOTE 1 In WMTS the list of supported output formats can be different for each layer, in contrast with
WMS which specifies a shared single list of supported formats for all layers. WMTS layers have been
given this ability because different layers may have different optimal formats. The use of a shared single
list would force layers to be offered in all declared formats, reducing scalability and performance.
NOTE 2 The UML class diagram contained in the Annex C4 provides a useful graphical view of thecontents of the Contents section listed in Tables 6 - 16.

Table 7 — Parts of Style data structure
Names
identifieraIdentifier

title bTitle

20

Definition

Data type and values

Multiplicity and use

An unambiguous reference to thisstyle, identifying a specificversion when needed, normallyused by software dTitle of this style, normally used
for display to a human

ows:CodeType, as
adaptation of
MD_Identifier class
ISO 19115
LanguageString data
structure, see Figure
15 in OWS Common[OGC 06-121r3]

One (mandatory)

Zero or more
(optional) Include
when available andusefulInclude one for eachlanguage
represented c

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Names
abstractb

Abstract

keywords b
Keywords

legendURL
LegendURL

isDefault
isDefault

Definition

Data type and values

Multiplicity and use

Brief narrative description of thisstyle, normally available fordisplay to a human

LanguageString data
structure, see Figure
15 in OWS Common[OGC 06-121r3]

Unordered list of one or morecommonly used or formalisedword(s) or phrase(s) used todescribe this dataset

MD_Keywords class in
ISO 19115

Description of an image that
represents the legend of the map

LegendURL data
structure, see Table 8

The style that a client SHOULD
select as the first choice (default
style)

BooleanZero or more
(optional) Include
when available andusefulInclude one for eachlanguage
represented
Zero or more
(optional)
One for eachkeyword authority
used
Zero or more
(optional) Include
when available andusefulZero or one(optional)
Default is "false" eaThis has the same meaning as "name" in WMS but has been replaced by "identifier" to harmonize with OWS Common.

b

The multilingual scoping rules in subclause 10.7.3 of OWS Common [OGC 06-121r3] SHALL apply.

c

If no Title is specified, client may display the Identifier value instead.

dStyle identifies SHALL be unique (different) for each style of a particular layereOnly one style per layer can have a "true" value

A WMTS ServiceMetadata document may include zero or more LegendURL elements toprovide an image(s) of a legend relevant to each style of a layer. Clients can show thisimage to the user as a visual summary of the information rendered in the tiles. The legend
image should clearly represent the symbols, lines and colors used in the portrayal of thetiles and their meanings. The legend image should not contain text that duplicates the titleof the layer, because that information is known to the client and may be shown to the user
by other means.
Table 8 — Parts of LegendURL data structure
NamesformatformatminScale
Denominator
minScale
DenominatormaxScale
DenominatormaxScale
Denominator

href
href

Definition
A supported output format for
the legend image

Data type and values
ows:MimeTypeMultiplicity and use
One (mandatory)

Minimum scale denominator(inclusive) for which thislegend image is valid

Double type, not
empty

Zero or one (optional)
Include whenavailable and useful a

Maximum scale denominator(exclusive) for which thislegend image is valid

Double type, not
empty

Zero or one (optional)
Include whenavailable and useful a

The URL from which the legend
image can be retrieved

URL type

One (mandatory)

Copyright © 2010 Open Geospatial Consortium Inc.

21

OGC 07-057r7

Names
width
width

heightheightDefinition
Width (in pixels) of the legend
image

Data type and values
Positive integer typenot empty

Height (in pixels) of the legend
image

Positive integer typenot empty

Multiplicity and use
Zero or one (optional)
Include whenavailable and useful
Zero or one (optional)
Include whenavailable and usefula The minScaleDenominator and maxScaleDenominator define the range of scales where this legend is valid.
The absence of a minScaleDenominator parameter means there is no minimum scale denominator to thecondition or logically that the default value is 0. The absence of a maxScaleDenominator parameter means that
there is no maximum scale denominator to the condition or logically that the default value is infinity. The
absence of both scale parameters in LegendURL metadata means that there is no scale constraint and that the
LegendURL is applicable to the style at all scales. General considerations about the meaning of
minScaleDenominator and maxScaleDenominator values and their pixel size equivalences as explained in
subclause 6.1 also apply here.

In case of multi-dimensional data, the service metadata can describe their multidimensionality and tiles can be requested at specific values in these dimensions.
Examples of dimensions are Time, Elevation and Band. Optional parameters in WMTS
service metadata declare available values along one or more dimensional axes applicable
to a Layer. GetTile and GetFeatureInfo requests for that layer should include parametersspecifying dimensional value(s).
Table 9 — Parts of Dimension data structure
Names
identifiera

Definition
A name of dimensional axis e

Identifier

title b
Title

abstract b
Abstract

keywordsb
Keywords

22

Title of this dimension, normallyused for display to a human

Data type and values
ows:CodeType, as
adaptation of
MD_Identifier class
ISO 19115
LanguageString data
structure, see Figure
15 in OWS Common[OGC 06-121r3]

Brief narrative description of thisdimension, normally available fordisplay to a human

LanguageString data
structure, see Figure
15 in OWS Common[OGC 06-121r3]

Unordered list of one or morecommonly used or formalisedword(s) or phrase(s) used todescribe this dataset

MD_Keywords class in
ISO 19115

Multiplicity and use
One (mandatory)

Zero or more
(optional) Include
when available andusefulInclude one for eachlanguage
represented dZero or more
(optional) Include
when available andusefulInclude one for eachlanguage
represented
Zero or more
(optional)
One for eachkeyword authority
used

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Names
UOM
UOM

Definition
Units of measure of dimensional
axis

unitSymbol
UnitSymbol

Symbol of the units

default

Default value that will be used if atile request does not specify avalue or uses the keyword 'default'

Default

current
Current

value
Value

A value of 'true' indicates (a) that
temporal data are normally kept
current and (b) that the request
value of this dimension accepts the
keyword 'current'
Indicates an available value for thisdimension

Data type and values

Multiplicity and use

DomainMetadata data
structure, see Table
43 in OWS Common[OGC 06-121r3]
Character String type,not empty

Zero or one(optional) Include
when available andusefulZero or one(optional) Include
when available andusefulOne (mandatory)

Character String type,not empty (with the
exception of 'default'
or 'current')
BooleanCharacter String type,not empty

Zero or one(optional) Include
only for temporalextents.
Default is 'false'
one or more(mandatory)c
One of eachdimension valueaThis has the same meaning as "name" in WMS but has been replaced by "identifier" to harmonize with OWS Common.

b

The multilingual scoping rules in subclause 10.7.3 of OWS Common [OGC 06-121r3] SHALL apply.

c

Repeat this parameter for each available value for this dimension.

d

If no Title is specified, client may display the Identifier value insteadeDimension identifies SHALL be unique (different) for each layer of this server
NOTE 3 The WMS content of a dimension section has a property called multiValues to inform the clientthat server supports the requesting of multiple values at the same time. The WMTS request for a tile does
not support this as a possible property for the dimension data type in this standard.

Table 10 — Parts of TileMatrixSetLink data structure
Names
tileMatrix
Set

Definition
Reference to a tileMatrixSet

Tile
MatrixSet

tileMatrix
Set
LimitsIndex limits for this tileMatrixSet

Tile
MatrixSet
LimitsData type and values
URI type
Values SHALL be an
tileMatrixSet
identifieir in service
metadata document
TileMatrixSetLimits
data structure, see
Table 11Multiplicity and use
One (mandatory)

Zero or one (optional)
Should be include
when the boundaryof the data is a
fragment of theboundary of thetileMatrixSet aa The absence of this parameter means that tile row and tile column indices are only limited by 0 and the corresponding
matrixWidth and matrixHeight for each tileMatrix of the tileMatrixSet definition.

Copyright © 2010 Open Geospatial Consortium Inc.

23

OGC 07-057r7

Table 11 — Parts of TileMatrixSetLimits data structure
Names
tileMatrix
LimitsDefinition
Indices limits for this tileMatrix

Tile
MatrixLimitsa

Data type and values
TileMatrixLimits data
structure, see Table
12

Multiplicity and use
one or more(mandatory) a

Multiplicity SHALL be the multiplicity of tileMatrix this tileMatrixSet.

Table 12 — Parts of TileMatrixLimits data structure
Names
tileMatrix

Definition
Reference to a tileMatrix identifier

Data type and values
URI type
Values defined inservice metadata a
Positive integer type b

Multiplicity and use
One (mandatory)

Maximim tile row index valid forthis layer.

Positive integer type c

One (mandatory)

Minimum tile column index valid
for this layer.

Positive integer type d

One (mandatory)

Maximim tile column index valid
for this layer.

Positive integer type e

One (mandatory)

TileMatrix

minTileRow
MinTileRow

maxTileRow
MaxTileRow

minTileCol
MinTileCol

maxTileCol
MaxTileCol

Minimum tile row index valid forthis layer.

One (mandatory)a

URI SHALL be an identifier to a tileMatrix section of this tileMatrixSet for this layer.

b

From 0 to maxTileRowc

From minTileRow to matrixWidth-1 of the tileMatrix section of this tileMatrixSetd

From 0 to maxTileCole

From minTileCol to tileHeight-1 of the tileMatrix section of this tileMatrixSet

A tileMatrixSet defines a generic tiled space bounding box through a TopLeftCorner andMatrixWidth and MatrixHeight as explained in clause 6. For practical reasons somelayers that point to this tiled space might not have data covering the entire bounding box
but have data covering only some rectangular subset. The optional TileMatrixSetLimits
should be included in the description of the layer section to reflect this fact. A request fora tile outside the area marked on Figure 7 SHOULD result in an exception response.

24

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

TopLeftCorner
TileMatrixMinX

TileMatrixMaxY

0,0

1,0

0,1

1,1

TileMatrixMaxX

minTileCol
minTileRow...

MatrixWidth-1,0...

MatrixWidth-1,1...

MatrixWidth-1,
MatrixHeight-1

2,2

5,4
0,
TileMatrixMinY

maxTileCol
maxTileRow

MatrixHeight-1

Figure 7 — Optional TileMatrix Limits<<DataType>>
TileMatrixSet+ identifier : CodeType+ title [0..1]: LanguageString+ abstract [0..1]: LanguageString+ keyword [0..*] : MD_Keywords+ SuportedCRS [0..1]: URI+ wellKnowScaleSet : URI

1

1..* +tileMatrix<<DataType>>
TileMatrix

1+boundaryBox

0..1

BoundingBox(From OWS Contents)+ lowerCorner : Sequence <Number, 2>+ upperCorner : Sequence <Number, 2>+ crs [0..1]: URI+ dimensions [0..1] PositiveInteger+ identifier : CodeType+ title [0..1]: LanguageString+ abstract [0..1]: LanguageString+ keyword [1..*] : MD_Keywords+ scaleDenominator : <Number>+ topLeftPoint : GML Point+ tileWitdh: PositiveInteger+ tileHeight: PositiveInteger+ matrixWitdh: PositiveInteger+ matrixHeight: PositiveIntege

Figure 8 — TileMatrixSet UML model
Copyright © 2010 Open Geospatial Consortium Inc.

25

OGC 07-057r7

Each layer has one or more references to a TileMatrixSet identifier. The structure in
Table 13 defines the structure of the TileMatrixSet sections in the Content section.
NOTE 4 If a client requires all tiles to be aligned to a specific TileMatrixSet, it could choose to only
display layers that share the same TileMatrixSet identifier. Alternatively, it could compare TileMatrixSet
definitions for an equivalency (a simple calculation can be performed to verify whether or not two given
tile matrices are aligned).

Table 13 — Parts of TileMatrixSet data structure
Names
identifier
Identifier

title aTitle

abstract a
Abstract

keywordsa
Keywords

bounding
Box
Bounding
Box

supported
CRS

Definition
Tile matrix set identifier

Data type and valuesgows:CodeType, as
adaptation of
MD_Identifier class
ISO 19115
Title of this tile matrix set, normally LanguageString data
used for display to a humanstructure, see Figure
15 in OWS Common[OGC 06-121r3]

Brief narrative description of thistile matrix set, normally available
for display to a human

LanguageString data
structure, see Figure
15 in OWS Common[OGC 06-121r3]

Unordered list of one or morecommonly used or formalisedword(s) or phrase(s) used todescribe this dataset

MD_Keywords class in
ISO 19115

Minimum bounding rectangle
surrounding the tile matrix set, inthe supported CRS b

BoundingBox data
structure, see
subclause 10.2 of
OWS Common [OGC
06-121r3]
URI type

Reference to one coordinate
reference system (CRS)

Multiplicity and use
One (mandatory)

Zero or more
(optional) Include
when available andusefulInclude one for eachlanguage
represented f
Zero or more
(optional) Include
when available andusefulInclude one for eachlanguage
represented
Zero or more
(optional)
One for eachkeyword authority
used
Zero or one(optional)

One (mandatory)

Supported
CRS

wellKnown
ScaleSet

Reference to a well known scalesete

URI type

Zero or one(optional) c

Describes a scale level and its tile
matrixTileMatrix data
structure, see Table 14

One or more(mandatory) d

WellKnown
ScaleSet

tileMatrix
TileMatrix

26

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Names
a

Definition

Data type and values

Multiplicity and use

The multilingual scoping rules in subclause 10.7.3 of OWS Common [OGC 06-121r3] SHALL apply.

b If available, it represents the area where the data is expected to be represented. This does not necessarily
indicate a complete tile boundary (and therefore does not necessarily include the TopLeftCorner of the tile
matrices).
c When a tile matrix set conforms to a well-known scale set it SHOULD reference it by its URI. The wellknown scale set SHALL be consistent with the supportedCRS and with the scaleDenominators of the tileMatrix
parameters.
d Commonly more than one. Each tileMatrix of a tileMatrixSet SHALL have a unique (different)
scaleDenominatoreSome possible values are defined the in Annex Ef

If no Title is specified, client may display the Identifier value insteadg

TileMatrixSet identifies SHALL be unique (different) for each TileMatrixSet of this serverh

The content of this parameter follows subclause 11.3 and annex D.14 of OWS Common [OGC 06-121r3]

Table 14 — Parts of TileMatrix data structure
Names
identifier

Definition
Tile matrix identifier c

Identifier

title aTitle

abstract a

Title of this style, normally used
for display to a human

Data type and values
ows:CodeType, as
adaptation of
MD_Identifier class
ISO 19115
LanguageString data
structure, see Figure
15 in OWS Common[OGC 06-121r3]

Multiplicity and use
One (mandatory)

Zero or more
(optional) Include
when available andusefulInclude one for eachlanguage
represented dZero or more
(optional) Include
when available andusefulInclude one for eachlanguage
represented
Zero or more
(optional)
One for eachkeyword authorityused
One (mandatory)

Brief narrative description ofthis style, normally available
for display to a human

LanguageString data
structure, see Figure
15 in OWS Common[OGC 06-121r3]

Keywords

Unordered list of one or morecommonly used or formalisedword(s) or phrase(s) used todescribe this dataset

MD_Keywords class in
ISO 19115

scale
Denominator

Scale denominator level of thistile matrix

Double type

Position in CRS coordinates of
the top-left corner of this tile
matrixWidth of each tile of this tile
matrix in pixels

Ordered sequence of
double values b

One (mandatory)

Positive integer type

One (mandatory)

Abstract

keywordsc

Scale
Denominator

topLeftCorner
TopLeftCorner

tileWidth
TileWidth

Copyright © 2010 Open Geospatial Consortium Inc.

27

OGC 07-057r7

Names
tileHeight
TileHeightmatrixWidth
MatrixWidthmatrixHeight
MatrixHeightaDefinition
Height of each tile of this tile
matrix in pixels

Data type and values
Positive integer typeMultiplicity and use
One (mandatory)

Width of the matrix (number oftiles in width)

Positive integer type

One (mandatory)

Height of the matrix (number oftiles in height)

Positive integer type

One (mandatory)

The multilingual scoping rules in subclause 10.7.3 of OWS Common [OGC 06-121r3] SHALL apply.

b CRS will be inherited from the supportedCRS parameter of the parent TileMatrixSet. The order of theseaxes, shall be as specified by the supportedCRS. These are the precise coordinates of the top left corner of top
left pixel of the 0,0 tile. See Figure 2.
c This TileMatrix identifiers SHALL be unique (different) within the context of the parent TileMatrixSet.
Consider using a rounded scale denominator or a rounded pixel size as a value.
d

If no Title is specified, client may display the Identifier value instead.

e

In XML schemas ows:PositionType data type is used. See OWS 1.1 schemas (owsCommon.xsd)

NOTE 5 It may be desirable to define a tile matrix set with some general-scale tile matrices in one CRS(e.g., CRS:84) and with detailed-scale tile matrices in a different CRS (e.g., LCC projection). However, thisstandard does not allow this. Each tile matrix set SHALL declare a single CRS. You could define two tile
matrix sets for the same layer instead.
NOTE 6 The width and height in tiles of each tile matrix is explicitly given, so the range of relevant tileindexes does not have to be calculated by the client application.
NOTE 7 The bounding box of a tile matrix is not supplied explicitly because it can be calculated fromtopLeftCorner, tileWidth, tileHeight and scaleDenominator.

7.1.1.1.3

Themes section contents

The optional Themes section of a WMTS service metadata document SHALL containdata about how layers are organized thematically.
The WMTS standard proposes a different approach from WMS for layer organization, an
approach based on the idea of themes. In the Contents section of WMTS, layers are
represented as a linear list without hierarchy, and a hierarchy of themes is specified
separately in the Themes section, removing the need to specify complex inheritance rules
for layer properties. This separates both concepts and makes it easy for a client to ignore
the theme hierarchy or even to force another layer organization. Also it allows servers tooffer more than one layer organization (in more than one themes section).
Each theme has a human-readable description (i.e., a title) and a list of layer references
and child themes. It is possible for a layer to be a member of more than one theme, andfor a layer to exist without being a member of any theme.

28

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Description(from OWS Data Identitfication)+ title [0..*] : LanguageString+ abstract [0..*] : LanguageString1+keywords

0..*

MD_Keywords(from ISO 19115 subset+ keyword [1..*] : LanguageString

Themes1+ theme0..*<<DataType>>
Theme+ identifier : CodeType+ theme [0..n] : Theme+ layerRef [0..n]: URI

Figure 9 — Themes UML model

The Themes sections SHALL include the parameters specified in Table 15 and Table 16.
Table 15 — Parts of the Themes section
Names
theme
Theme

Definition

Data type and values

Metadata describing the toplevel themes where layers
available on this server can
be classified

Theme data structure, see
Table 16

Multiplicity and use
Zero or more
(optional) a
One for each toplevel theme
available

Table 16 — Parts of Theme data structure
Names
identifier

Definition
Name of the theme

IdentifierCopyright © 2010 Open Geospatial Consortium Inc.

Data type and values
ows:CodeType, as
adaptation of
MD_Identifier class ISO
19115

Multiplicity and use
One (mandatory)

29

OGC 07-057r7

Names
title aDefinition
Title of this theme, normally used
for display to a human

Data type and values
LanguageString data
structure, see Figure 15
in OWS Common [OGC
06-121r3]

Brief narrative description of thistheme, normally available fordisplay to a human

LanguageString data
structure, see Figure 15
in OWS Common [OGC
06-121r3]

Unordered list of one or morecommonly used or formalisedword(s) or phrase(s) used todescribe this dataset

MD_Keywords class in
ISO 19115

Theme

Metadata describing the child(subordinate) themes of thistheme where layers available on
this server can be classified

Theme data structure, see
this Table

layerRef

Reference to layer

URI type
Values defined in service
metadata b

Title

abstract a
Abstract

keywordsa
Keywords

theme

LayerRef

Multiplicity and use
Zero or more
(optional) Include
when available andusefulInclude one for eachlanguage
represented c
Zero or more
(optional) Include
when available andusefulInclude one for eachlanguage
represented
Zero or more
(optional)
One for eachkeyword authority
used
Zero or more
(optional) a
One for each theme
available
Zero or more
(optional)a

The multilingual scoping rules in subclause 10.7.3 of OWS Common [OGC 06-121r3] SHALL apply.

b

A layer identifier on this ServiceMetadata document.

c

If no Title is specified, client may display the Identifier value instead.

7.1.1.2

ServiceMetadata document XML schema

ServiceMetadata documents can be encoded in XML. This standard provides XML
schemas to encode XML Service metadata documents as described in Annex B. The
following XML schema fragment for a WMTS service metadata document shows how
WMTS extends ows:CapabilitiesBaseType in owsCommon.xsd of OWS Common [OGC
06-121r3] to include other parameters as previously described in Table 3:<?xml version="1.0" encoding="UTF-8"?><schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:wmts="http://www.opengis.net/wmts/1.0"
xmlns:ows="http://www.opengis.net/ows/1.1"
xmlns:gml="http://www.opengis.net/gml"
targetNamespace="http://www.opengis.net/wmts/1.0"
elementFormDefault="qualified" xml:lang="en"><annotation><documentation>
This XML Schema Document defines the ServiceMetadata document
namespace.

30

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7</documentation></annotation><!-- =============================================================
includes and imports============================================================== --><import namespace="http://www.opengis.net/ows/1.1"
schemaLocation="../../ows/1.1.0/owsAll.xsd"/><!--==============================================================
elements and types============================================================== --><element name="Capabilities"><complexType><complexContent><extension base="ows:CapabilitiesBaseType"><sequence><element name="Contents" type="wmts:ContentsType"minOccurs="0" /><element ref="wmts:Themes" minOccurs="0"
maxOccurs="unbounded" /><element name="WSDL" type="ows:OnlineResourceType"minOccurs="0" maxOccurs="unbounded" /><element name="ServiceMetadataURL"
type="ows:OnlineResourceType" minOccurs="0"
maxOccurs="unbounded" /></sequence></extension></complexContent></complexType></element>...
</schema>

As indicated above, this XML Schema document uses the owsServiceIdentification.xsd,
owsServiceProvider.xsd, and owsOperationsMetadata.xsd schemas specified in OWS
Common [OGC 06-121r3]. It also uses an XML Schema document for the ―Contents‖
sections of the WMTS ServiceMetadata XML document, which is included in the
wmtsGetCapabilities_response.xsd file. All these XML Schema documents containdocumentation of the meaning of each element, attribute and type, and thisdocumentation SHALL be considered normative as specified in subclause 11.6.3 of OWS
Common [OGC 06-121r3].
Annex B contains more details on this normative set of XML Schema documents.
7.1.1.3

ServiceMetadata document example

A WMTS server might generate a ServiceMetadata document that looks like thefollowing example. Another example can be found in Annex D:<?xml version="1.0" encoding="UTF-8"?><Capabilities xmlns="http://www.opengis.net/wmts/1.0"
xmlns:ows="http://www.opengis.net/ows/1.1"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:gml="http://www.opengis.net/gml"
xsi:schemaLocation="http://www.opengis.net/wmts/1.0

Copyright © 2010 Open Geospatial Consortium Inc.

31

OGC 07-057r7../wmtsGetCapabilities_response.xsd"
version="1.0.0"><ows:ServiceIdentification><ows:Title>World example Web Map Tile Service</ows:Title><ows:Abstract>
Example service that constrains some world layers in the
GlobalCRS84Pixel Well-known scale set</ows:Abstract><ows:Keywords><ows:Keyword>World</ows:Keyword><ows:Keyword>Global</ows:Keyword><ows:Keyword>Digital Elevation Model</ows:Keyword><ows:Keyword>Administrative Boundaries</ows:Keyword></ows:Keywords><ows:ServiceType>OGC WMTS</ows:ServiceType><ows:ServiceTypeVersion>1.0.0</ows:ServiceTypeVersion><ows:Fees>none</ows:Fees><ows:AccessConstraints>none</ows:AccessConstraints></ows:ServiceIdentification><ows:ServiceProvider><ows:ProviderName>UAB-CREAF-MiraMon</ows:ProviderName><ows:ProviderSite xlink:href="http://www.creaf.uab.cat/miramon"/><ows:ServiceContact><ows:IndividualName>Joan Maso Pau</ows:IndividualName><ows:PositionName>Senior Software Engineer</ows:PositionName><ows:ContactInfo><ows:Phone><ows:Voice>+34 93 581 1312</ows:Voice><ows:Facsimile>+34 93 581 4151</ows:Facsimile></ows:Phone><ows:Address><ows:DeliveryPoint>Fac Ciencies UAB</ows:DeliveryPoint><ows:City>Bellaterra</ows:City><ows:AdministrativeArea>Barcelona</ows:AdministrativeArea><ows:PostalCode>08193</ows:PostalCode><ows:Country>Spain</ows:Country><ows:ElectronicMailAddress>joan.maso@uab.cat</ows:ElectronicMailAddress></ows:Address></ows:ContactInfo></ows:ServiceContact></ows:ServiceProvider><ows:OperationsMetadata><ows:Operation name="GetCapabilities"><ows:DCP><ows:HTTP><ows:Get xlink:href="http://www.maps.bob/maps.cgi?"><ows:Constraint name="GetEncoding"><ows:AllowedValues><ows:Value>KVP</ows:Value></ows:AllowedValues></ows:Constraint></ows:Get><ows:Post xlink:href="http://www.maps.bob/maps.cgi?"><ows:Constraint name="PostEncoding"><ows:AllowedValues><ows:Value>SOAP</ows:Value>

32

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7</ows:AllowedValues></ows:Constraint></ows:Post></ows:HTTP></ows:DCP></ows:Operation><ows:Operation name="GetTile"><ows:DCP><ows:HTTP><ows:Get xlink:href="http://www.maps.bob/maps.cgi?"><ows:Constraint name="GetEncoding"><ows:AllowedValues><ows:Value>KVP</ows:Value></ows:AllowedValues></ows:Constraint></ows:Get></ows:HTTP></ows:DCP></ows:Operation><ows:Operation name="GetFeatureInfo"><ows:DCP><ows:HTTP><ows:Get xlink:href="http://www.maps.bob/maps.cgi?"><ows:Constraint name="GetEncoding"><ows:AllowedValues><ows:Value>KVP</ows:Value></ows:AllowedValues></ows:Constraint></ows:Get></ows:HTTP></ows:DCP></ows:Operation></ows:OperationsMetadata><Contents><Layer><ows:Title>etopo2</ows:Title><ows:Abstract>
ETOPO2 - 2 minute Worldwide Bathymetry/Topography
Data taken from National Geophysical Data Center(NGDC),ETOPO2 Global 2' Elevations, September 2001...
</ows:Abstract><ows:WGS84BoundingBox><ows:LowerCorner>-180 -90</ows:LowerCorner><ows:UpperCorner>180 90</ows:UpperCorner></ows:WGS84BoundingBox><ows:Identifier>etopo2</ows:Identifier><ows:Metadata
xlink:href="http://www.maps.bob/etopo2/ metadata.htm"/><Style isDefault="true"><ows:Title>default</ows:Title><ows:Identifier>default</ows:Identifier><LegendURL format="image/png"
xlink:href="http://www.maps.bob/etopo2/legend.png" /></Style><Format>image/png</Format><InfoFormat>application/gml+xml; version=3.1</InfoFormat><TileMatrixSetLink><TileMatrixSet>WholeWorld_CRS_84</TileMatrixSet>

Copyright © 2010 Open Geospatial Consortium Inc.

33

OGC 07-057r7</TileMatrixSetLink></Layer><Layer><ows:Title>Administrative Boundaries</ows:Title><ows:Abstract>The sub Country Administrative Units 1998
GeoDataset represents a small-scale political map of
the world...</ows:Abstract><ows:WGS84BoundingBox><ows:LowerCorner>-180 -90</ows:LowerCorner><ows:UpperCorner>180 84</ows:UpperCorner></ows:WGS84BoundingBox><ows:Identifier>AdminBoundaries</ows:Identifier><ows:Metadata
xlink:href="http://www.maps.bob/AdminBoundaries/metadata.htm"/><Style isDefault="true"><ows:Title>default</ows:Title><ows:Identifier>default</ows:Identifier></Style><Format>image/png</Format><TileMatrixSetLink><TileMatrixSet>WholeWorld_CRS_84</TileMatrixSet></TileMatrixSetLink></Layer><TileMatrixSet><ows:Identifier>WholeWorld_CRS_84</ows:Identifier><ows:SupportedCRS>urn:ogc:def:crs:OGC:1.3:CRS84</ows:SupportedCRS><WellKnownScaleSet>urn:ogc:def:wkss:OGC:1.0:GlobalCRS84Pixel</WellKnownScaleSet><TileMatrix><ows:Identifier>2g</ows:Identifier><ScaleDenominator>795139219.9519541</ScaleDenominator><!-- top left point of tile matrix bounding box --><TopLeftCorner>-180 90</TopLeftCorner><!-- width and height of each tile in pixel units --><TileWidth>320</TileWidth><TileHeight>200</TileHeight><!-- width and height of matrix in tile units --><MatrixWidth>1</MatrixWidth><MatrixHeight>1</MatrixHeight></TileMatrix><TileMatrix><ows:Identifier>1g</ows:Identifier><ScaleDenominator>397569609.9759771</ScaleDenominator><TopLeftCorner>-180 90</TopLeftCorner><TileWidth>320</TileWidth><TileHeight>200</TileHeight><MatrixWidth>2</MatrixWidth><MatrixHeight>1</MatrixHeight></TileMatrix><TileMatrix><ows:Identifier>30m</ows:Identifier><ScaleDenominator>198784804.9879885</ScaleDenominator><TopLeftCorner>-180 90</TopLeftCorner><TileWidth>320</TileWidth><TileHeight>200</TileHeight><MatrixWidth>3</MatrixWidth><MatrixHeight>2</MatrixHeight>

34

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7</TileMatrix><TileMatrix><ows:Identifier>20m</ows:Identifier><ScaleDenominator>132523203.3253257</ScaleDenominator><TopLeftCorner>-180 90</TopLeftCorner><TileWidth>320</TileWidth><TileHeight>200</TileHeight><MatrixWidth>4</MatrixWidth><MatrixHeight>3</MatrixHeight></TileMatrix><TileMatrix><ows:Identifier>10m</ows:Identifier><ScaleDenominator>66261601.66266284</ScaleDenominator><TopLeftCorner>-180 90</TopLeftCorner><TileWidth>320</TileWidth><TileHeight>200</TileHeight><MatrixWidth>7</MatrixWidth><MatrixHeight>6</MatrixHeight></TileMatrix><TileMatrix><ows:Identifier>5m</ows:Identifier><ScaleDenominator>33130800.83133142</ScaleDenominator><TopLeftCorner>-180 90</TopLeftCorner><TileWidth>320</TileWidth><TileHeight>200</TileHeight><MatrixWidth>14</MatrixWidth><MatrixHeight>11</MatrixHeight></TileMatrix><TileMatrix><ows:Identifier>2m</ows:Identifier><ScaleDenominator>13252320.33253257</ScaleDenominator><TopLeftCorner>-180 84</TopLeftCorner><TileWidth>320</TileWidth><TileHeight>200</TileHeight><MatrixWidth>34</MatrixWidth><MatrixHeight>28</MatrixHeight></TileMatrix></TileMatrixSet></Contents><Themes><Theme><ows:Title>Foundation</ows:Title><ows:Abstract>World reference data</ows:Abstract><ows:Identifier>Foundation</ows:Identifier><Theme><ows:Title>Digital Elevation Model</ows:Title><ows:Identifier>DEM</ows:Identifier><LayerRef>etopo2</LayerRef></Theme><Theme><ows:Title>Administrative Boundaries</ows:Title><ows:Identifier>AdmBoundaries</ows:Identifier><LayerRef>AdminBoundaries</LayerRef></Theme></Theme></Themes></Capabilities>

Copyright © 2010 Open Geospatial Consortium Inc.

35

OGC 07-057r7
7.1.2

GetCapabilities operation (mandatory in procedure oriented architectural style)

The GetCapabilities operation in procedure oriented architectural style allows WMTS
clients to retrieve a service metadata document from a server. The response to a
GetCapabilities request SHALL be a document containing service metadata about theserver, including specific information about the layers that can be requested, the tile setsin which these layers are available, and (optionally) one or more theme sets. The
GetCapabilities operation also includes a version-negotiation mechanism, allowing theclient and server to agree on a standard version on which to base all futurecommunication. The subclause 7.1.1 specifies the sections for the ServiceMetadata
document that a WMTS server SHALL return to describe its service metadata (usually
encoded in an XML file).
7.1.2.1

GetCapabilities operation request

The GetCapabilities operation request SHALL be as specified in Subclauses 7.2 and 7.3
of OWS Common [OGC 06-121r3] and SHALL follow the Tables 3 and 7 of OWS
Common [OGC 06-121r3]. Parameters of the GetCapabilities request are described inTable 3 of OWS Common [OGC 06-121r3] with the restriction in the value of the―service‖ parameter that SHALL be ―WMTS‖ as listed in Table 17 below.
Table 17 — Parameters in GetCapabilities operation request
Names
service

Definition

Data type and values

Service type identifier

Character String type, not empty
SHALL be "WMTS"
Character String type, not empty
SHALL be "GetCapabilities"
Sequence of Character String type,each not empty
Value is list of x.y.z ―version‖values. SHALL contain "1.0.0"

ServicerequestOperation name

RequestacceptVersions
AcceptVersions

sections
Sections

updateSequence
UpdateSequence

36

Prioritized sequence of
one or more standard
versions accepted byclient, with preferredversions listed first
Unordered list of zeroor more names ofrequested sections incomplete service
metadata document

Sequence of Character String type,each not empty
Value is list of section names
Allowed section names are in Table
18

Service metadata
Character String type, not empty
document version,
Values are selected by each server,
value is ―increased‖
and are always opaque to clients
whenever any change
is made in complete
service metadata
document

Multiplicity and use
One (mandatory)
One (mandatory)
Zero or one(optional)
When omitted, returnlatest supported
versionZero or one(optional)
When omitted or notsupported byserver, return
complete service
metadata document
Zero or one(optional)
When omitted or notsupported byserver, return latest
service metadata
document

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Names
acceptFormats
AcceptFormats

Definition

Data type and values

Multiplicity and use

Prioritized sequence ofzero or more
response formats
desired by client,with preferred
formats listed first

Sequence of Character String type,each not empty
Value is list of format identifiers
Identifiers are MIME types offormats useful for service
metadata documents

Zero or one(optional)
When omitted or notsupported byserver, returnservice metadata
document using
MIME type"application/xml"

Sections name values of the WMTS service valid in a GetCapabilities request are
specified in Table 6 of OWS Common [OGC 06-121r3] with the addition of the Themes
section as listed in Table 18 below.
Table 18 — Meaning of section name values
Section nameServiceIdentification
ServiceProvider
OperationsMetadata
Contents
ThemesAll

Meaning
Return ServiceIdentification element in service metadata document
Return ServiceProvider metadata element in service metadata document
Return OperationsMetadata element in service metadata document
Return Contents metadata element in service metadata document
Return Themes metadata element in service metadata document
Return complete service metadata document, containing all elements

The ―Multiplicity and use‖ column in Table 1 of OWS Common [OGC 06-121r3]
specifies the optionally of each listed parameter in the GetCapabilities operation request.
Table 19 specifies the implementation of those parameters by WMTS clients and servers.
Table 19 — Implementation of parameters in GetCapabilities operation request
Names
service
ServicerequestRequestacceptVersions
AcceptVersions

sections
Sections

updateSequence
UpdateSequence

Multiplicity

Client implementation

Server implementation

One(mandatory)

Each parameter SHALL be
implemented by all clients,using specified value

Each parameter SHALL be
implemented by all servers,
checking that each parameter isreceived with specified value

Zero or one(optional)

SHOULD be implemented by
all software clients, using
specified values

Zero or one(optional)

Each parameter may be
implemented by each client
If parameter not provided,
SHALL expect default
response

SHALL be implemented by all
servers, checking if parameteris received with specified
value(s)Each parameter may be
implemented by each server
If parameter not implemented or
not received, SHALL provide
default responseOne(mandatory)

Zero or one(optional)

Copyright © 2010 Open Geospatial Consortium Inc.

37

OGC 07-057r7

acceptFormats

Zero or one(optional)

AcceptFormats

7.1.2.2

If parameter provided, SHALL
allow default or specified
response

If parameter implemented andreceived, SHALL provide
specified response

GetCapabilites exceptions in procedure oriented architectural style

When a WMTS server encounters an error while performing a GetCapabilities operation,
it SHALL return an exception-report message as specified in clause 8 of OWS Common[OGC 06-121r3]. The allowed exception codes SHALL include those listed in Table 20
assuming the updateSequence parameter is implemented by the server.
NOTE 1 To reduce the need for readers to refer to other documents, the table below is copied from
Table 8 in subclause 7.4.1 of OWS Common [OGC 06-121r3].

Table 20 — Exception codes for GetCapabilities operation
exceptionCode value
MissingParameterValue
InvalidParameterValue
VersionNegotiationFailed

InvalidUpdateSequence

NoApplicableCode

Meaning of code
Operation request does not include a parameter
value
Operation request contains an invalid parameter
value
List of versions in ―AcceptVersions‖ parametervalue, in GetCapabilities operation request,
did not include any version supported by thisserverValue of (optional) updateSequence parameter,in GetCapabilities operation request, is greaterthan current value of service metadata
updateSequence number
No other exceptionCode specified by thisservice and server applies to this exception―locator‖ value
Name of missing
parameter
Name of parameterwith invalid value
None, omit ―locator‖
parameter
None, omit ―locator‖
parameter
None, omit ―locator‖
parameter

If the client sends a KVP encoded request using unknown parameters these unknown
parameters SHALL be ignored by the server and will not cause an exception to begenerated.

38

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

When a WMTS server responds with an ExceptionReport and the report is transmitted
via HTTP, the WMTS server should set the status code of the HTTP response to thecorresponding value for the given exceptionCode values, as shown in Table 21. When the
ExceptionReport contains more than one Exception, then the HTTP status code value
should be based upon the exceptionCode of the first Exception in the ExceptionReport.
Table 21 — HTTP exception codes and meanings on GetCapabilities operation
exceptionCode value
MissingParameterValue
InvalidParameterValue
VersionNegotiationFailed
InvalidUpdateSequence
NoApplicableCode

7.1.3

Code
400
400
400
400
500

HTTP Status Code
Message
Bad request
Bad request
Bad request
Bad request
Internal server error

ServiceMetadata resource request (mandatory in resource oriented architectural
style)WMTS servers using a resource oriented architectural style provide standard endpoints
from which a representation of the ServiceMetadata resource can be obtained. The
endpoint SHALL also be specified in the ServiceMetadata document although it will
generally be obtained prior to communication with the server.
The client will request the representation of the ServiceMetadata resource by performinga standard request to the endpoint. In response to a correct request, the server SHALL
provide a representation of its ServiceMetadata document which conforms with subclause
7.1.1. Incorrect requests shall be handled according to the standard semantics for errors
for the transport protocol used for communication between the client and the server.

7.2

Tile

WMTS servers are designed to serve map image tiles. The ServiceMetadata document
described in the previous subclause lists the tiles available on the server and therequirements for requesting a tile. Typically clients will first request the ServiceMetadata
document from the server and then use the information in that document to discover how
to perform valid requests for tiles.

Copyright © 2010 Open Geospatial Consortium Inc.

39

OGC 07-057r7
7.2.1

Tile resource

The tile resource is generally a rectangular image containing cartographic data.
Alternatively, this resource might be a non-image representation of the tile such as a
description of the tile or a link to the actual image. For example, the tile resource could
be a KML document used in a superoverlay, or a tile metadata document. When returning
an image tile, a full single tile SHALL always be returned. Also, the background pixels ofa tile SHOULD be transparent when possible so that the client can overlay the tiles on topof other map data (possibly other tiles).
The Tile resource representation SHALL be returned in the format specified in therequest when the format has been advertised in the ServiceMetadata document asavailable for that Tile resource.
7.2.2

GetTile operation (mandatory in procedure oriented architectural style)

The GetTile operation in procedure oriented architectural style allows WMTS clients torequest a particular tile of a particular tile matrix set in a predefined format. This
operation has some parameters in common with WMS GetMap but it has been
deliberately simplified. For instance, only one layer can be retrieved at a time. WMTS
servers that want to allow a combination of layers to be served and requested have to givethis combination an identifier and add it as a new layer in the service metadata document.
Nevertheless, clients are expected to be able easily to overlay layers themselves
eliminating the need for servers to offer layers by combination.

7.2.2.1

GetTile operation request

A request to perform the GetTile operation SHALL use the data structure specified inTable 22. This table also specifies the UML model data type, source of values, andmultiplicity of each listed parameter, plus the default server behavior when an optionalparameter is not included in the operation request.

40

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7<<Interface>>
OWService {Abstract}+ getTile(request : GetTile) : TileResponse

RequestBase (Abstract)

TileResponse(from OWS Get Capabilities)+ service : CharacterString+ request : CharacterString+ version : CharacterString+ map : byte[]+ type : MimeType

WMTSGetCapabilities(from WMTS Service)+ service : CharacterString = "WMTS" {frozen}

TileRequest

1+ request : CharacterString = "GetTile" {frozen}<<DataType>>
TileAttributes

1<<DataType>>
TileRequestParameters

1+ format : ows:MimeType+ tilePosition : TilePosition
11<<DataType>>
TilePosition+ layer : CharacterString
1 + style : CharacterString
1
0..1<<DataType>>
SampleDimensions+ elevation [0..1] : Double+ otherSampleDimensions [0..*]: CharacterString+ time [0..1] : CharacterString+ tileMatrixSet: CharacterString+ tileCol : Integer+ tileRow : Integer+ tileMatrix : CharacterString

Figure 10 — GetTile operation request UML class diagram

Copyright © 2010 Open Geospatial Consortium Inc.

41

OGC 07-057r7

Table 22 — Parameters in GetTile operation request
Names
service

Definition
Service type identifier

ServicerequestOperation name

RequestversionVersionStandard version for
operation

layer

Layer identifier

Layer

style

Style identifier

StyleformatOutput format of the tile

FormatOther
Value allowed for thissampledimension
dimensionsatileMatrix
Set

TileMatrixSet identifier

TileMatrix
Set

tileMatrix

TileMatrix identifier b

TileMatrix

tileRow

Row index of tile matrix

TileRow

tileCol
TileCol

Column index of tile
matrix

Data type and values
Character String type, not empty
SHALL be "WMTS"
Character String type, not empty
SHALL be "GetTile"
Character String type, not empty
SHALL contain "1.0.0"
Character String type, not empty
identifier that is defined in theServiceMetadata document
Character String type, not empty
identifier that is defined in theServiceMetadata document
Character String type, not empty
value that is defined in theServiceMetadata document
Character String type, not empty
a single value from a list or a range
defined in the ServiceMetadata
document
Character String type, not empty
identifier that is defined in theServiceMetadata document

Multiplicity and use
One (mandatory)

Character String type, not empty
value that is defined in theServiceMetadata document
Non negative integer typevalue between 0 andMatrixHeight-1 of this tile matrix
defined in the ServiceMetadata
document
Non negative integer typevalue between 0 and MatrixWidth1 of this tile matrix defined in theServiceMetadata document

One (mandatory)

One (mandatory)
One (mandatory)
One (mandatory)

One (mandatory)

One (mandatory)

Zero or one (optional)

One (mandatory)

One (mandatory)

One (mandatory)

a The name of this parameter is, in fact, the identifier of the dimension specified in the ServiceMetadata. See
WMS 1.3.0 annex C for reference. This parameter appear once for each dimension specified for this Layer in theServiceMetadata document.
bThis will be the identifier of the tileMatrix of the desired scale denominator for the tileMatrixSet requested.
NOTE 1 To reduce the need for readers to refer to other documents, the first three parameters listed
below are largely copied from Table 21 in subclause 9.2.1 of OWS Common [OGC 06-121r3].
NOTE 2 The UML class diagram in Figure 10 provides a useful graphical view of the contents of the
GetTile operation request listed in Table 22.

42

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7
7.2.2.2

GetTile exceptions in procedure oriented architectural style

When a WMTS server encounters an error while performing a GetTile operation, it
SHALL return an exception report message as specified in subclause 7.4.1 of OWS
Common [OGC 06-121r3]. The allowed standard exception codes SHALL include thoselisted in Table 23. For each listed exceptionCode, the contents of the ―locator‖ parametervalue SHALL be as specified in the right column of Table 23.
NOTE 1 To reduce the need for readers to refer to other documents, four values listed below are copiedfrom Table 8 in subclause 7.4.1 of OWS Common [OGC 06-121r3].

Table 23 — Exception codes for GetTile operation
exceptionCode value―locator‖ value

Meaning of code

OperationNotSupported

Request is for an operation that is not supported bythis server
MissingParameterValue Operation request does not include a parametervalue, and this server did not declare a default
value for that parameter
InvalidParameterValue Operation request contains an invalid parameter
value
TileOutOfRange
TileRow or TileCol out of range
NoApplicableCode

No other exceptionCode specified by this service
and server applies to this exception

Name of operation
not supported
Name of missing
parameter
Name of parameterwith invalid value
Name of the out-ofrange parameter
None, omit ―locator‖
parameter

If the client sends a GetTile request using unknown parameters (for example time,elevation or any other dimension that are not advertised in the ServiceMetadata
document) these unknown parameters SHALL be ignored by the server and will notcause an exception to be generated.
When a WMTS server responds with an ExceptionReport and the report is transmitted
via HTTP, the WMTS server should set the status code of the HTTP response to thecorresponding value for the given exceptionCode values, as shown in Table 24. When the
ExceptionReport contains more than one Exception then the HTTP status code value
should be based upon the exceptionCode of the first Exception in the ExceptionReport.
Table 24 — HTTP exception codes and meanings on GetTile operation
exceptionCode value

Code

OperationNotSupported
MissingParameterValue
InvalidParameterValue
TileOutOfRange
NoApplicableCode

501
400
400
400
500

Copyright © 2010 Open Geospatial Consortium Inc.

HTTP Status Code
Message
Not implemented
Bad request
Bad request
Bad request
Internal server error

43

OGC 07-057r7
7.2.3

Tile resource request (mandatory in resource oriented architectural style)

WMTS servers using a resource oriented architectural style provide standard endpoints
from which a representation of each Tile resource can be obtained. The endpoints
SHALL be specified in the ServiceMetadata document using an address template.
The client will request the representation of any offered Tile resource by performing arequest to the address following the standard semantics of the transport protocol used forcommunication between the client and the server. In response to a correct request, theserver SHALL provide a representation of the Tile resource. Incorrect requests shall behandled according to the standard semantics for the transport protocol.

7.3

FeatureInfo

WMTS servers may support requests for information about the features present at aparticular pixel location on a map tile. Requests for feature information will specify thetile along with a pixel location on that tile. The WMTS server will provide informationon the features present at or near the location specified by the client request. The WMTS
server may choose what information to provide about the nearby features.
7.3.1

FeatureInfo document

A FeatureInfo document is either the response of a GetFeatureInfo request in procedureoriented architectural style or the resource representation of a FeatureInfo resource inresource oriented architectural style. The FeatureInfo document SHALL be in the format
specified in the request when that format has been advertised in the ServiceMetadata
document as available for that FeatureInfo resource.
For a better interoperability between servers and clients we strongly recommend GML
Simple Features Profile [06-049r1] as a supported document format for FeatureInfo
resources. That standard defines three levels of content in three profiles with different
degrees of constraints to the GML flexibility. We strongly recommend support of themost constrained one (level 0) that results in a simpler GML document. In the context ofthat profile only simple XML types can be used as thematic properties and cardinality
greater than one is not allowed. Servers and clients SHALL specify the MIME type"application/gml+xml; version=3.1" as an InfoFormat value and the GML application
schema of the response SHOULD conform to GML Simple Features profile level 0 whenthat GML profile is used. In most cases, only thematic attributes of the features areintended to be included in a FeatureInfo document but the Simple Feature profiles were
evidently intended to include the geometric information of the features in the GML
objects. However, it is possible to generate an application schema that does not include
feature geometry and only describes non-geometric feature attribute types. This can bevery useful to avoid unnecessarily requesting long sequences of position values in line or
polygon layers.

44

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Also, to allow easy presentation of the data, support for the HTML format (represented
by an InfoFormat MIME type of ―text/html‖) is also recommended.
NOTE
OGC 06-049r1 recommends the use of "text/xml; subType=gml/3.1.1/profiles/gmlsf/1.0.0/0"
but this has been corrected by OGC 09-144r1 Technical Committee Policies and Procedures: MIME Media
Types for GML. This document adopts the new policy.

7.3.2

GetFeatureInfo operation (optional in procedure oriented architectural style)

The GetFeatureInfo operation in procedure oriented architectural style allows WMTS
clients to request information at a particular position of a particular tile for a particularqueryable layer. A layer is queryable if the Contents section of the ServiceMetadata
document specifies one or more InfoFormats for this layer.
NOTE 1 This criterion is different from the one used in WMS. In WMTS, the queryable property of
WMS has been substituted by the presence or absence of an InfoFormat element in the ServiceMetadata
document.

The GetFeatureInfo operation is designed to provide clients of a WMTS with more
information about features rendered in a previously returned tile. The canonical use casefor GetFeatureInfo is that a user chooses a pixel (I,J) on a particular tile at which the user
would like to obtain more information. Because the WMTS protocol is stateless, theGetFeatureInfo request indicates to the WMTS server what tile the user is viewing by
including the original GetTile request parameters but modifying the request value to'GetFeatureInfo' and adding the pixel offset parameters. From the spatial context
information (TileRow, TileCol and TileMatrixSet), along with the I,J position the user
requested, the WMTS can return additional information about that position. The other
GetTile parameters (e.g., Style) may play a role in the server's decision as to what
information to return.
NOTE 2
When the user chooses a point (I,J) in a client that is showing overlapped layers, the client willneed to make a separate GetFeatureInfo request for each layer.

7.3.2.1

GetFeatureInfo operation request

A request to perform the GetFeatureInfo operation SHALL include the use of the data
parameters as specified in Figure 11 and in Table 25. This table also specifies the UML
model data type, source of values, and multiplicity of each listed parameter, plus themeaning to servers when each optional parameter is not included in the operation request.

Copyright © 2010 Open Geospatial Consortium Inc.

45

OGC 07-057r7<<Interface>>
OWService {Abstract}+ getFeatureInto(request : GetFeaturelnfo) : FeatureInfoResponse

RequestBase (Abstract)

FeatureInfoResponse(from OWS Get Capabilities)+ service : CharacterString+ request : CharacterString+ version : CharacterString

The use of GML
Simple Features
Profile [OGC 06049r1] is strongly
recommended, as
is text/html+ featureInfo : byte[]+ type : MimeType

WMTSGetCapabilities(from WMTS Service)+ service : CharacterString = "WMTS" {frozen}

FeatureInfoRequest+ request : CharacterString = "GetFeatureInfo" {frozen}

11

TileRequestParameters(from WMTS Get Tile)

1
TileAttributes(from WMTS Get Tile)1+ layer : CharacterString
1 + style : CharacterString+ format : ows:MimeType+ tilePosition : TilePosition

1
0..1
SampleDimensions

1(from WMTS Get Tile)1+ elevation [0..1] : Double+ otherSampleDimensions [0..*]: CharacterString+ time [0..1] : CharacterString

TilePosition(from WMTS Get Tile)+ tileMatrixSet: CharacterString+ tileCol : Integer+ tileRow : Integer+ tileMatrix : CharacterString
1<<DataType>>

FeatureInfoRequestParameters+ infoFormat : FormatType+ point : PixelPoint

PixelPoint1

1 + i : integer+ j : integer

Figure 11 — GetFeatureInfo operation request UML class diagram

46

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Table 25 — Parameters in GetFeatureInfo operation request
Names
service

Definition
Service typeidentifier

ServicerequestRequestversionVersionlayer, style,format, Sample
dimension,
tileMatrixSet,
tileMatrix,
tileRow, tileCol
j
J

i
I

infoFormat
InfoFormat

Data type and values
Character String type, not empty
SHALL be ―WMTS‖
Operation nameCharacter String type, not empty
SHALL be "GetFeatureInfo‖
Standard version
Character String type, not empty
for operation
SHALL contain 1.0.0
These correspond to The values of these parameters
the parameters ofSHALL match those in thethe same name incorresponding GetTile request
the corresponding
described in Table 22
GetTile request
described in Table
22
Row index of a
Non negative integer type
pixel within the tilea value between 0 and TileHeight-1of this tile matrix defined in theServiceMetadata document
Column index of a
Non negative integer type
pixel within thevalue between 0 and TileWidth-1
tilebof this tile matrix defined in theServiceMetadata document
Output format ofCharacter String type, not empty
the retrieved
value that is defined in theinformation
ServiceMetadata documentaNumber of full pixels in the Tile to the left of the requested locationb

Number of full pixels in the Tile to the top of the requested location

Multiplicity and use
One (mandatory)
One (mandatory)
One (mandatory)
Multiplicity and use of
these parameters
SHALL match thosein the corresponding
GetTile request
described in Table
22
One (mandatory)

One (mandatory)

One (mandatory)

NOTE 1 To reduce the need for readers to refer to other documents, the first three parameters listed arelargely copied from Table 26 in subclause 9.2.1 of OWS Common [OGC 06-121r3].
NOTE 2 The UML class diagram in Figure 11 provides a useful graphical view of the contents of the
GetFeatureInfo operation request listed in Table 25.

Although some values listed in the "Names" column appear to contain white spaces, they
SHALL not contain any spaces.
7.3.2.2

GetFeatureInfo exceptions in procedure oriented architectural style

When a WMTS server encounters an error while performing a GetFeatureInfo operation,
it SHALL return an exception report message as specified in subclause 7.4 of OWS
Common [OGC 06-121r3]. The allowed standard exception codes SHALL include thoselisted in Table 26. For each listed exceptionCode, the contents of the ―locator‖ parametervalue SHALL be as specified in the right column of Table 26.

Copyright © 2010 Open Geospatial Consortium Inc.

47

OGC 07-057r7

Table 26 — Exception codes for GetFeatureInfo operation
exceptionCode value
OperationNotSupported

Meaning of code
Request is for an operation that is not supported bythis server or you are requesting a GetFeatureInfo
response for a non queryable layer
MissingParameterValue Operation request does not include a parametervalue, and this server did not declare a default
value for that parameter
InvalidParameterValue Operation request contains an invalid parameter
value
TileOutOfRange
TileRow or TileCol out of range
PointIJOutOfRange

I or J out of range

NoApplicableCode

No other exceptionCode specified by this service
and server applies to this exception―locator‖ value
Name of operation
not supported
Name of missing
parameter
Name of parameterwith invalid value
Name of the out-ofrange parameter
Name of the out-ofrange parameter
None, omit ―locator‖
parameter

NOTE
To reduce the need for readers to refer to other documents, the first four values listed below arecopied from Table 25 in subclause 8.3 of OWS Common [OGC 06-121r3].

If the client sends a GetFeatureInfo request using unknown parameters (for example time,elevation or any other dimension that are not advertised in the ServiceMetadata
document) these unknown parameters SHALL be ignored by the server and will notcause an exception to be generated.
When a WMTS server responds with an ExceptionReport and the report is transmitted
via HTTP the WMTS server should set the HTTP response’s status code to thecorresponding value for the given exceptionCode values, as shown in Table 27. When the
ExceptionReport contains more than one Exception then the HTTP status code value
should be based upon the exceptionCode of the first Exception in the ExceptionReport.
Table 27 — HTTP exception codes and meanings on GetFeatureInfo operation
exceptionCode value
OperationNotSupported
MissingParameterValue
InvalidParameterValue
TileOutOfRange
PointIJOutOfRange
NoApplicableCode

48

Code
501
400
400
400
400
500

HTTP Status Code
Message
Not implemented
Bad request
Bad request
Bad request
Bad request
Internal server error

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7
7.3.3

FeatureInfo resource request (optional in resource oriented architectural style)

WMTS servers using a resource oriented architectural style provide standard endpoints
from which representations of the FeatureInfo resources can be obtained. The endpoints
SHALL be specified in the ServiceMetadata document based on an address template.
The client will request the representation of a FeatureInfo resource by performing arequest to the address following the standard semantics of the transport protocol used forcommunication between the client and the server. In response to a correct request, theserver SHALL provide a representation of each FeatureInfo resource. Incorrect requests
shall be handled according to the standard semantics for the transport protocol.
7.4

Operation request encoding

The encoding of procedure oriented architectural style operation requests performed over
HTTP SHALL use HTTP GET with KVP encoding or HTTP POST with KVP or SOAP
encoding as specified in clause 11 of OWS Common [OGC 06-121r3]. Table 28
summarizes the WMTS Service operations and their encoding methods defined in thisstandard.
Table 28 — Procedure oriented architectural style operation request encoding
Operation name
GetCapabilities (required)
GetTile (required)
GetFeatureInfo

Request encodings
KVP, SOAP
KVP, SOAP
KVP, SOAP

HTTP GET with KVP is described in clause 8 and HTTP POST with SOAP is defined in
described in clause 9.
A resource oriented architectural style using HTTP is also defined in this standard. For
that approach, HTTP GET operations SHALL be used to access the resources(GetResourceRepresentation) available on the server. The resource repesentations
SHALL be equivalent to those that are obtained as a result of the GetCapabilites, GetTileand GetFeatureInfo operations in the procedure oriented architectural style. Thisapproach will be described in clause 10.
8

WMTS using HTTP KVP encoding

WMTS servers may support service requests made using lists of parameters and theirvalues defined as lists of Key-Value Pairs (KVP) and sent over HTTP using either GETor POST messages. Each pair is defined using the name of the parameter followed by anequals sign, '=' or ASCII character 61 (decimal), followed by the value given to theparameter, for example "service=WMTS". Parameter names for the operations aredefined in subclause 7.1.2.1. For GET HTTP messages, the KVP lists are sent as part of
the URL, as in the example of subclause 08.1.1. In POST HTTP messages, the KVP lists
are sent in the message body, one pair per line.

Copyright © 2010 Open Geospatial Consortium Inc.

49

OGC 07-057r7

Any server wishing to support KVP requests SHALL declare its support by providing an
OperationsMetadata section in its ServiceMetadata document with an Operation section
for each supported operation and a section for each supported HTTP request type, GETor POST, in which KVP is declared as an AllowedValue, as explained in subclause
7.1.1.1.1. An example of this practice, declaring support for GetCapabilities operations
using KVP with HTTP GET, can be seen in subclause 8.1.3.
8.1

GetCapabilities

WMTS servers may support KVP requests for a representation of the ServiceMetadata
document by declaring support for and correctly handling GetCapabilities requests.
8.1.1

GetCapabilities request HTTP KVP encoding

A client performs a GetCapabilities operation using KVP over HTTP by sending a GETor POST HTTP message with the 'request' parameter set to 'GetCapabilities'.
8.1.2

GetCapabilities request HTTP KVP encoding example

To request a WMTS ServiceMetadata document, a client could issue the following KVPencoded GetCapabilities operation request with minimal contents:
http://www.maps.bob/maps.cgi?service=WMTS&version=1.0.0&
request=GetCapabilities

8.1.3

GetCapabilities HTTP KVP encoding response

In response to a valid GetCapabilities request from a client, a WMTS server SHALL senda ServiceMetadata document which conforms with the XML schema defined in Annex B.
8.1.4

GetCapabilities HTTP KVP encoding response example

In response to a valid GetCapabilities operation request in KVP encoding, a WMTS
server might generate a document that looks like the one in subclause 7.1.1.3.
The following fragment declares support for KVP encoded GetCapabilities operations
using HTTP GET:...
<ows:OperationsMetadata><ows:Operation name="GetCapabilities"><ows:DCP><ows:HTTP><ows:Get xlink:href="http://www.maps.bob/maps.cgi?"><ows:Constraint name="GetEncoding"><ows:AllowedValues><ows:Value>KVP</ows:Value></ows:AllowedValues></ows:Constraint></ows:Get></ows:HTTP></ows:DCP>

50

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7</ows:Operation>
...

8.2

GetTileWMTS servers may support KVP requests for representations of image Tiles bydeclaring support for and correctly handling GetTile requests.
8.2.1

GetTile request HTTP KVP encoding

Servers may implement HTTP GET transfer of the GetTile operation request, using KVP
encoding. The KVP encoding of the GetTile operation request SHALL use theparameters specified in Table 29 which follows the abstract description specified in Table
22 above.
Table 29 — GetTile operation request URL parameters
Name and example aService=WMTS
Request=GetTile
Version=1.0.0
Layer
Style
FormatSample dimensions b
TileMatrixSet
TileMatrix
TileRow
TileCol

Optionality and use
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Optional
Mandatory
Mandatory
Mandatory
Mandatory

Definition and format
Service type identifier
Operation nameStandard and schema version forthis operation
Layer identifier
Style identifier
Output format of tile
Value allowed for this dimension
TileMatrixSet identifier
TileMatrix identifier
Row index of tile matrix
Column index of tile matrix

a All parameter names are here listed using mostly lower case letters. However, any parameter name capitalization SHALL
be allowed in KVP encoding, see subclause 11.5.2 of OWS Common [OGC 06-121r3].
b Names for these parameters SHALL be the names indicated in the ServiceMetadata document. Typical examples are
Time, Elevation and Band.

Parameters in a GetTile request may be specified in any order. However, in order tofacilitate the caching mechanisms already available on the web, the parameters SHOULD
be specified in the exact order that appears in Table 29.
8.2.2

GetTile request HTTP KVP encoding example

An example GetTile operation request KVP encoded for HTTP GET is:
http://www.maps.bob/maps.cgi?service=WMTS&request=GetTile&version=1.0.0&
layer=etopo2&style=default&format=image/png&TileMatrixSet=WholeWorld_CRS_84&
TileMatrix=10m&TileRow=1&TileCol=3

Copyright © 2010 Open Geospatial Consortium Inc.

51

OGC 07-057r7
8.2.3

GetTile HTTP KVP encoding response

The normal response to a valid GetTile operation request SHALL be a tile map thatcomplies with the requested parameters and as described in subclause 7.2.1.
8.2.4

GetTile HTTP KVP encoding response example

A GetTile operation response for the GetTile request example in subclause 8.2.1 that
corresponds with the ServiceMetadata document shown in subclause 7.1.1.3 is shown on
Figure 12.

Figure 12 — GetTile response example
8.3

GetFeatureInfo

WMTS servers may support KVP requests for representations of documents furnishing
information related to the features at particular pixel positions on particular image Tiles
by declaring support for and correctly handling GetFeatureInfo requests.
8.3.1

GetFeatureInfo request HTTP KVP encoding

Servers may implement HTTP GET transfer of the GetFeatureInfo operation request,
using KVP encoding. The KVP encoding of the GetFeatureInfo operation request
SHALL follow the requirements for operation parameters specified in Table 30 that
follows the abstract description specified in Table 25 above.
Table 30 — GetFeatureInfo operation request URL parameters
Name and example aService=WMTS
Request=GetFeatureInfo
Version=1.0.0

52

Optionality and use
Mandatory
Mandatory
Mandatory

Definition and format
Service type identifier
Operation nameStandard and schema version forthis operation

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Name and example a
Sample dimensions b
Layer, Style, Format,

Sample dimensions,

TileMatrixSet,
TileMatrix, TileRow,
and TileCol
J
I
InfoFormat

Optionality and use
Optional
Optionality and use of theseparameters SHALL match
those in the corresponding
GetTile request described inTable 29
Mandatory
Mandatory
Mandatory

Definition and format
Value allowed for this dimension
The values of these parameters
SHALL match those in thecorresponding GetTile request
described in Table 29
Row index of a pixel in the tile
Column index of a pixel in the tile
Output format of the retrieved
informationa All parameter names are here listed using mostly lower case letters. However, any parameter name capitalization SHALL
be allowed in KVP encoding, see subclause 11.5.2 of OWS Common [OGC 06-121r3].
b Names for these parameters SHALL be the names indicated in the ServiceMetadata document. Typical examples are
Time, Elevation and Band.

Parameters in a GetFeatureInfo request may be specified in any order. However, in orderto facilitate the caching mechanisms already available on the web, the parameters
SHOULD be specified in the exact order that appears in Table 30
8.3.2

GetFeatureInfo request HTTP KVP encoding example

An example GetFeatureInfo operation request KVP encoded for HTTP GET is:
http://www.maps.bob/maps.cgi?service=WMTS&request=GetFeatureInfo&
version=1.0.0&layer=coastlines&style=default&format=image/png&
TileMatrixSet=WholeWorld_CRS_84&TileMatrix=10m&TileRow=1&TileCol=3&J=86&I=132&
InfoFormat=application/gml+xml; version=3.1

8.3.3

GetFeatureInfo HTTP KVP encoding response

The normal response to a valid GetFeatureInfo operation request SHALL be a
FeatureInfo document as described in subclause 7.3.1.
8.3.4

GetFeatureInfo HTTP KVP encoding response example

A GetFeatureInfo operation response for the GetFeatureInfo request example insubclause 8.3.1 may look like this:<?xml version="1.0" encoding="UTF-8"?><ReguralGriddedElevations xmlns="http://www.maps.bob/etopo2"
xmlns:gml="http://www.opengis.net/gml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.maps.bob/etopo2
GetFeatureInfoExampleSchema.xsd"><featureMember><GridPoint_etopo2><elevation>503.0</elevation><TileRow>1</TileRow><TileCol>2</TileCol><J>86</J><I>132</I></GridPoint_etopo2>

Copyright © 2010 Open Geospatial Consortium Inc.

53

OGC 07-057r7</featureMember></ReguralGriddedElevations>

8.4

Exceptions in HTTP KVP encoded operations

If an error is detected while processing an operation request encoded with KVP over
HTTP, the WMTS server SHALL generate an ExceptionReport element (as defined inclause 8.5 of OWS Common [OGC 06-121r3]) and which conforms to the schemas
described in Annex B.
9

WMTS using SOAP encoding

A WMTS server SHALL declare support for SOAP encoding for each operation bymeans of the OperationsMetadata section of its ServiceMetadata document as explainedin subclause 7.1.1.1.1. An example of this practice for GetCapabilities operation can beseen in subclause 9.1.2. Annex F contains information on how to write a WSDL
description document of the service.
9.1

GetCapabilities

9.1.1

GetCapabilities request SOAP encoding

Servers may also implement SOAP encoding using HTTP POST transfer of the
GetCapabilities operation request, using SOAP version 1.2 encoding.
9.1.2

GetCapabilities request SOAP encoding example

To request a WMTS ServiceMetadata document, a client could issue the following SOAP
encoded GetCapabilities operation request:<?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><GetCapabilities service="WMTS"
xmlns="http://www.opengis.net/ows/1.1"><AcceptVersions><Version>1.0.0</Version></AcceptVersions><AcceptFormats><OutputFormat>application/xml</OutputFormat></AcceptFormats></GetCapabilities></soap:Body></soap:Envelope>

9.1.3

GetCapabilities SOAP encoding response

In response to GetCapabilities operation request in SOAP encoding, a WMTS server
SHALL generate a document that looks like the one in subclause 7.1.1.3 wrapped in the
SOAP version 1.2 envelope.

54

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7
9.1.4

GetCapabilities SOAP encoding response example

The following fragment remarks the SOAP envelope and the encoding of GetCapabilities
response in the OperationsMetadata section:<?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><Capabilities version="1.0.0"
xmlns="http://www.opengis.net/wmts/1.0"
xmlns:ows="http://www.opengis.net/ows/1.1"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:gml="http://www.opengis.net/gml">...
<ows:OperationsMetadata><ows:Operation name="GetCapabilities"><ows:DCP><ows:HTTP><ows:Post
xlink:href="http://www.maps.bob/maps.cgi?"><ows:Constraint name="PostEncoding"><ows:AllowedValues><ows:Value>SOAP</ows:Value></ows:AllowedValues></ows:Constraint></ows:Post></ows:HTTP></ows:DCP></ows:Operation>...
<WSDL xlink:role="http://schemas.xmlsoap.org/wsdl/1.0"
xlink:show="none" xlink:type="simple"
xlink:href="wmtsConcrete.wsdl"/></Capabilities></soap:Body></soap:Envelope>

9.2

GetTile9.2.1

GetTile request SOAP encoding

Servers may also implement SOAP encoding using HTTP POST transfer of the GetTile
operation request, using SOAP version 1.2 encoding.
9.2.2

GetTile request SOAP encoding example

An example of the SOAP encoding of the GetTile operation request equivalent of therequest in subclause 8.2.1 is:<?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><GetTile service="WMTS" version="1.0.0"
xmlns="http://www.opengis.net/wmts/1.0"><Layer>etopo2</Layer>

Copyright © 2010 Open Geospatial Consortium Inc.

55

OGC 07-057r7<Style>default</Style><Format>image/png</Format><TileMatrixSet> WholeWorld_CRS_84</TileMatrixSet><TileMatrix>10m</TileMatrix><TileRow>1</TileRow><TileCol>3</TileCol></GetTile></soap:Body></soap:Envelope>

9.2.3

GetTile SOAP encoding response

The response of a successful SOAP-encoded GetTile operation request SHALL be animage with the MIME type specified by the Format parameter of the request, wrapped in
the SOAP version 1.2 envelope. If the image is binary (such as is the case with image/png
and image/jpeg images), it SHALL be base64 encoded and placed within the following
XML element:<element name="BinaryPayload"><complexType><sequence><element name="Format" type="ows:MimeType"/><element name="PayloadContent" type="base64Binary"/></sequence></complexType></element>

The xs:base64Binary type and associated base64-encoding rules are defined in the XML
Schema Part 2 W3C recommendation. MIME element includes the MIME type of theoriginal BinaryPayload.
NOTE 1 The reason for using embedded encoded data instead of linking to an external source is to allow
secured implementations.

Since the main part of the SOAP message is the base64 encoded binary content, base64
data SHOULD be enclosed inside a <![CDATA[ ]]>. This will prevent unnecessary parseof the base64 data resulting in a fast XML parse and validation.
NOTE 2 Current JavaScript XML parsers have limits on the length of the element content that are often
too low to contain a base64 256x256 image in a single element. It as been seen that the use of <![CDATA[]]> is a workaround for this limitation.

9.2.4

GetTile SOAP encoding response example

An example of the SOAP response may look like:<?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><wmts:BinaryPayload><wmts:Format>image/png</wmts:Format><wmts:BinaryContent><!-- base64-encoded --><![CDATA[R0lGODdh4AEOAfYAAOGW/9aM9MuC6L943LRu
0KlkxJ1auJJQrIdGoXs8lXAyiWUofVkecU4U

56

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7<!-- ... -->Ah0ianvIh+7Fb38oehcBI4NIiPdXhECyf4zY
iGNnOq7FcfZTiUJ1hfyjVCW3bJ3IiYEAADs=]]></wmts:BinaryContent></wmts:BinaryPayload></soap:Body></soap:Envelope>

9.3

GetFeatureInfo

9.3.1

GetFeatureInfo request SOAP encoding

Servers may also implement SOAP encoding using HTTP POST transfer of the
GetFeatureInfo operation request, using SOAP version 1.2 encoding.
9.3.2

GetFeatureInfo request SOAP encoding example

An example of the SOAP encoding of the GetFeatureInfo operation request equivalent of
the request in subclause 8.3.1 is:<?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><GetFeatureInfo service="WMTS" version="1.0.0"
xmlns="http://www.opengis.net/wmts/1.0"><GetTile service="WMTS" version="1.0.0"
xmlns="http://www.opengis.net/wmts/1.0"><Layer>etopo2</Layer><Style>default</Style><Format>image/png</Format><TileMatrixSet> WholeWorld_CRS_84</TileMatrixSet><TileMatrix>10m</TileMatrix><TileRow>1</TileRow><TileCol>3</TileCol></GetTile><J>86</J><I>132</I><InfoFormat>application/gml+xml; version=3.1</InfoFormat></GetFeatureInfo></soap:Body></soap:Envelope>

9.3.3

GetFeatureInfo SOAP encoding response

The response of a successful SOAP-encoded GetFeatureInfo operation request SHALL
be a document with the MIME type specified by the InfoFormat parameter of the request,
wrapped in the SOAP version 1.2 envelope.
Since the GetFeatureInfo response format does not mandate any particular response
format, the following flexible XML element that emphasizes the recommendation of
GML Simple Features Profile level 0 response format is shown below:<element name="FeatureInfoResponse"><complexType>

Copyright © 2010 Open Geospatial Consortium Inc.

57

OGC 07-057r7<choice><element ref="gml:_FeatureCollection"><element ref="wmts:TextPayload"><element ref="wmts:BinaryPayload"><element name="AnyContent" type="anyType"></choice></complexType></element>

9.3.4

GetFeatureInfo SOAP encoding response example

A GetFeatureInfo operation SOAP response for the GetFeatureInfo SOAP request
example in subclause 9.3.2 may look like this in GML encoding:<?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope
http://www.w3.org/2003/05/soap-envelope.xsd"><soap:Body><FeatureInfoResponse><ReguralGridedElevations
xmlns="http://www.maps.bob/etopo2"
xmlns:gml="http://www.opengis.net/gml"
xsi:schemaLocation="http://www.maps.bob/etopo2
wmtsGetFeatureInfo_response.xsd"><featureMember><GridPoint_etopo2><elevation>503.0</elevation><TileRow>1</TileRow><TileCol>2</TileCol><J>86</J><I>132</I></GridPoint_etopo2></featureMember></ReguralGridedElevations></FeatureInfoResponse></soap:Body></soap:Envelope>

A GetFeatureInfo operation SOAP response with the same information in HTML
encoding may look like this:<?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope
http://www.w3.org/2003/05/soap-envelope.xsd"><soap:Body><FeatureInfoResponse xmlns="http://www.opengis.net/wmts/1.0"
xmlns:gml="http://www.opengis.net/gml"
xsi:schemaLocation="http://www.opengis.net/wmts/1.0
wmtsGetFeatureInfo_response.xsd">

58

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7<TextPayload><Format>text/html</Format><TextContent><![CDATA[<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><HTML><title>GetFeatureInfoResponse<title><b>Elevation</b>503.0<br><b>TileRow</b>1<br><b>TileCol</b>2<br><b>J</b>86<br><b>I</b>132<br></HTML>]]></TextContent></TextPayload></FeatureInfoResponse></soap:Body></soap:Envelope>NOTE
XHTML.

The use of <![CDATA[ ]]> is needed for embedded HTML data but will not be needed for

A GetFeatureInfo operation SOAP response with the same information in arbitrary xml
encoding may look like this:<?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope
http://www.w3.org/2003/05/soap-envelope.xsd"><soap:Body><FeatureInfoResponse xmlns="http://www.opengis.net/wmts/1.0"
xmlns:gml="http://www.opengis.net/gml"
xsi:schemaLocation="http://www.opengis.net/wmts/1.0
wmtsGetFeatureInfo_response.xsd"><AnyContent><GridPoint_etopo2><elevation>503.0</elevation><TileRow>1</TileRow><TileCol>2</TileCol><J>86</J><I>132</I></GridPoint_etopo2></AnyContent></FeatureInfoResponse></soap:Body></soap:Envelope>

9.4

Exceptions in SOAP encoding

If an error is detected while processing an operation request encoded in a SOAP
envelope, the WMTS server SHALL generate a SOAP 1.2 response message where thecontent of the Body element is a Fault element containing an ExceptionReport element(as defined in clause 8.5 of OWS Common [OGC 06-121r3]). This SHALL be doneusing the following XML fragment:

Copyright © 2010 Open Geospatial Consortium Inc.

59

OGC 07-057r7<?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><soap:Fault><soap:Code><soap:Value>soap:Receiver</soap:Value></soap:Code><soap:Reason><soap:Text>A server exception was encountered.</soap:Text></soap:Reason><soap:Detail><ows:ExceptionReport
xmlns:ows="http://www.opengis.net/ows/1.1">…
</ows:ExceptionReport></soap:Detail></soap:Fault></soap:Body></soap:Envelope>

The Code element SHALL have the Value "soap:server" indicating that this is a server
exception. The Reason element SHALL have the Text "A Server exception was
encountered". This fixed string is used since the details of the exception SHALL be
specified in the Detail element using an ows:ExceptionReport element.
10 WMTS using RESTful
A WMTS server that supports HTTP RESTful SHALL declare support for each resourceby means of the ServiceMetadataURL (see Table 3) and the ResourceURL (see Table 6)elements of its ServiceMetadata document as explained in this clause. An example of thispractice can be seen in the Annex D.
The first step in the resource oriented architectural style is to identify the resources andthe relations between the resources. This version of WMTS standard identifies 3
resources: the service (ServiceMetadata), the map tiles (Tile) and the feature information
related to a pixel of a tile (FeatureInfo). The RESTful approach provides a way tomanipulate these resources via standard HTTP requests. This standard only defined theuse of HTTP GET to download resource representations (that are equivalent to the ones
that can be retrieved by the GetCapabilities, GetTile and GetFeatureInfo operations in theprocedure oriented architectural style).
NOTE 1 Some RESTful literature calls this action of retrieval (downloading) of a resource using HTTP
GET "GetResource" or "GetResourceRepresentation", the action to delete a resource using HTTP DELETE
DeleteResource, etc. This is useful to clarify the action of the HTTP operation but note that there is nooperation called explicitly GetResourceRepresentation operation in RESTful. The WMTS standard also
adopts this notation allowing easy extension to other future RESTful actions.

The RESTful encoding for WMTS consists of a set of canonical URLs to the service
metadata document, to tiles, and to FeatureInfo documents (one for each pixel). The
service metadata document is the single entry point and all other URL endpoints can beobtained by analyzing the templates contained in the ResourceURL elements of eachlayer element in the ServiceMetadata document.

60

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7
NOTE 2 Other ways of connecting resources were studied during WMTS standard elaboration andOWS-6 and URL templates seemed an interesting convenience that allows the description of thousands oftile URLs and millions of pixels FeatureInfo URLs with a few expressions rather than describing every
required URL endpoint individually.

10.1

ServiceMetadata resource (mandatory in resource oriented architectural style)10.1.1 GetResourceRepresentation request

In the resource oriented architectural style, clients will access the ServiceMetadata
document simply by requesting a file to a standard HTTP server using the URL. The
ServiceMetadata document SHALL have one or more <ServiceMetadataURL> elements
indicating a URL where this document can be obtained.
The URL referencing a ServiceMetadata document can have any form but werecommend the following syntax and format:{WMTSBaseURL}/1.0.0/WMTSCapabilities.xml

Clients can also specify the MIME type of the ServiceMetadata document by including
an "Accept: " parameter in the HTTP header of the request.
10.1.2 GetResourceRepresentation request example

To request WMTS ServiceMetadata document in XML format, from a WMTS server that
implements the resource oriented architectural style, a client could issue the following
RESTful URL:
http://www.maps.bob/1.0.0/WMTSCapabilities.xml

10.1.3 ServiceMetadata representation

In response to a valid request for a ServiceMetadata representation from a client, a
WMTS server SHALL send a ServiceMetadata document which conforms to the model
described in 7.1.1. Servers SHALL be able to respond with a ServiceMetadata documentin XML format (application/xml) that conforms to the XML schema described in Annex
B but other formats are also allowed.
10.1.4 ServiceMetadata representation example

In response to a valid request for a ServiceMetadata representation from a client, a
WMTS server might generate a document that looks like the one in subclause 7.1.1.3.
10.1.5 GetResourceRepresentation exception

If a client requests a document version or a format extension that is not available on aparticular server, the server SHALL return an HTTP Error 404 (File Not Found).

Copyright © 2010 Open Geospatial Consortium Inc.

61

OGC 07-057r7
10.2

Tile resource (mandatory in resource oriented architectural style)10.2.1 GetResourceRepresentation request

The ServiceMetadata document in the resource oriented architectural style MAY containa list of Layer elements and each layer that is available to be retrieved in this architectural
style SHALL have one or more <ResourceURL> elements with the "resourceType"
attribute set to "tile" and a template attribute. In this RESTful approach the template
attribute contains a URL template that can be converted to a URL by using a template
processor and then get the expected tile in the format specified by the attribute "format"
by requesting the resource with a standard HTTP GET.
<<DataType>>
URLTemplateDescription+ format : MimeType+ resourceType: CharacterString = "tile" {frozen}+ template: CharacterString

template is a
CharacterString but withthe same limitations thana URI (RFC2396) adding
support to "{" and "}"characters.

Figure 13 — URLTemplate for tile UML class diagram
Table 31 — Parts of the URLTemplate data structure for tiles
Names
formatformatresourceType

Definition
Format of the resource representationthat can be retrieved one resolved
the URL template
Resource type to be retrieved

Data type and values
ows:MimeTypeMultiplicity and use
One (mandatory)

Character String type,not empty
SHALL contain "tile"

One (mandatory)

URL template a.

Character String typebut with the same
limitations than a URI(RFC2396) adding
support to "{" and "}"characters.

One (mandatory)

resourceTypetemplate
templatea

A template processor will apply the rules in Table 32 to get a URL to a resource.

A template processor is a program or library that runs on the client side and converts a
URL template into a URL. It will have to process the URL template that contains variablenames marked off in matching braces ('{', '}') and substitute them with the corresponding
62

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

valid value. The template processor SHALL support the following variable names:"Style", "TileMatrixSet", "TileMatrix", "TileRow", "TileCol" and any dimension
identifier that has been defined for this layer in the element ./Dimension/ows:Identifier.
The template processor SHALL substitute the variable names by the values of theelements as shown in Table 32.
Possible values and ranges of the variables in the URL template can be extracted from theSeviceMetadata document parameters. The following table lists all the possible variablenames, their description, possible values and multiplicity. Assuming a ServiceMetadata
in XML format the possible values are also given using XPath expressions that point to
the ServiceMetadata document. When a relative XPath is used, it is relative to its layer
element of the ServiceMetadata document.
When a variable has only one possible value for this layer, the use of the direct value
instead of the variable is recommended on the URL template.
Table 32 — URL template variables and possible values for tile
URL template
variable

Meaning"style"Styleidentifier

identifier in Table 7./Dimension/
ows:IdentifierDimension
value

identifier in Table 9"TileMatrix
Set"

tile matrix
set
identifier
tile matrix
identifier

identifier in Table 6

row index
of tilematrixIf TileMatrixSetLimits is present, see Table 10,(./TileMatrixSetLimits), SHALL be any integer
value between MinTileRow and MaxTileRow inTable 12 (both included)(./tileMatrixSetLimits/tileMatrixLimits[./
TileMatrix={TileMatrix}]/MinTileRow and"TileMatrix""TileRow"

Possible values./style/ows:Identifier./Dimension[ows:Identifier={./Dimension/
ows:Identifier}]/Value./ TileMatrixSetLink/TileMatrixSet

identifier in Table 14/Capabilities/Contents/TileMatrixSet[
ows:Identifier={TileMatrixSet}]/TileMatrix/ ows:Identifier

Multiplicity
One(mandatory) a
One for eachdimension
available(mandatory if
there aredimensions
defined)One(mandatory) aOne(mandatory) aOne(mandatory) a./tileMatrixSetLimits/tileMatrixLimits[./T
ileMatrix={TileMatrix}]/MaxTileRow).

else SHALL be any integer value between 0 andMatrixHeight – 1, see Table 14, (both included) (0and/Capabilities/Contents/TileMatrixSet[ows:I
dentifier={TileMatrixSet}]/TileMatrix[ows:Identifier={TileMatrix}]/MatrixHeight – 1)

Copyright © 2010 Open Geospatial Consortium Inc.

63

OGC 07-057r7

URL template
variable

Meaning

Possible values"TileCol"col index of If TileMatrixSetLimits is present, see Table 10,
tile matrix (./TileMatrixSetLimits), SHALL be any integer
value between MinTileCol and MaxTileCol inTable 12 (both included)(./tileMatrixSetLimits/tileMatrixLimits[./
TileMatrix={TileMatrix}]/MinTileCol andMultiplicity
One(mandatory) a./tileMatrixSetLimits/tileMatrixLimits[./T
ileMatrix={TileMatrix}]/MaxTileCol)

else SHALL be any integer value between 0 andMatrixWidth – 1, see Table 14, (both included) (0and/Capabilities/Contents/TileMatrixSet[ows:I
dentifier={TileMatrixSet}]/TileMatrix[ows:Identifier={TileMatrix}]/ MatrixWidth – 1)

a When a variable has only one possible value for this layer the use of the direct value instead of the variable isrecommended.

Any possible order of the variables and values in the URL template is valid. Neverdeless
we recommend the following order:
style, firstDimension, ..., lastDimension, TileMatrixSet, TileMatrix, TileRow and TileCol
NOTE 1 It is not necessary for a file system with this particular structure to actually exist on the server.
A WMTS server implementation is free to parse the request URL itself and either remap the request to adifferent internal directory structure or generate the response on the fly (at the expense of speed).
NOTE 2 This syntax and processing is in-line with the pre-existing templating schemas present in
OpenSearch, WSDL and WADL and is a simplification of the description made by the IETF Network
Working Group in the Internet-Draft called "URI Template draft-gregorio-uritemplate-03".

10.2.2 GetResourceRepresentation request example

An example of a tile URL for a resource representation in RESTful HTTP GET
equivalent of the request in subclause 8.2.1 is:
http://www.maps.bob/etopo2/default/WholeWorld_CRS_84/10m/1/3.png

It corresponds to the following ResourceURL element:<ResourceURL format="image/png" resourceType="tile"
template="http://www.maps.bob/etopo2/default/{TileMatrixSet}/{TileMatrix}/{TileRow}/{TileCol}.png">

10.2.3 Tile representation

In response to a valid request for a Tile representation from a client, a WMTS server
SHALL send either an image representation of the tile or a reference to an image, as
stated in subclause 7.2.1. An image is the most typical representation but representationsin other formats are also allowed.
10.2.4 Tile representation example

The response could be the same image shown in subclause 8.2.4.
64

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7
10.2.5 GetResourceRepresentation exception

If the response of a GetResourceRepresentation request for a tile is unsuccessful, theserver SHALL return an HTTP error code that SHOULD be accompanied by an XML
ExceptionReport document as defined in subclause 8.5 of OWS Common [OGC 06121r3] and subclause 7.2.2.2 of this document. Determination of what error conditions
map to which HTTP error codes is up to the discretion of the server. If the error conditionis due to a malformed request or the resource does not exist (for instance in a request
URL with illegal path values), the HTTP error code returned SHOULD be HTTP Error
404 (File Not Found).
NOTE
For a server where the tile resource files actually exists and there is no specific application
capable of generating specific responses on the fly, HTTP error code SHALL be expected but an XML
ExceptionReport document cannot be expected.

10.3

FeatureInfo resource (optional in resource oriented architectural style)10.3.1 GetResourceRepresentation request

The ServiceMetadata document in the resource oriented architectural style may contain alist of Layer elements and each layer that is available to be retrieved in this architectural
style and is queryable SHALL have one or more <ResourceURL> elements with the"resourceType" attribute set to "FeatureInfo" and a template attribute. In this RESTful
approach the template attribute contains a URL template that can be converted to a URL
by using a template processor and then get the expected FeatureInfo in the format
specified by the attribute "format" by requesting the resource with a standard HTTP GET.
<<DataType>>
URLTemplate+ format : MimeType+ resourceType: CharacterString = "FeatureInfo" {frozen}+ template: URI

Figure 14 — URLTemplate for the FeatureInfo UML class diagram
Table 33 — Parts of the URLTemplate data structure for FeatureInfo
NamesformatformatresourceType

Definition
Format of the resource representationthat can be retrieved or resolved
from the URL template
Resource type to be retrieved

resourceTypetemplate

URL template a.

Data type and values
ows:MimeTypeMultiplicity and use
One (mandatory)

Character String type,not empty
SHALL contain"FeatureInfo"
URI

One (mandatory)

One (mandatory)

templatea

A template processor will apply the rules in Table 34 to get a URL to a resource.

Copyright © 2010 Open Geospatial Consortium Inc.

65

OGC 07-057r7

A template processor is a program or library that runs on the client side and converts a
URL template into a URL. It will have to process the URL template that contains variablenames marked off in matching braces ('{', '}') and substitute them with the corresponding
valid value. The template processor SHALL support the following variable names:"Style", "TileMatrixSet", "TileMatrix", "TileRow", "TileCol", "J", "I", and any
dimension identifier that has been defined for this layer in the element./Dimension/ows:Identifier. The template processor SHALL substitute the variable namesby the values shown in Table 34.
Possible values and ranges of the variables in the URL template can be extracted from theSeviceMetadata document parameters. The following table lists all the possible variablenames, their description, possible values and multiplicity. Assuming a ServiceMetadata
in XML format the possible values are also given using XPath expressions that point to
the ServiceMetadata document. When a relative XPath is used, it is relative to its layer
element of the ServiceMetadata document.
When a variable has only one possible value for this layer, the use of the direct value
instead of the variable is recommended on the URL template.
Table 34 — URL template variables and possible values for FeatureInfo
URL template
variable

Meaning"style"Styleidentifier

identifier in Table 7./Dimension/
ows:IdentifierDimension
value

identifier in Table 9"TileMatrix
Set"

tile matrix
set
identifier
tile matrix
identifier

identifier in Table 6"TileMatrix"

66

Possible values./style/ows:Identifier./Dimension[ows:Identifier={./Dimension/
ows:Identifier}]/Value./ TileMatrixSetLink/TileMatrixSet

identifier in Table 14/Capabilities/Contents/TileMatrixSet[
ows:Identifier={TileMatrixSet}]/TileMatrix/ ows:Identifier

Multiplicity
One(mandatory) a
One for eachdimension
available(mandatory if
there aredimensions
defined)One(mandatory) aOne(mandatory) a

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

URL template
variable

Meaning

Possible values

Multiplicity"TileRow"

row index
of tilematrixIf TileMatrixSetLimits is present, see Table 10,(./TileMatrixSetLimits), SHALL be any integer
value between MinTileRow and MaxTileRow inTable 12 (both included)(./tileMatrixSetLimits/tileMatrixLimits[./
TileMatrix={TileMatrix}]/MinTileRow andOne(mandatory) a./tileMatrixSetLimits/tileMatrixLimits[./T
ileMatrix={TileMatrix}]/MaxTileRow).

else SHALL be any integer value between 0 andMatrixHeight – 1, see Table 14, (both included) (0and/Capabilities/Contents/TileMatrixSet[ows:I
dentifier={TileMatrixSet}]/TileMatrix[ows:Identifier={TileMatrix}]/MatrixHeight – 1)
"TileCol"col index of If TileMatrixSetLimits is present, see Table 10,
tile matrix (./TileMatrixSetLimits), SHALL be any integer
value between MinTileCol and MaxTileCol inTable 12 (both included)(./tileMatrixSetLimits/tileMatrixLimits[./
TileMatrix={TileMatrix}]/MinTileCol andOne(mandatory) a./tileMatrixSetLimits/tileMatrixLimits[./T
ileMatrix={TileMatrix}]/MaxTileCol)

else SHALL be any integer value between 0 andMatrixWidth – 1, see Table 14, (both included) (0and/Capabilities/Contents/TileMatrixSet[ows:I
dentifier={TileMatrixSet}]/TileMatrix[ows:Identifier={TileMatrix}]/ MatrixWidth – 1)
"J"

"I"

Pixel rowindex in a
tile

SHALL be any integer value between 0 and
TileHeight-1 (see Table 14) (both included) (0 andOne(mandatory) a

Pixelcolumnindex in a
tile

SHALL be any integer value between 0 and
TileWidth -1 (see Table14) (both included) (0 andOne(mandatory) a/Capabilities/Contents/TileMatrixSet[ows:I
dentifier={TileMatrixSet}]/TileMatrix[ows:Identifier={TileMatrix}]/TileHeight – 1)

/Capabilities/Contents/TileMatrixSet[ows:I
dentifier={TileMatrixSet}]/TileMatrix[ows:Identifier={TileMatrix}]/TileWidth – 1)

a When a variable has only one possible value for this layer the use of the direct value instead of the variable isrecommended.

Any possible order of the variables and values in the URL template is valid. Neverdeless
we recommend the following order:
style, firstDimension, ..., lastDimension, TileMatrixSet, TileMatrix, TileRow, TileCol, J
and I.
NOTE
It is highly improbable that all of the GetFeatureInfo response file URLs physically exist in apractical implementation, so for a GetFeatureInfo-enabled server it seems inevitable that a RESTful server
implementation would generate them on the fly or cache them.

Copyright © 2010 Open Geospatial Consortium Inc.

67

OGC 07-057r7
10.3.2 GetResourceRepresentation request example

An example FeatureInfo request for a resource representation in RESTful HTTP GET
equivalent of request in subclause 8.2.1 ishttp://www.maps.bob/etopo2/
default/WholeWorld_CRS_84/10m/1/3/86/132.xml

It corresponds to the following ResourceURL element:<ResourceURL format="application/gml+xml; version=3.1"
resourceType="FeatureInfo"
template="http://www.maps.bob/etopo2/default/{TileMatrixSet}/{TileMatrix}/{TileRow}/{TileCol}/{J}/{I}.xml">

10.3.3 FeatureInfo representation

In response to a valid request for a FeatureInfo representation from a client, a WMTS
server SHALL send a document with information related to a particular pixel of a tile or areference to resources that represents the geographic data portrayed on that area, as statedin subclause 7.3.1. An XML document conforming GML Simple Features Profile [06049r1] is the most typical representation but other representations and formats are also
allowed.
10.3.4 FeatureInfo representation as an XML document example

The response could be the same xml document shown in subclause 8.3.4.
10.3.5 GetResourceRepresentation exception

If the response of a GetResourceRepresentation request for a FeatureInfo is unsuccessful
the server SHALL return an HTTP error code that SHOULD be accompanied by an XML
ExceptionReport document as defined in subclause 8.5 of OWS Common [OGC 06121r3] and subclause 7.3.2.2 of this document. Determination of what error conditions
map to which HTTP error codes is up to the discretion of the server. If the error conditionis due to a malformed request or the resource does not exist (for instance in a request
URL with illegal path values), the HTTP error code returned SHOULD be HTTP Error
404 (File Not Found).
11 Recommendations to improve interoperability and performance.
For maximum interoperability, this WMTS standard makes the following
recommendations.
11.1

Server and Client support for KVP, SOAP and RESTful

This specification defines 3 interfaces KVP, SOAP and RESTful. Clients and servers areencouraged to support as many interfaces as possible to improve interoperability. The
minimum recommended support is:68

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

A WMTS client SHOULD support both KVP and RESTful. SOAP support is optional.
A WMTS server SHOULD support KVP and/or 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 image/png and image/jpeg file formats.
The image/png image format is good for categorical maps and image/jpeg is better forimagery but since image/jpeg does not support transparency, image/png may be used forimages. 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 "application/gml+xml; version=3.1" and to follow GML Simple Features Profile [06049r1]. 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 areain 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 cachingoccurs at several levels, but for caching to occur at any of these levels cachingmechanisms need to know that resources are cachable. Servers should include appropriatecaching 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 indirectories that are directly accessed by generic internet servers, the expiration date of thedata 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 yourdata 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.

Copyright © 2010 Open Geospatial Consortium Inc.

69

OGC 07-057r7

HTTP 1.1, uses the "Cache-control" header. This header indicates a period of time tocache the data before expiration. If your data is guarantied to be static, or you know when
the data is going to be updated, you can use a convenient period of time in the Cachecontrol header.

70

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Annex A(normative)
Abstract test suite

A.1

Introduction

This abstract test suite specifies at a high level how server and client implementations of
this standard SHALL be tested for conformance to this standard. The framework for such
abstract test suites is specified in ISO 19105: Geographic information – Conformance andtesting, especially Clauses 7 and 9.
An abstract test suite contains multiple abstract tests, grouped into one or more test
modules. This abstract test suite consists of two top-level test modules:a) Client test module – Abstract tests for checking conformance of client implementations
with the requirements of this standard that are normatively referenced by thisImplementation Specification.
b) Server test module – Abstract tests for checking conformance of server
implementations with the requirements of this standard that are normatively referenced
by this Implementation Specification.
Any of these modules could contain lower-level test modules. At this time, only theServer test module contains lower-level test modules, namely:a) All operations implemented test module – Abstract tests for checking server properties
that are common to all operations implemented.
b) GetCapabilities, GetTile and GetFeatureInfo operation test module – Abstract tests forchecking server properties that are specific to an operation.
In the client and server test modules, all operations specified and implemented SHALL
be tested, including KVP HTTP GET, and SOAP HTTP POST transfer and RESTFul
HTTP GET transfer of each operation request. In the standard test module, all operations
specified SHALL be checked, including KVP HTTP GET, SOAP HTTP POST and
RESTFul HTTP GET transfer of operation requests. And all operation request andresponse parameters specified or implemented SHALL be tested. Of course, some
operations, transfer methods, and parameters are specified as optional implementation by
servers. Any optional item not implemented by a server SHALL not be tested. Also,
items not implemented by a client SHALL not be tested.

Copyright © 2010 Open Geospatial Consortium Inc.

71

OGC 07-057r7

A.2

Client test module

A.2.1

GetCapabilities operation requesta) Test Purpose: Verify that a client satisfies all requirements for a GetCapabilities
operation request.
b) Test Method: Generate an adequate sample of GetCapabilities operation requests
from the client, and verify that each is a valid request.
c) Reference: Subclause 7.1.2.1d) Test Type: Basic
A.2.2

GetTile operation requesta) Test Purpose: Verify that a client satisfies all requirements for a GetTile operation
request.
b) Test Method: Generate an adequate sample of GetTile operation requests from theclient, and verify that each is a valid request.
c) Reference: Subclause 7.2.2d) Test Type: Basic
A.2.3

Contiguous GetTile operation requestsa) Test Purpose: Verify that a client is capable of generating contiguous GetTile
operation requests.
b) Test Method: Generate adequate samples of GetTile operation requests from theclient, for tiles that are contiguous, and verify that the client is able to show themwithout any discontinuity.
c) Reference: Subclause 7.2.1 and 7.2.2d) Test Type: Capability
A.2.4

Overlay and transparency in GetTile operation requesta) Test Purpose: Verify that a client is capable to generating overlaying GetTile
operation requests, each one for a different layer.
b) Test Method: Generate adequate samples of GetTile operation requests from theclient, for tiles that overlays and verify that the client is able to show them correctly
overlaid and with a transparency when NODATA is present on the upper images
when the image format allows that.
c) Reference: Subclauses 7.2.1,7.2.2 and 11.3
72

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7d) Test Type: Capability
A.2.5

Different TileMatrixSets in GetTile operation requestsa) Test Purpose: Verify that a client can correctly overlay layers with layers having
different TileMatrixSets.
b) Test Method: Generate adequate samples of GetTile operation requests from theclient of tiles from layers with different TileMatrixSets, and verify that client is able
to show them correctly overlaid.
c) Reference: Subclauses 7.2.1 and 7.2.2d) Test Type: Capability
A.2.6

Optional GetFeatureInfo operation requesta) Test Purpose: Verify that a client satisfies all requirements for a GetFeatureInfo
operation requests.
b) Test Method: Generate an adequate sample of GetFeatureInfo operation requests
from the client, and verify that each is a valid request.
c) Reference: Subclause 7.3.2.1d) Test Type: Basic
A.2.7

GetTile and GetFeatureInfo operation request form ServiceMetadata content.

e) Test Purpose: Verify that a client is able to parse a GetCapabilities response andgenerate GetTile and GetFeatureInfo operation request.
f)

Test Method: Generate an adequate sample of GetCapabilities operation requests
from the client, and verify that the client is able to generate valid GetTile and
GetFeatureInfo requests conforming with the content section of the ServiceMetadata
document.

g) Reference: Subclause 7.1.1h) Test Type: Basic
A.3

Server test module

A.3.1

All operations implemented test module

A.3.1.1 HTTP protocol usagea) Test purpose: Verify that the rules and conventions governing the use of HTTP are
observed.
Copyright © 2010 Open Geospatial Consortium Inc.

73

OGC 07-057r7b) Test method: TBDc) Reference: RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1). See<http://www.ietf.org/rfc/rfc2616>.
d) Test type: Capability
A.3.1.2 Accept HTTP GET and POST transferred operation requestsa) Test Purpose: Verify that a server accepts HTTP GET and/or HTTP POST
transferred requests for each operation.
b) Test Method: Submit HTTP GET and/or HTTP POST transferred requests for each
operation. Verify that the server accepts and responds to these requests as specified andimplemented. Check that the server accepts at least one HTTP GET or HTTP POST
transfer of requests for each operation.
c) Reference: Clause 8, and 9d) Test Type: Capability
A.3.1.3 Handle KVP-encoded operation requestsa) Test Purpose: Verify that a server handles all parameter names in a KVP-encoded
operation request in a capitalization- and sequence-insensitive manner.
b) Test Method: Submit KVP-encoded GetCapabilities and other operation requests
containing parameter names using various combinations of cases, with a variety ofparameter sequences. Verify that the server provides the same response when the same
parameter names use different cases and combinations of cases.
c) Reference: Clause 8d) Test Type: Capability
A.3.1.4 Handle SOAP-encoded operation requestsa) Test Purpose: Verify that a server handles all parameters in a XML-encoded
operation request in a name-capitalization and parameter-sequence sensitive manner.
b) Test Method: Submit SOAP-encoded GetCapabilities request and other operation
requests containing parameters using correct and incorrect name capitalizations andparameter sequences. Verify that the server accepts all correct requests, and returns
ExceptionReport messages for all incorrect requests.
c) Reference: Clause 9d) Test Type: Capability
A.3.1.5 Handle HTTP GET RESTful -encoded operation requestsa) Test Purpose: Verify that a server handles a URL service metadata request.

74

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7b) Test Method: Request a Service metadata URL and other URL resources using correctand incorrect URLs. Verify that the server respond with the right resource to correct
URLs, and a returns HTTP errors for invalid URLs.
c) Reference: Clause 10d) Test Type: Capability
A.3.1.6 KVP and SOAP HTTP response status codea) Test purpose: Verify that a service request which generates an exception produces a
response that contains 1) a correct service exception report, and 2) the correct status
code indicating the error.
b) Test method: Check the response code in the Status-Line and the message body. Pass if
the response code is either 4xx (Client error) or 5xx (Server error) and the body contains
a service exception report. Fail otherwise.
c) Reference: RFC 2616, clause 11 and Subclauses 7.1.2.2, 7.2.2.2 and 7.3.2.2d) Test type: Capability
A.3.2
Style)

GetCapabilities operation request test module (Procedure Oriented Architectural

A.3.2.1 Accept HTTP GET transferred operation requestsa) Test Purpose: Verify that a server accepts at least HTTP GET transferred requests for
the GetCapabilities operation.
b) Test Method: Submit HTTP GET transferred requests for the GetCapabilities operation.
Verify that the server accepts and responds to these requests as specified.
c) Reference: Subclause 8.1.1d) Test Type: Capability
A.3.2.2 GetCapabilities operation responsea) Test Purpose: Verify that a server satisfies all requirements of the GetCapabilities
operation response.
b) Test Method: Make several GetCapabilities requests including a variety of input
parameters. Verify that the specified correct response is returned to each request.
c) Reference: Subclause 8.1.3d) Test Type: Capability
A.3.2.3 Version negotiationa) Test Purpose: Verify that a server satisfies the requirements for version negotiation.

Copyright © 2010 Open Geospatial Consortium Inc.

75

OGC 07-057r7b) Test Method: Submit GetCapabilities operation requests containing version numbers
lower than, higher than, and equal to the version supported by the server. Verify that theserver responses are in accord with the specified rules for version negotiation.
c) Reference: Subclause 7.3.2 of OWS Common [OGC 06-121r3]d) Test Type: Capability
A.3.2.4 Format selectiona) Test Purpose: Verify that a server satisfies the requirements for format selection, if
the server implements the AcceptFormats request parameter.
b) Test Method: Submit GetCapabilities operation requests containing supported andunsupported values for the AcceptFormats parameter. Verify that the server responses arein accord with the specified rules for format selection.
c) Reference: Subclause 7.3.5 of OWS Common [OGC 06-121r3]d) Test Type: Capability
A.3.2.5 Handling updateSequence parametera) Test Purpose: Verify that a server satisfies the requirements for generating and using
the updateSequence parameter, if the server implements the AcceptFormats request
parameter.
b) Test Method: Submit GetCapabilities operation requests containing correct and incorrect
values of the AcceptFormats parameter. Verify that the server provides the specified
correct response to each request.
c) Reference: Subclause 7.3.4 of OWS Common [OGC 06-121r3]d) Test Type: Capability
A.3.2.6 Section selectiona) Test Purpose: Verify that a server satisfies the requirements for using the Sections
parameter, if the server implements the Sections request parameter.
b) Test Method: Submit GetCapabilities operation requests containing various values andcombinations of values of the Sections parameter. Verify that the server provides the
specified correct response to each requestc) Reference: Subclause 7.1.2.1 and Table 18d) Test Type: Capability
A.3.3

ServiceMetadata resource test module (Resource Oriented Architectural Style)

A.3.3.1 Accept HTTP GET transferred operation requestsa) Test Purpose: Verify that a server sends a correct ServiceMetadata resource.

76

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7b) Test Method: Perform HTTP GET requests to the ServiceMetadata URL Verify that the
specified correct response is returned to each request.
c) Reference: Subclause 10.1.1d) Test Type: Capability
A.3.4

ServiceMetadata response

A.3.4.1 XML well formateda) Test purpose: Verify that the ServiceMetadata document is a valid xml document.
b) Test method: Submit GetCapabilities operation requests and verify that the returned
document is a well formed xml document.
c) Reference: Subclause 7.1.1d) Test type: Capability
A.3.4.2 XML references the normative schemaa) Test purpose: Verify that the normative content of the schema document referred toby the schemaLocation attribute in the ServiceMetadata document is identical to thenormative content of the on-line schema referred to in the Annex B.
b) Test method: Pass if the normative content of the schema document referred to by theschemaLocation attribute in the ServiceMetadata document is identical to thenormative content of the on-line schema referred to in the Annex B.1.
c) Reference: Subclause 7.1.1d) Test type: Capability
A.3.4.3 XML validates against the schemaa) Test purpose: Verify that the response to a GetCapabilities request validates against
the schema(s) provided with the schemaLocation attribute.
b) Test method: Pass if the response to a GetCapabilities request validates against theschema(s) provided with the schemaLocation attribute.
c) Reference: Subclause 7.1.1d) Test type: Capability
A.3.4.4 OnLineResource is an only resource prefixa) Test purpose: Verify that each OnlineResource URL intended for HTTP Get requests
in the ServiceMetadata document is a URL prefix.

Copyright © 2010 Open Geospatial Consortium Inc.

77

OGC 07-057r7b) Test method: Pass if each OnlineResource URL intended for HTTP Get requests in
the ServiceMetadata document is a URL prefix.
c) Reference: Subclause 7.1.1d) Test type: Capability
A.3.4.5 XML format for GetCapabilitiesa) Test purpose: Verify that the server advertises the application/xml format for the
GetCapabilities operation.
b) Test method: Pass if the server advertises the application/xml format for the
GetCapabilities operation.
c) Reference: Subclause 7.1.1d) Test type: Capability
A.3.4.6 ows:Constraint GetEncodinga) Test Purpose: Verify that a server satisfies the requirements for using theows:Constraint GetEncoding parameter, if the server implements the Sections request
parameter.
b) Test Method: Verify that the server provides a Service Metadata document that includes
ows:Constraint GetEncoding information on OperationsMetadata section. Verify thatthe server is able to respond the encodings specified.
c) Reference: Subclause 7.1.1d) Test Type: Capability
A.3.4.7 ows:Constraint PostEncodinga) Test Purpose: Verify that a server satisfies the requirements for using theows:Constraint PostEncoding parameter, if the server implements the Sections
request parameter.
b) Test Method: Verify that the server provides a Service Metadata document that includes
ows:Constraint PostEncoding information on OperationsMetadata section. Verify thatthe server is able to respond the encodings specified.
c) Reference: Subclause 7.1.1d) Test Type: Capability
A.3.4.8 Layer identifiersa) Test purpose: Verify that the layer identifiers are different.
b) Test method: Pass if all the layers have different non empty identifiers.

78

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7c) Reference: Subclause 7.1.1.1.2 and Table 6d) Test type: Capability
A.3.4.9 Layer LegendURL are correct resourcesa) Test purpose: Verify that the metadata for each of the LegendURL resources iscorrect.
b) Test method: Pass if all the submodules and subtests pass.
c) Reference: Subclause 7.1.1.1.2 and Table 8d) Test type: Capability
A.3.4.10 Layer LegendURL correct Formata) Test purpose: Verify that the MIME-type returned for the LegendURL resource is theadvertised format.
b) Test method: Pass if the MIME-type returned for the LegendURL resource is theadvertised format.
c) Reference: Subclause 7.1.1.1.2 and Table 11d) Test type: Capability
A.3.4.11 Layer LegendURL correct sizesa) Test purpose: Verify that the size of the LegendURL resource is the advertised width
and the advertised height.
b) Test method: Pass if the size of the LegendURL resource is the advertised width andthe advertised height.
c) Reference: Subclause 7.1.1.1.2 and Table 8d) Test type: Capability
A.3.4.12 Layer TileMatrixSet is valida) Test purpose: Verify that Layer TileMatrixSet contains a correct identifier.
b) Test method: Pass if Layer TileMatrixSet value is equal to a TileMatrixSet identifierin the content section.
c) Reference: Subclause 7.1.1.1.2 and Table 8d) Test type: Capability
A.3.4.13 TileMatrixSet Identifiera) Test purpose: Verify that TileMatrixSet identifiers are correct.
b) Test method: Pass if all TileMatrixSet have different non empty identifiers.

Copyright © 2010 Open Geospatial Consortium Inc.

79

OGC 07-057r7c) Reference: Subclause 7.1.1.1.2 and Table 13d) Test type: Capability
A.3.4.14 TileMatrix Identifiera) Test purpose: Verify that TileMatrix identifiers are correct.
b) Test method: Pass if all TileMatrix in a TileMatrixSet have different non empty
identifiers.
c) Reference: Subclause 7.1.1.1.2 and Table 14d) Test type: Capability
A.3.4.15 TileMatrixSet ScaleDenominatorsa) Test purpose: Verify that ScaleDenominator values are correct.
b) Test method: Pass if ScaleDenominators in a TileMatrixSet have different non empty
values.
c) Reference: Subclause 7.1.1.1.2 and Table 14d) Test type: Capability
A.3.4.16 TileMatrixSet WellKnownScaleSeta) Test purpose: Verify that a WellKnownScaleSet is compatible with
ScaleDenominator values.
b) Test method: When a WellKnownScaleSet is advertised, there has to be a TileMatrix
for each different ScaleDenominator with values starting from the largest scale
denominator in the WellKnownScaleSet table and all intermediate scales
denominators down to some ScaleDenominator minimum value for this Layer.
c) Reference: Subclause 7.1.1.1.2 and Table 14d) Test type: Capability
A.3.4.17 Theme LayerRef is valida) Test purpose: Verify that Theme LayerRef contains a correct identifier.
b) Test method: Pass if each Theme LayerRef value is equal to a Layer identifier in thecontent section.
c) Reference: Subclause 7.1.1.1.3 and Table 15d) Test type: Capability

80

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7
A.3.5

Tile request test module

A.3.5.1 GetTile Layera) Test purpose: Verify that when a request contains a Layer incorrect value, then theserver throws an exception.
b) Test method: When a request contains a Layer that is not advertised in theServiceMetadata document, then the server throws an exception (code=
InvalidParameterValue) in Procedure Oriented Architectural Style.
c) Reference: Subclause 7.2.2.2 and Table 26d) Test type: Capability
A.3.5.2 Tile ResourceURL templatea) Test Purpose: Verify that a client supports URL templates and server satisfies
RESTful requestsb) Test Method: Verify that the server provides a Service Metadata document that includes
complete ResourceURL information with resourceType=tile on Layer section if tilesof this layer are able for RESTful. Verify that the template processor in the client isable to convert the URL template in a correct URL to a tile and the server is able torespond RESTful requests.
c) Reference: Subclause 10.2.1d) Test Type: Capability
A.3.5.3 Tile TileMatrixSeta) Test purpose: Verify that when a request contains a TileMatrixSet incorrect value,then the server throws an exception.
b) Test method: When a request contains a TileMatrixSet value that is not advertised forthis Layer in the ServiceMetadata document, then the server throws an exception(code= InvalidParameterValue) in Procedure Oriented Architectural Style or a HTTP
404 File not found in Resource Oriented Architectural Style.
c) Reference: Subclause 7.2.2.2 and Table 26d) Test type: Capability
A.3.5.4 Tile TileMatrixa) Test purpose: Verify that when a request contains a TileMatrix incorrect value, thenthe server throws an exception.
b) Test method: When a request contains a TileMatrix value that is not advertised forthis TileMatrixSet in the ServiceMetadata document, then the server throws an
exception (code= InvalidParameterValue) in Procedure Oriented Architectural Styleor a HTTP 404 File not found in Resource Oriented Architectural Style.

Copyright © 2010 Open Geospatial Consortium Inc.

81

OGC 07-057r7c) Reference: Subclause 7.2.2.2 and Table 26d) Test type: Capability
A.3.5.5 Tile TileRow and TileCola) Test purpose: Verify that when a request contains a TileRow or TileCol incorrect,
then the server throws an exception.
b) Test method: When a request contains a TileRow or TileCol greater or equal toMatrixHeight and MatrixWidth respectively for the selected TileMatrix, then theserver throws an exception (code= TileOutOfRange) in Procedure Oriented
Architectural Style or a HTTP 404 File not found in Resource Oriented Architectural
Style.
c) Reference: Subclause 7.2.2.2 and Table 26d) Test type: Capability
A.3.5.6 Tile incorrect Sytlea) Test purpose: Verify that when a request contains a Style incorrect value, then theserver throws an exception.
b) Test method: When a request contains a Style value that is not advertised for this
Layer in the ServiceMetadata document, then the server throws an exception (code=
InvalidParameterValue) in Procedure Oriented Architectural Style or a HTTP 404
File not found in Resource Oriented Architectural Style.
c) Reference: Subclause 7.2.2.2 and Table 26d) Test type: Capability
A.3.5.7 Tile incorrect dimension valuea) Test purpose: Verify that when a request contains an incorrect dimension value, thenthe server throws an exception.
b) Test method: When a request contains a dimension value that is not advertised forthis Layer in the ServiceMetadata document, then the server throws an exception(code= InvalidParameterValue) in Procedure Oriented Architectural Style or a HTTP
404 File not found in Resource Oriented Architectural Style.
c) Reference: Subclause 7.2.2.2 and Table 26d) Test type: Capability
A.3.5.8 Tile dimension default and currenta) Test purpose: Verify that the server supports 'default' and 'current'.

82

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7b) Test method: When the ServiceMetadata document advertises a default value or thecurrent value support, request that uses the 'default' and 'current' keywords returns acorrect answer.
c) Reference: Subclause 7.1.1 Table 9d) Test type: Capability
A.3.5.9 GetTile incorrect Formata) Test purpose: Verify that when a request contains a Format incorrect value, then theserver throws an exception.
b) Test method: When a request contains a Format value that is not advertised for this
Layer in the ServiceMetadata document, then the server throws an exception (code=
InvalidParameterValue) in Procedure Oriented Architectural Stylec) Reference: Subclause 7.2.2.2 and Table 26d) Test type: Capability
A.3.5.10 Tile correct Formata) Test purpose: Verify that for each GetTile format, when the Format parameter is set
to that format or URLtemplate having a format parameter, the MIME type of the
response matches that format.
b) Test method: Pass if for each GetTile format, when the Format parameter is set tothat format, the MIME type of the response matches that format in Procedure
Oriented Architectural Style or the URL template format of the response matches
that format in Resource Oriented Architectural Stylec) Reference: Subclause 7.2.1 and 10.2.1d) Test type: Capability
A.3.5.11 GetTile sizea) Test purpose: Verify that the returned tile has the correct size.
b) Test method: Send a correct request for each TileMatrix in the TileMatrixSet of aLayer and the test passes if width and height of the returned image are equal to theadvertised values in TileWidth and TileHeight in the ServiceMetadata.
c) Reference: Subclause 7.2.1d) Test type: Capability
A.3.5.12 GetTile transparent colora) Test purpose: Verify that the returned tile has transparent color for NODATA values.

Copyright © 2010 Open Geospatial Consortium Inc.

83

OGC 07-057r7b) Test method: Send a correct request for a Layer in a format that supports
transparency and in a tile where NODATA values are expected and test fortransparent color there.
c) Reference: Subclause 7.2.1d) Test type: Capability
A.3.6

FeatureInfo request test module

In order to pass this test module test A.3.5.1 to A.3.5.9 has to be also passed.
A.3.6.1 GetTileFeatureInfo on non-queryable layera) Test purpose: Verify that when a request to a non-queryable layer, then the serverthrows an exception.
b) Test method: When a GetFeatureInfo is requested on a Layer that not advertises any
InfoFormat in the ServiceMetadata document, then the server throws an exception(code=OperationNotSupported) in Procedure Oriented Architectural Stylec) Reference: Subclause 7.3.2.2d) Test type: Capability
A.3.5.2 FeatureInfo ResourceURL templatea) Test Purpose: Verify that a client supports URL templates and server satisfies
RESTful requestsb) Test Method: Verify that the server provides a ServiceMetadata document that includes
complete ResourceURL information with resourceType=FeatureInfo on Layer section
if FeatureInfos of this layer are able for RESTful. Verify that the template processor
in the client is able to convert the URL template in a correct URL to a FeatureInfo
and the server is able to respond RESTful requests.
c) Reference: Subclause 10.2.1d) Test Type: Capability
A.3.6.2 GetFeatureInfo incorrect InfoFormata) Test purpose: Verify that when a request contains an InfoFormat incorrect value, thenthe server throws an exception.
b) Test method: When a request contains an InfoFormat value that is not advertised forthis Layer in the ServiceMetadata document, then the server throws an exception(code= InvalidParameterValue) in Procedure Oriented Architectural Style.
c) Reference: Subclause 7.3.2.2d) Test type: Capability

84

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7
A.3.6.3 FeatureInfo correct InfoFormata) Test purpose: Verify that for each GetTile format, when the InfoFormat parameter is
set to that format or URLtemplate having a format parameter, the MIME type of the
response matches that format.
b) Test method: Pass if for each GetTile format, when the InfoFormat parameter is set
to that format, the MIME type of the response matches that format or the URL
template format of the response matches that format in Resource Oriented
Architectural Stylec) Reference: Subclause 7.3.1 and 10.3.1d) Test type: Capability
A.3.6.4 FeatureInfo J and Ia) Test purpose: Verify that when a request contains an I or J incorrect, then the serverthrows an exception.
b) Test method: When a request contains an I or J greater or equal to TileHeight and
TileWidth respectively for the selected TileMatrix, then the server throws an
exception (code=PointIJOutOfRange) in Procedure Oriented Architectural Style or a
HTTP 404 File not found in Resource Oriented Architectural Style.
c) Reference: Subclause 7.3.2.2d) Test type: Capability

Copyright © 2010 Open Geospatial Consortium Inc.

85

OGC 07-057r7

Annex B
(normative)
XML Schema Documents

In addition to this document, this standard includes several normative XML Schema
Documents. These XML Schema Documents may be bundled in a zip file with thepresent document. After OGC acceptance of a Version 1.0.0 of this standard, these XML
Schema Documents will also be posted online at the URL
http://schemas.opengis.net/wmts/1.0.0. In the event of a discrepancy between the bundled
and online versions of the XML Schema Documents, the online files SHALL beconsidered authoritative.
The WMTS abilities specified in this document use one specified XML Schema
Documents included in the zip file with this document. These XML Schema Documents
combine the XML schema fragments listed in various subclauses of this document,eliminating duplications. These XML Schema Documents are named:
wmtsGetCapabilities_request.xsd
wmtsGetCapabilities_response.xsd
wmtsGetTile_request.xsd
wmtsGetFeatureInfo_request.xsd
wmtsGetFeatureInfo_response.xsd
wmtsPayload_response.xsd
In addition, the following XML Schema Documents imported by WSDL documents areused in the annex F and are also included:
wmts.xsd
wmtsKVP.xsd
These XML Schema Documents use and build on the OWS common XML Schema
Documents specified OWS Common [OGC 06-121r3], named:
ows19115subset.xsd
owsCommon.xsd
owsDataIdentification.xsd
owsExceptionReport.xsd
owsGetCapabilities.xsd
owsOperationsMetadata.xsd
owsServiceIdentification.xsd
86

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

owsServiceProvider.xsd
All these XML Schema Documents contain documentation of the meaning of eachelement and attribute, and this documentation SHALL be considered normative as
specified in subclause 11.6.3 of OWS Common [OGC 06-121r3].
Also complete examples for KVP, SOAP and RESTful can be found on the zip file andon the portal. Some fragments of these examples are shown throughout this document.

Copyright © 2010 Open Geospatial Consortium Inc.

87

OGC 07-057r7

Annex C
(informative)
UML model

C.1

Introduction

This annex provides a UML model of the WMTS interface, using the OGC/ISO profile of
UML summarized in subclause 5.2 of [06-121r3].
Figure C.1 is a simple UML diagram summarizing the WMTS interface. This class
diagram shows that the WMTS class inherits the getCapabilities operation from the
OGCWebService interface class, and adds the getTile and getFeatureInfo operations.
(The capitalization of names uses the OGC/ISO profile of UML.)<<Interface>>
OGCWebService {Abstract}(from OGC Web Service)+ getCapabilities(request : GetCapabilities) : Capabilities

WMTService+ getTile(request : GetTile) : GetTile Response+ getFeatureInfo(request : GetFeatureInfo) : GetFeatureInfoResponse

Each server instance instantiates only one object of this classand this object always exists while server is available.

Figure C.1 — WMTS interface UML diagram
Each of the three operations uses a request and a response data type, each of which isdefined by one or more additional UML classes. The following subclauses provide amore complete UML model of the WMTS interface, adding UML classes defining theoperation request and response data types.

88

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

C.2

UML packages

The WMTS interface UML model is organized in six packages that will be described in
the following subclauses. These six WMTS-specific packages make use of six nonWMTS-specific packages, named OWS Web Service, OWS Operations Metadata, OWS
Service Identification, OWS Service Provider, and ISO 19115 Subset. This package
diagram shows the dependencies among the various packages shown.
Get Tile+ TileRequestType+ TileRequestParametersType+ TileAttributsType+ TilePositionType+ SampleDimensionsType

WMTS Service+ WMTSRequestBase {Abstract}+ WMTService

WMTS Get Capabilities+ WMTSserviceMetadata+ WMTSGetCapabilities

Get Feature Info
+ FeatureInfoRequestParameters+ PixelPointType

OWS Web Service(from OWS Packages)+ GetCapabilities {Abstract}+ OWService {Abstract}+ RequestBase {Abstract}+ Section+ ServiceMetadata {Abstract}

WMTS Contents+ LayerTypeStyleType+ LegendURLType+`DimensionsType+ TileMatrixSetType+ TileMatrixType
WMTS Themes+ ThemeDescription

OWS Operations Metadata(from OWS Packages)+ DCP+ Domain+ ExtendedCapabilities {Abstract}+ HTTP+ Metadata+ Operation+ OperationsMetadata+ PostOWS Service
Identification(from OWS Packages)+ ServiceIdentification+ ServiceProvider

ISO 19115 Subset(from Logical View)+ Address+ Contact+ Keywords+ OnlineResource+ ResponsibleParty+ Telephone

OWS Service Provider(from OWS Packages)+ ServiceProvider

Figure C.2 — WMTS interface package diagram
Each of the three WMTS-specific packages shown in Figure C.2 is described in thefollowing subclauses. The OWS Web Service, OWS Operations Metadata, OWS Service
Identification, OWS Service Provider, and ISO 19115 Subset packages are described in
the Annex C of OWS Common [OGC 06-121r3].

Copyright © 2010 Open Geospatial Consortium Inc.

89

OGC 07-057r7

C.3

WMTS Service package

The WMTS Service package is shown in the class diagram in Figure C.3. This diagram
does not show the classes used by the WMTS operation requests and responses, which
are shown (with part of this package) in the WMTS Get Capabilities, Get Tile and Get
Feature Info packages. This diagram also shows RequestBase used classes from the OWS
Web Service package, which is common to all OGC Web Services, plus one used classfrom the WMTS package.
<<Interface>>
OWService {Abstract}(from OWS Web Service)+ getCapabilities(request : GetCapabilities) : Capabilities Response

WMTService+ getTile(request : GetTile) : Tile Response+ getFeatureInfo(request : GetFeatureInfo) : FeatureInfo Response

Each server instance conceptually instantiates only one objectof this class and this object always exists while server isavailable.
RequestBase {Abstract}

LanguageString(from OWS Web Service)(from ISO 19115 Subset)+ service : CharacterString+ request : CharacterString+ version : CharacterString+ value : CharacterString+ language [0..1]: CharacterString

Code(from ISO 19115 Subset)<<DataType>>
WMTSRequestBase {Abstract}+ service : CharacterString = "WMTS" {frozen}+ code : CharacterString+ codeSpace [0..1]: URI

Figure C.3 — WMTS Service package class diagram

90

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

C.4

WMTS Get Capabilities, Contents and Themes packages

The WMTS Get Capabilities package is shown in the class diagram in Figure C.4, C.5
and C.6. This diagram also shows several classes from the OWS package. The classes
introduced by this package are further defined by Table 2 through Table 16 in thisdocument.
<<Interface>>
OWService {Abstract}(from OWS Web Service)+ getCapabilities(request : GetCapabilities) : Capabilities

Capabilities (Abstract)
GetCapabilities (Abstract)(from OWS Get Capabilities)(from OWS Get Capabilities))+ version : CharacterString+ updateSequence [0..1] : CharacterString+ wsdl [0..1]: URL+ serviceMetadataURL [0..1]: URL+ service : CharacterString+ request : CharacterString = "GetCapabilities" {frozen}+ acceptVersions[0..1] : Sequence < CharacterString>

1+serviceIdentification

1

1

1

1

0..1

ServiceIdentification(from OWS Service Identification)+operationsMetadata

0..1

OperationsMetadata(from OWS Operations Metadata)+serviceProvider

0..1

ServiceProvider(from OWS Service Provider)

WMTSGetCapabilities+ service : CharacterString = "WMTS" {frozen}+contents

0..1

Contents(from OWS contents)+themes

0..*

Themes(from WMTS GetCapabilities)

Figure C.4 — Get Capabilities package class diagram, part 1

Copyright © 2010 Open Geospatial Consortium Inc.

91

OGC 07-057r7
Description(from OWS Data Identitfication)+ title [0..*] : LanguageString+ abstract [0..1]: LanguageString1+keywords+ abstract [0..*] : LanguageString
Contents
0..*

MD_Keywords+ otherSources [0..*] : URL(from OWS Contents)(from ISO 19115 subset+ keyword [1..*] : LanguageString

1<<DataType>>
TileMatrixSet
1+ identifier : CodeType+ SuportedCRS [0..1]: URI+ wellKnownScaleSet : URI

0..*

DatasetDescriptionSummary

1+layer+tileMatrix 1..*

Layer
1..*

+tileMatrixSet+ identifier : CodeType+ format [1..*]: MimeType+ infoFormat [0..*]: MimeType

TileMatrixSet+ resourceURL [0..*]: URLtemplateDescriptionType1+style

1

1

1

1

1

1 +tileMatrixSetLink

1..*<<DataType>>
Style

TileMatrixSetLink+ tileMatrixSet [1..*]: URI+ identifier : CodeType+ title [0..1]: LanguageString+ abstract [0..1]: LanguageString+ keywords [0..*]: MD_Keywords+ isDefault [0..1]: Boolean

0..*+dimensions<<DataType>>
Dimensions

1+legendÜRL

+ identifier : CodeType+ title [0..1]: LanguageString+ abstract [0..1]: LanguageString+ keywords [0..*]: MD_Keywords+ UOM : DomainMetadata+ unitsSimbol : CharacterString+ default: CharacterString+ current: CharacterString+ value [1..*] : CharacterString

0..*<<DataType>>
LegendURL+ format : CharacterString+ minScaleDenominator: double+ maxScaleDenomnator: double+ href: URI+ width: integer+ height: integer

0..1 +WGS84BoundingBox+ metadata

Metadata(from OWS Common)+ metadata [0..1]: Any+ link [0..1]: URL+ about [0..1]: URI

0..*

WGS84BoundingBox(From OWS Contents)+ lowerCorner : Sequence <Number, 2>+ upperCorner : Sequence <Number, 2>+ crs [0..1]: "urn:ogc:def:crs:CRS::84"+ dimensions [0..1] PositiveInteger=2

1<<DataType>>
TileMatrix+ identifier : CodeType+ scaleDenominator : <Number>+ topLeftCorner : Sequence <Number, 2>+ tileWitdh: PositiveInteger+ tileHeight: PositiveInteger+ matrixWitdh: PositiveInteger+ matrixHeight: PositiveInteger

0..* +boundaryBox+boundaryBox

BoundingBox(From OWS Contents)+ lowerCorner : Sequence <Number, 2>+ upperCorner : Sequence <Number, 2>+ crs [0..1]: URI+ dimensions [0..1] PositiveInteger

0..1 + tileMatrixSetLimits<<DataType>>
TileMatrixSetLimits
1
0..* + tileMatrixLimits

TileMatrixLimits+ tileMatrix: URI+ minTileRow: integer+ maxTileRow: integer+ minTileCol: integer+ maxTileCol: integer
TileMatrixSetLimits

Figure C.5 — Get Capabilities package class diagram, part 2

92

1

Copyright © 2010 Open Geospatial Consortium Inc.

0..1

OGC 07-057r7

Description(from OWS Data Identitfication)+ title [0..*] : LanguageString+ abstract [0..*] : LanguageString<<DataType>>
URLTemplate+ format : MimeType+ resourceType: CharacterString+ template: CharacterString1+keywords

0..*

MD_Keywords(from ISO 19115 subset+ keyword [1..*] : LanguageString

Themestemplate is a
CharacterString but withthe same limitations thana URI (RFC2396) adding
support to "{ "and "}"characters.

1+ theme0..*<<DataType>>
Theme+ identifier : CodeType+ theme [0..n] : Theme+ layerRef [0..n]: URI

Figure C.6 — Get Capabilities package class diagram, part 3

Copyright © 2010 Open Geospatial Consortium Inc.

93

OGC 07-057r7

C.5

WMTS Get Tile package

The WMTS Get Tile package is shown in the class diagram in Figure C.7. This diagram
also shows several classes from the OWS package. The classes introduced by thispackage are further defined by Table 22 in this document.
<<Interface>>
OWService {Abstract}+ getTile(request : GetTile) : TileResponse

RequestBase (Abstract)(from OWS Get Capabilities)

TileResponse+ service : CharacterString+ request : CharacterString+ version : CharacterString+ map : byte[]+ type : MimeType

WMTSGetCapabilities(from WMTS Service)+ service : CharacterString = "WMTS" {frozen}

TileRequest

1+ request : CharacterString = "GetTile" {frozen}<<DataType>>
TileAttributes+ format : ows:MimeType+ tilePosition : TilePosition
11<<DataType>>
TilePosition

1<<DataType>>
TileRequestParameters

1+ layer : CharacterString
1 + style : CharacterString
1
0..1<<DataType>>
SampleDimensions+ elevation [0..1] : Double+ otherSampleDimensions [0..*]: CharacterString+ time [0..1] : CharacterString+ tileMatrixSet: CharacterString+ tileCol : Integer+ tileRow : Integer+ tileMatrix : CharacterString

Figure C.7 — Get Tile package class diagram

94

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Table C.1 — Mapping of UML TileRequest attributes and HTTP GetTile request
parameters
UML attribute

HTTP request parametersservice

ServicerequestRequestversionVersion

layer

Layer

style

Style

tileAttributes

TileMatrixSet, TileMatrix, TileRow, TileCol,
FormatsampleDimensions

Time, Elevation, SampleDimensions

Copyright © 2010 Open Geospatial Consortium Inc.

95

OGC 07-057r7

C.6

WMTS Get Feature Info package

The WMTS Get Feature Info package is shown in the class diagram in Figure C.8. This
diagram also shows several classes from the OWS and WMTS packages. The classes
introduced by this package are further defined by Table 25 in this document.
<<Interface>>
OWService {Abstract}+ getFeatureInto(request : GetFeaturelnfo) : FeatureInfoResponse

RequestBase (Abstract)
FeatureInfoResponse(from OWS Get Capabilities)+ service : CharacterString+ request : CharacterString+ version : CharacterString

The use of GML
Simple Features
Profile [OGC 06049r1] is strongly
recommended, as
is text/html+ featureInfo : byte[]+ type : MimeType

WMTSGetCapabilities(from WMTS Service)+ service : CharacterString = "WMTS" {frozen}

FeatureInfoRequest+ request : CharacterString = "GetFeatureInfo" {frozen}

11

TileRequestParameters(from WMTS Get Tile)

1
TileAttributes(from WMTS Get Tile)1+ layer : CharacterString
1 + style : CharacterString+ format : ows:MimeType+ tilePosition : TilePosition

1
0..1
SampleDimensions

1(from WMTS Get Tile)1+ elevation [0..1] : Double+ otherSampleDimensions [0..*]: CharacterString+ time [0..1] : CharacterString

TilePosition(from WMTS Get Tile)+ tileMatrixSet: CharacterString+ tileCol : Integer+ tileRow : Integer+ tileMatrix : CharacterString
1<<DataType>>

FeatureInfoRequestParameters+ infoFormat : FormatType+ point : PixelPoint

PixelPoint1

1 + i : integer+ j : integer

Figure C.8 — Get Feature Info package class diagram

96

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Table C.2 — Mapping of UML FeatureInfoRequest attributes and HTTP
GetFeatureInfo request parameters
UML attribute

HTTP request parametersservice

ServicerequestRequestversionVersion

layer

Layer

style

Style

tileAttributes

TileMatrixSet, TileMatrix, TileRow, TileCol,
FormatsampleDimensions

Time, Elevation, SampleDimensions

infoFormat

InfoFormat

point

J, I

Copyright © 2010 Open Geospatial Consortium Inc.

97

OGC 07-057r7

Annex D
(informative)
Example XML documents

D.1

Introduction

This annex provides more example XML documents than given in the body of thisdocument. Particularly it includes an XML example for RESTful approach.
D.2

ServiceMetadata response example

This is a complete example of ServiceMetadata response with RESTful and KVP
support.
<?xml version="1.0" encoding="UTF-8"?><Capabilities xmlns="http://www.opengis.net/wmts/1.0"
xmlns:ows="http://www.opengis.net/ows/1.1"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:gml="http://www.opengis.net/gml"
xsi:schemaLocation="http://www.opengis.net/wmts/1.0
http://schemas.opengis.net/wmts/1.0.0/wmtsGetCapabilities_response.xsd"
version="1.0.0"><ows:ServiceIdentification><ows:Title>Web Map Tile Service</ows:Title><ows:Abstract>Service that contrains the map
access interface to some TileMatrixSets</ows:Abstract><ows:Keywords><ows:Keyword>tile</ows:Keyword><ows:Keyword>tile matrix set</ows:Keyword><ows:Keyword>map</ows:Keyword></ows:Keywords><ows:ServiceType>OGC WMTS</ows:ServiceType><ows:ServiceTypeVersion>1.0.0</ows:ServiceTypeVersion><ows:Fees>none</ows:Fees><ows:AccessConstraints>none</ows:AccessConstraints></ows:ServiceIdentification><ows:ServiceProvider><ows:ProviderName>MiraMon</ows:ProviderName><ows:ProviderSite xlink:href="http://www.creaf.uab.cat/miramon"/><ows:ServiceContact><ows:IndividualName>Joan Maso Pau</ows:IndividualName><ows:PositionName>Senior Software Engineer</ows:PositionName><ows:ContactInfo><ows:Phone><ows:Voice>+34 93 581 1312</ows:Voice><ows:Facsimile>+34 93 581 4151</ows:Facsimile></ows:Phone><ows:Address>

98

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7<ows:DeliveryPoint>Fac Ciencies UAB</ows:DeliveryPoint><ows:City>Bellaterra</ows:City><ows:AdministrativeArea>Barcelona</ows:AdministrativeArea><ows:PostalCode>08193</ows:PostalCode><ows:Country>Spain</ows:Country><ows:ElectronicMailAddress>joan.maso@uab.cat</ows:ElectronicMailAddress></ows:Address></ows:ContactInfo></ows:ServiceContact></ows:ServiceProvider><ows:OperationsMetadata><ows:Operation name="GetCapabilities"><ows:DCP><ows:HTTP><ows:Get xlink:href="http://www.maps.bob/cgi-bin/MiraMon5_0.cgi?"><ows:Constraint name="GetEncoding"><ows:AllowedValues><ows:Value>KVP</ows:Value></ows:AllowedValues></ows:Constraint></ows:Get></ows:HTTP></ows:DCP></ows:Operation><ows:Operation name="GetTile"><ows:DCP><ows:HTTP><ows:Get xlink:href="http://www.maps.bob/cgi-bin/MiraMon5_0.cgi?"><ows:Constraint name="GetEncoding"><ows:AllowedValues><ows:Value>KVP</ows:Value></ows:AllowedValues></ows:Constraint></ows:Get></ows:HTTP></ows:DCP></ows:Operation></ows:OperationsMetadata><Contents><Layer><ows:Title>Blue Marble Next Generation</ows:Title><ows:Abstract>Blue Marble Next Generation NASA Product</ows:Abstract><ows:WGS84BoundingBox><ows:LowerCorner>-180 -90</ows:LowerCorner><ows:UpperCorner>180 90</ows:UpperCorner></ows:WGS84BoundingBox><ows:Identifier>BlueMarbleNextGeneration</ows:Identifier><Style isDefault="true"><ows:Identifier>Default</ows:Identifier></Style><Format>image/jpeg</Format><TileMatrixSetLink><TileMatrixSet>BigWorldPixel</TileMatrixSet>

Copyright © 2010 Open Geospatial Consortium Inc.

99

OGC 07-057r7</TileMatrixSetLink><ResourceURL format="image/png" resourceType="tile"
template="http://www.maps.bob/wmts/BlueMarbleNextGeneration/
default/BigWorldPixel/{TileMatrix}/{TileRow}/{TileCol}.png"/></Layer><TileMatrixSet><ows:Identifier>BigWorldPixel</ows:Identifier><ows:SupportedCRS>urn:ogc:def:crs:OGC:1.3:CRS84</ows:SupportedCRS><WellKnownScaleSet>urn:ogc:def:wkss:OGC:1.0:GlobalCRS84Pixel</WellKnownScaleSet><TileMatrix><ows:Identifier>10000m</ows:Identifier><ScaleDenominator>33130800.83133142</ScaleDenominator><TopLeftCorner>-180 90</TopLeftCorner><TileWidth>640</TileWidth><TileHeight>480</TileHeight><MatrixWidth>7</MatrixWidth><MatrixHeight>5</MatrixHeight></TileMatrix><TileMatrix><ows:Identifier>20000m</ows:Identifier><ScaleDenominator>66261601.66266284</ScaleDenominator><TopLeftCorner>-180 90</TopLeftCorner><TileWidth>640</TileWidth><TileHeight>480</TileHeight><MatrixWidth>4</MatrixWidth><MatrixHeight>3</MatrixHeight></TileMatrix><TileMatrix><ows:Identifier>40000m</ows:Identifier><ScaleDenominator>132523203.3253257</ScaleDenominator><TopLeftCorner>-180 90</TopLeftCorner><TileWidth>640</TileWidth><TileHeight>480</TileHeight><MatrixWidth>2</MatrixWidth><MatrixHeight>2</MatrixHeight></TileMatrix><TileMatrix><ows:Identifier>60000m</ows:Identifier><ScaleDenominator>198784804.9879885</ScaleDenominator><TopLeftCorner>-180 90</TopLeftCorner><TileWidth>640</TileWidth><TileHeight>480</TileHeight><MatrixWidth>1</MatrixWidth><MatrixHeight>1</MatrixHeight></TileMatrix><TileMatrix><ows:Identifier>120000m</ows:Identifier><ScaleDenominator>397569609.9759771</ScaleDenominator><TopLeftCorner>-180 90</TopLeftCorner><TileWidth>640</TileWidth><TileHeight>480</TileHeight><MatrixWidth>1</MatrixWidth><MatrixHeight>1</MatrixHeight></TileMatrix><TileMatrix><ows:Identifier>240000m</ows:Identifier>100

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7<ScaleDenominator>795139219.9519541</ScaleDenominator><TopLeftCorner>-180 90</TopLeftCorner><TileWidth>640</TileWidth><TileHeight>480</TileHeight><MatrixWidth>1</MatrixWidth><MatrixHeight>1</MatrixHeight></TileMatrix></TileMatrixSet></Contents><ServiceMetadataURL
xlink:href="http://www.maps.bob/wmts/1.0.0/WMTSCapabilities.xml"/></Capabilities>

Copyright © 2010 Open Geospatial Consortium Inc.

101

OGC 07-057r7

Annex E
(informative)
Well-known scale sets
The following well-known scale sets are defined in this standard. To be conformant to thesewell-known scale sets, a WMTS server SHALL allow responses from the largest scale
denominator on the following tables and all intermediate scale denominators down to the mostdetailed scale resolution of that data; it is therefore not required to support the smallest scale
denominators in order to be conformant to a well-known scale set. Cell sizes (pixel size interrain units) have been calculated assuming 0.28 mm pixel size and the WGS84 equatorial
earth diameter.
URN identifiers for each well-known scale set follow the OGC 07-092r3 best practices
document.
E.1

GlobalCRS84Scale (urn:ogc:def:wkss:OGC:1.0:GlobalCRS84Scale)This well-known scale set has been defined for global cartographic products. Roundedscales have been chosen for intuitive cartographic representation of vector data. Scaledenominator is only accurate near the equator.
Table E.1 — Definition of Well-known scale set GlobalCRS84ScaleCRS
urn:ogc:def:crs:OGC:1.3:CRS84

102

Scale Denominator

Pixel Size (degrees)

500 106

1.25764139776733

250 106

0.628820698883665

100 1060.251528279553466

50 10

6

0.125764139776733

25 10

6

6.28820698883665 10-2

10 1062.51528279553466 10-2

5 106

1.25764139776733 10-2

2.5 106

6.28820698883665 10-3

1 106

2.51528279553466 10-3500 103

1.25764139776733 10-3

250 1036.28820698883665 10-4

100 1032.51528279553466 10-4

50 103

1.25764139776733 10-4

25 1036.28820698883665 10-5

10 1032.51528279553466 10-5

5 103

1.25764139776733 10-5

2.5 1036.28820698883665 10-6

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

CRS

E.2

Scale Denominator

Pixel Size (degrees)

1 103

2.51528279553466 10-6500

1.25764139776733 10-6250

6.28820698883665 10-7100

2.51528279553466 10-7

GlobalCRS84Pixel (urn:ogc:def:wkss:OGC:1.0:GlobalCRS84Pixel)

This well-known scale set has been defined for global cartographic products. Roundedpixel sizes have been chosen for intuitive cartographic representation of raster data. Some
values have been chosen to coincide with original pixel size of commonly used global
products like STRM (1" and 3"), GTOPO (30") or ETOPO (2' and 5'). Scale denominatorand approximated pixel size in meters are only accurate near the equator.
Table E.2 — Definition of Well-known scale set GlobalCRS84PixelCRS
urn:ogc:def:crs:OGC:1.3:CRS84

Scale Denominator

Pixel Size (degrees)

Approx. Pixel
Size (m)795139219.9519541

2

240000397569609.9759771

1120000198784804.9879885

0.5 (30')

60000

132523203.3253257

0.333333333333333 (20')

40000

66261601.66266284

0.166666666666667 (10')

20000

33130800.83133142

-2

10000

-2

4000

-2

2000

-3

1000

-3

500

-3

166

-4

100

-4

33

-4

16

-5

10

-5

3

-6

1

-6

0.33

13252320.33253257
6626160.166266284
3313080.083133142
1656540.041566571
552180.0138555236
331308.0083133142
110436.0027711047
55218.00138555237
33130.80083133142
11043.60027711047
3313.080083133142
1104.360027711047

Copyright © 2010 Open Geospatial Consortium Inc.

8.333333333333333 10 (5')
3.333333333333333 10 (2')
1.666666666666667 10 (1')
8.333333333333333 10 (30")
4.166666666666667 10 (15")
1.388888888888889 10 (5")
8.333333333333333 10 (3")
2.777777777777778 10 (1")
1.388888888888889 10 (0.5")8.333333333333333 10 (0.3")
2.777777777777778 10 (0.1")
8.333333333333333 10 (0.03")
2.777777777777778 10 (0.01")

103

OGC 07-057r7

E.3

GoogleCRS84Quad (urn:ogc:def:wkss:OGC:1.0:GoogleCRS84Quad)

This well-known scale set has been defined to allow quadtree pyramids in CRS84. Level
0 allows representing the whole world in a single 256x256 pixels (where the first 64 andlast 64 lines of the tile are left blank). The next level represents the whole world in 2x2
tiles of 256x256 pixels and so on in powers of 2. Scale denominator is only accurate near
the equator.
Table E.3 — Definition of Well-known scale set GoogleCRS84QuadCRS
urn:ogc:def:crs:OGC:1.3:CRS84

104

Scale Denominator

Pixel Size (degrees)

559082264.0287178

1.40625000000000

279541132.0143589

0.703125000000000

139770566.0071794

0.351562500000000

69885283.00358972

0.175781250000000

34942641.50179486

8.78906250000000 10-2

17471320.75089743

4.39453125000000 10-28735660.375448715

2.19726562500000 10-2

4367830.187724357

1.09863281250000 10-2

2183915.093862179

5.49316406250000 10-3

1091957.546931089

2.74658203125000 10-3

545978.7734655447

1.37329101562500 10-3

272989.3867327723

6.86645507812500 10-4

136494.6933663862

3.43322753906250 10-4

68247.34668319309

1.71661376953125 10-4

34123.67334159654

8.58306884765625 10-5

17061.83667079827

4.29153442382812 10-5

8530.918335399136

2.14576721191406 10-54265.459167699568

1.07288360595703 10-5

2132.729583849784

5.36441802978516 10-6

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

E.4

GoogleMapsCompatible (urn:ogc:def:wkss:OGC:1.0:GoogleMapsCompatible)

This well-known scale set has been defined to be compatible with Google Maps andMicrosoft Live Map projections and zoom levels. Level 0 allows representing the wholeworld in a single 256x256 pixels. The next level represents the whole world in 2x2 tilesof 256x256 pixels and so on in powers of 2. Scale denominator is only accurate near theequator.
Table E.4 — Definition of Well-known scale set GoogleMapsCompatible
CRS

Zoom
level
name

Scale Denominator

Pixel Size (m)urn:ogc:def:crs:EPSG:6.18:3:3857

0559082264.0287178

156543.0339280410

WGS 84 / Pseudo-Mercator1279541132.0143589

78271.51696402048

http://www.epsg-registry.org/export.htm?
gml=urn:ogc:def:crs:EPSG::3857

2139770566.0071794

39135.75848201023

369885283.00358972

19567.87924100512

434942641.50179486

9783.939620502561

517471320.75089743

4891.969810251280

68735660.375448715

2445.984905125640

74367830.187724357

1222.992452562820

82183915.093862179

611.4962262814100

91091957.546931089

305.7481131407048

10545978.7734655447

152.8740565703525

11

272989.3867327723

76.43702828517624

12136494.6933663862

38.21851414258813

1368247.34668319309

19.10925707129406

1434123.67334159654

9.554628535647032

1517061.83667079827

4.777314267823516

168530.918335399136

2.388657133911758

174265.459167699568

1.194328566955879

18

2132.729583849784

0.5971642834779395

Copyright © 2010 Open Geospatial Consortium Inc.

105

OGC 07-057r7

Annex F(normative)
WSDL description of the service
This Annex is normative for services that support SOAP messages. It provides an abstract
WSDL description for a generic WMTS service and guidance on how to create a concrete
WSDL description for a particular WMTS server instance.
A WSDL document is typically used in combination with SOAP encoding but this annex
describes WSDL documents that deal with KVP and SOAP encodings of the procedureoriented architectural style. WSDL documents (especially in version 1.1) seem not to beappropriate to describe resource oriented architectural style.
F.1

GeneralThe Web Services Description Language (WSDL) is an XML language for describing thecomputational characteristics of a web service: interface signatures, protocol bindings
and network endpoints. Version 1.1 was authored jointly by Microsoft and IBM andpublished as a W3C Note in March 2001. Furthermore, WSDL 1.1 is recommended by
WS-I Basic Profile 1.2 and the current drafts of WS-I Basic Profile 2.0, which will be
used in conjunction with WSDL 1.1. WSDL 2.0 (formerly 1.2 but renamed because of its
substantial differences from 1.1) has already been promoted to a W3C Recommendation
but is not widely supported yet by standards and tools.
F.2

WSDL Publication

There are many ways to publish a WSDL file for a Web Service instance. The
mainstream IT world has established three major ways:
1. The WSDL file can be offered on the web site of the organization that publishes
the web service. This approach allows humans to find the WSDL file but is not
sufficient for automatic use.
2. The WSDL file can be published through public and private registries. UDDI
would be the choice for general Web Services and CSW for OGC Web Services.
This approach follows the publish-find-bind pattern and thus allows humans andservices to discover the WSDL file in a standardized manner.
3. The web service itself can also publish the WSDL file. AXIS and the .NET
frameworks follow the convention of http://url:port/service/xx?WSDL. This issufficient for a pragmatic approach, but fails for multiple WSDL files describing
specific aspects of a Web Service as long as the base URL does not change.

106

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7

Option number two can be combined with option number three by just pointing to the
WSDL initially published via the WSDL pattern. Therefore, it is recommended to publish
a single WSDL file as described in option three but ideally to publish it through any kindof registry.
Also, within the service metadata document, a <WSDL> element may be used to specify
a reference to a WSDL resource. If the service has a SOAP binding, there SHALL be a
<WSDL> element. The value of the xlink:href attribute SHALL refer to a web accessible
WSDL document. The xlink:role attribute indicates the namespace of the document
element and WSDL version (in our examples http://schemas.xmlsoap.org/wsdl/1.0). The
xlink:show attribute has the value "none" to indicate that no specific behavior is intended.
This approach enables OGC Web Services with SOAP bindings to be discovered via the
GetCapabilities operation and to get additional information through the referenced
WSDL file.
F.3

Abstract and concrete WSDL documents

WSDL documents are intended to be modularized through the use of import statements
since they are structured in an abstract and concrete service instance part. Thesemechanisms permit the separation of service-specific elements from shared interface
definitions; such an authoring style is recommended in the WSDL specifications, and it isadvocated here. In practice, this separation means that the complete OGC service will
always be described by exactly one top-level WSDL. This top-level WSDL file may
import a set of WSDL files for specific parts, for instance a WSDL for the abstract partand a WSDL describing only the concrete service instance part of the service.
A concrete WSDL 1.1 document need to describe five main parts: types, messages,
portTypes, bindings and services. The abstract WSDL document describes types,
messages and portTypes in a generic way and can be imported in the concrete WSDL
description of any particular service instance. A concrete WSDL document also has todescribe the binding and service parts of the document.
F.4

Abstract WMTS WSDL document

Abstract WSDL document have a modular design that reuses application schemas that arealso used by SOAP messages and are mentioned in the Annex B and in some subclausesof this document.
In addition to this document, this standard includes and abstract WSDL document andsome XML Schema Documents imported by the abstract WSDL and also mentioned in
the Annex B. These XML Schema Documents and the abstract WSDL are bundled in a
zip file with the present document. After OGC acceptance of a Version 1.0.0 of thisstandard, these files will also be posted online at the URL
http://schemas.opengis.net/wmts/1.0.0. In the event of a discrepancy between the bundled
and online versions of the XML Schema Documents, the online files SHALL beconsidered authoritative.
Copyright © 2010 Open Geospatial Consortium Inc.

107

OGC 07-057r7

The documents relevant only in WSDL document creation are named:
wmtsAbstract.wsdl
wmts.xsd
wmtsKVP.xsd
Also complete examples can be found on the zip file and on the portal. Some fragmentsof these examples are shown throughout this document.
This is WSDL schema fragment for the abstract WMTS service illustrates the ability ofimporting some XDS files:<definitions name="WMTS"><types><xsd:schema
targetNamespace="http://www.opengis.net/wmts_wsdl/1.0"><xsd:import namespace="http://www.opengis.net/ows/1.1"
schemaLocation="../../ows/1.1.0/owsCommon.xsd"/><xsd:import namespace="http://www.opengis.net/wmts/1.0"
schemaLocation="wmts.xsd"/></xsd:schema></types><message name="GetTileMessage_GET"><part name="service" type="wmts:RequestServiceType"/><part name="request" type="wmts:GetTileValueType"/><part name="version" type="wmts:VersionType"/><part name="layer" type="xsd:string"/><part name="style" type="xsd:string"/><part name="format" type="ows:MimeType"/><part name="TileMatrixSet" type="xsd:string"/><part name="TileMatrix" type="xsd:string"/><part name="TileRow" type="xsd:unsignedInt"/><part name="TileCol" type="xsd:unsignedInt"/></message><message name="GetTileMessage_POST"><part name="request" element="wmts:GetTile"/></message><message name="GetTileResult_SOAP"><part name="body" element="wmts:BinaryPayload" /></message><portType name="WMTS_HTTP_Port_GET"><operation name="GetTile"><input message="tns:GetTileMessage_GET"/><output message="tns:GetTileResult"/><fault name="exception"
message="tns:ServiceExceptionMessage"/></operation></portType><portType name="WMTS_HTTP_Port_SOAP"><operation name="GetTile"><input message="tns:GetTileMessage_POST"/><output message="tns:GetTileResult_SOAP"/>108

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7<fault name="exception"
message="tns:ServiceExceptionMessage"/></operation></portType></definitions>

F.5

Concrete WMTS WSDL document

A concrete WSDL describes a particular server instance. First, it has to import theabstract WSDL file, then it has to use a <binding> element for each encoding the server
supports and, finally, a service element has to be used and it has to contain as portelements as encodings the server supports.
A HTTP GET <binding> element SHALL reference a GET portType from the abstract
part and make use of the <http:binding verb="GET"> binding as described in the
WSDL 1.1 specification. The operation element SHALL reference the corresponding
operation from the abstract part and use <http:urlEncoded/> as input and <mime />element as output. The <http:operation> element SHALL be used according to the
WSDL 1.1 and WS-I Basic.
A SOAP <binding> element SHALL reference a SOAP portType from the abstract partand make use of the <soap:binding style="document"> binding as described in the
WSDL 1.1 specification. The operation element SHALL reference the corresponding
operation from the abstract part and use <soap:body use="literal"/> as input andoutput. The <soap:operation> element SHALL be used according to the WSDL 1.1 and
WS-I Basic Profile 1.2 specifications. The soapAction attribute value SHALL follow theformat template:
http://www.opengis.net/{serviceType}/requests#{operationName}<port> elements in the <service> element SHALL reference bindings from the binding
part. In a GET encoding an <http:address location=""> element SHALL reference
the URL of the service (that has to be the same of the <ows:Get xlink:href="">element attribute in the service metadata document). In a SOAP encoding an<soap:address location=""> element SHALL reference the URL of the service (thathas to be the same value of the <ows:Get xlink:href=""> element attribute in theservice metadata document).
F.6

Concrete WMTS WSDL document example

The following example illustrates how a concrete WSDL document imports the abstract
WSDL document and adds a particular description of bindings and service for thisparticular server instance. The example only describes GetTile operation and describes
the same server example shown in subclause 7.1.3 of this document:<?xml version="1.0" encoding="UTF-8"?><definitions xmlns:wmts_wsdl="http://www.opengis.net/wmts_wsdl/1.0"
targetNamespace="http://www.opengis.net/wmts_wsdl/1.0">

Copyright © 2010 Open Geospatial Consortium Inc.

109

OGC 07-057r7<!-- import WMTS types, message and portType --><import namespace="http://www.opengis.net/wmts_wsdl/1.0"
location="../wmtsAbstract.wsdl"/><!--Bindings--><!-- HTTP Get KVP

bindings --><binding name="WMTS_HTTP_GET_Binding"
type="wmts_wsdl:WMTS_HTTP_Port_GET"><http:binding verb="GET"/><operation name="GetTile"><http:operation location=""/><input><http:urlEncoded/></input><output><mime:content type="image/*"/></output><fault name="exception"><mime:mimeXML/></fault></operation></binding><!-- HTTP Post SOAP

bindings --><binding name="WMTS_SOAP_Binding"
type="wmts_wsdl:WMTS_HTTP_Port_SOAP"><soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="GetTile"><soap:operation
soapAction="http://www.opengis.net/wms/requests#GetTile"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output><fault name="exception"><soap:fault name="exception" use="literal"/></fault></operation></binding><!-Services--><service name="WMTS-TiledWorld-UAB-CREAF-MiraMon"><port name="WMTS-GET-Port"binding="wmts_wsdl:WMTS_HTTP_GET_Binding">

110

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7<http:address location="http://www.maps.bob/maps.cgi"/></port><port name="WMTS-SOAP-Port"binding="wmts_wsdl:WMTS_SOAP_Binding"><soap:address location="http://www.maps.bob/maps.cgi"/></port></service></definitions>

Copyright © 2010 Open Geospatial Consortium Inc.

111

OGC 07-057r7

Annex H(informative)
Pseudocode
This informative Annex provides pseudocode that illustrates how to get the tiles thatcover a bounding box rectangle and how to get the CRS coordinates that bounds a tile.
H.1

From BBOX to tile indices

The following fragment of pseudocode could be used to convert from a desired boundingbox (bBoxMinX, bBoxMinY, bBoxMaxX, bBoxMaxY) in CRS coordinates to a range oftile set indices. This pseudocode uses the same notation that subclause 6.1 uses. In thispseudocode we assume that bBoxMinX, bBoxMinY, bBoxMaxX, bBoxMaxY,
tileMatrixMinX, tileMatrixMinY, tileMatrixMinY, tileMatrixMaxY, tileSpanX andtileSpanY are floating point variables (IEEE-754) that has accuracy issues derived fromthe finite precision of the representation. These accuracy issues could be amplified in a
typical floor() rounding down function that could return a value ±1 than that expected. To
overcome this issue this code uses a small value (epsilon) added or subtracted in a placethat is not affected by CRS coordinate precision.
// to compensate for floating point computation inaccuracies
epsilon = 1e-6
tileMinCol = floor((bBoxMinX - tileMatrixMinX) / tileSpanX +epsilon)tileMaxCol = floor((bBoxMaxX - tileMatrixMinX) / tileSpanX epsilon)
tileMinRow = floor((tileMatrixMaxY - bBoxMaxY) / tileSpanY +epsilon)tileMaxRow = floor((tileMatrixMaxY - bBoxMinY) / tileSpanY epsilon)// to avoid requesting out-of-range tiles
if (tileMinCol < 0) tileMinCol = 0
if (tileMaxCol >= matrixWidth) tileMaxCol = matrixWidth-1
if (tileMinRow < 0) tileMinRow = 0
if (tileMaxRow >= matrixHeight) tileMaxRow = matrixHeight-1

To fetch all the tiles that cover this bounding box, a client would scan through tileMinCol
to tileMaxCol and tileMinRow to tileMaxRow, all inclusive. A total of (tileMaxColtileMinCol+1) × (tileMaxRow- tileMinRow+1) will be fetched.
H.2

From tile indices to BBOX

The following pseudocode could be used to convert from a pair of tile indices (tileCol,
tileRow) to the bounding box (in CRS coordinates) of this tile defined by the upper-leftcorner (leftX, upperY) of the tile:112

Copyright © 2010 Open Geospatial Consortium Inc.

OGC 07-057r7
leftX = tileCol * tileSpanX + tileMatrixMinX
upperY = tileMatrixMaxY - tileRow * tileSpanYand the lower-right corner (rightX, lowerY) of the tile:rightX = (tileCol+1) * tileSpanX + tileMatrixMinX
lowerY = tileMatrixMaxY – (tileRow+1) * tileSpanY

Copyright © 2010 Open Geospatial Consortium Inc.

113

OGC 07-057r7

Bibliography[1]

OGC 05-007r7, OpenGIS® Web Processing Service Implementation Specification
version 1.0.0, at http://portal.opengeospatial.org/files/?artifact_id=24151[2]

OGC 06-042, OpenGIS® Web Map Server Implementation Specification version
1.3.0, at http://portal.opengeospatial.org/files/?artifact_id=14416[3]

OGC 06-121r3, OpenGIS® Web Service Common Implementation Specification
version 1.1.0 with Corrigendum 1, at
http://portal.opengeospatial.org/files/?artifact_id=20040[4]

OGC 07-057r2, OpenGIS® Tiled WMS Discussion Paper version 0.3.0, at
http://portal.opengeospatial.org/files/?artifact_id=23206[5]

OGC 07-092r3, Definition identifier URNs in OGC namespace Best Practices
version 1.3, at http://portal.opengeospatial.org/files/index.php?artifact_id=30575[6]

OGC 07-146r2 OGC® KML at
https://portal.opengeospatial.org/files/?artifact_id=27810[7]

OGC 07-156r1 Integration of Resource-Oriented Architecture Concepts into the
OGC Reference Model at
http://portal.opengeospatial.org/files/?artifact_id=29634&version=1[8]

OGC 08-142 OWS-Common WSDL Annex[9]

OGC 09-006 OWS-6-DSS Engineering Report – SOAPXML and REST in
WMTS at http://portal.opengeospatial.org/files/?artifact_id=31987[10]

OGC 09-144r1, Technical Committee Policies and Procedures: MIME Media
Types for GML, Version 1.0, at
http://portal.opengeospatial.org/files/?artifact_id=37743[11]

OnEarth WMS tiled extension at http://onearth.jpl.nasa.gov/tiled.html[12]

OpenSearch Specification 1.1 draft 4
http://www.opensearch.org/Specifications/OpenSearch/1.1[13]

OSGeo Tile Map Service Specification version 1.0 at
http://wiki.osgeo.org/wiki/Tile_Map_Service_Specification[14]

OSGeo WMS Tile Caching at http://wiki.osgeo.org/wiki/WMS_Tile_Caching[15]

RESTful Web Services. Web Services for the real World. Leonard Richardson
and Sam Ruby. O'Reilly Media Inc. 2007.

[16]

URI Template, draft-gregorio-uritemplate-03. Network Working Group InternetDraft. J. Gregorio, Ed. http://tools.ietf.org/html/draft-gregorio-uritemplate-03

114

Copyright © 2010 Open Geospatial Consortium Inc.