oSIST ISO 19128:2006
Geographic information - Web map server interface
Geographic information - Web map server interface
ISO 19128:2005 specifies the behaviour of a service that produces spatially referenced maps dynamically from geographic information. It specifies operations to retrieve a description of the maps offered by a server, to retrieve a map, and to query a server about features displayed on a map. ISO 19128:2005 is applicable to pictorial renderings of maps in a graphical format; it is not applicable to retrieval of actual feature data or coverage data values.
Information géographique - Interface de carte du serveur Web
L'ISO 19128:2005 sp�cifie le comportement d'un service qui produit des cartes � r�f�rence spatiale de mani�re dynamique � partir d'informations g�ographiques. Elle pr�cise les op�rations d'extraction d'une description des cartes propos�es par un serveur et d'interrogation d'un serveur sur les �l�ments qui s'affichent sur une carte. L'ISO 19128:2005 s'applique aux rendus image des cartes dans un format graphique. Elle ne concerne pas l'extraction d'�l�ments r�els ou de donn�es de couverture.
Geografske informacije - Vmesnik za spletni kartografski strežnik
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 19128
First edition
2005-12-01
Geographic information — Web map
server interface
Information géographique — Interface de carte du serveur web
Reference number
ISO 19128:2005(E)
©
ISO 2005
---------------------- Page: 1 ----------------------
ISO 19128:2005(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO 2005
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2005 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 19128:2005(E)
Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Conformance. 1
2.1 Conformance classes and requirements . 1
2.2 Basic WMS. 1
2.3 Queryable WMS. 1
3 Normative references . 1
4 Terms and definitions. 2
5 Abbreviated terms . 3
6 Basic service elements . 4
6.1 Introduction . 4
6.2 Version numbering and negotiation . 4
6.3 General HTTP request rules . 5
6.4 General HTTP response rules . 7
6.5 Numeric and Boolean values. 7
6.6 Output formats. 8
6.7 Coordinate systems. 8
6.8 Request parameter rules. 12
6.9 Common request parameters. 13
6.10 Service result . 14
6.11 Service exceptions . 14
7 Web Map Service operations. 14
7.1 Introduction . 14
7.2 GetCapabilities (mandatory). 14
7.3 GetMap (mandatory). 25
7.4 GetFeatureInfo (optional). 31
Annex A (normative) Conformance tests . 34
Annex B (normative) CRS Definitions. 37
Annex C (normative) Handling multi-dimensional data . 44
Annex D (normative) Web Map Service profile of ISO 8601. 50
Annex E (normative) XML Schemas. 52
Annex F (normative) UML model . 63
Annex G (informative) Web Mapping Examples. 68
Annex H (informative) XML examples . 71
Bibliography . 76
© ISO 2005 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 19128:2005(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 19128 was prepared by Technical Committee ISO/TC 211, Geographic information/Geomatics, from a
base document supplied by the Open Geospatial Consortium, Inc.
iv © ISO 2005 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 19128:2005(E)
Introduction
A Web Map Service (WMS) produces maps of spatially referenced data dynamically from geographic
information. This International Standard defines a “map” to be a portrayal of geographic information as a
digital image file suitable for display on a computer screen. A map is not the data itself. WMS-produced maps
are generally rendered in a pictorial format such as PNG, GIF or JPEG, or occasionally as vector-based
graphical elements in Scalable Vector Graphics (SVG) or Web Computer Graphics Metafile (WebCGM)
formats.
This International Standard defines three operations: one returns service-level metadata; another returns a
map whose geographic and dimensional parameters are well-defined; and an optional third operation returns
information about particular features shown on a map. Web Map Service operations can be invoked using a
standard web browser by submitting requests in the form of Uniform Resource Locators (URLs). The content
of such URLs depends on which operation is requested. In particular, when requesting a map the URL
indicates what information is to be shown on the map, what portion of the Earth is to be mapped, the desired
coordinate reference system, and the output image width and height. When two or more maps are produced
with the same geographic parameters and output size, the results can be accurately overlaid to produce a
composite map. The use of image formats that support transparent backgrounds (e.g. GIF or PNG) allows
underlying maps to be visible. Furthermore, individual maps can be requested from different servers. The Web
Map Service thus enables the creation of a network of distributed map servers from which clients can build
customized maps. Illustrative examples of map request URLs and their resulting maps are shown in Annex G.
This International Standard applies to a Web Map Service instance that publishes its ability to produce maps
rather than its ability to access specific data holdings. A basic WMS classifies its geographic information
holdings into “Layers” and offers a finite number of predefined “Styles” in which to display those layers. This
International Standard supports only named Layers and Styles, and does not include a mechanism for
user-defined symbolization of feature data.
NOTE The Open Geospatial Consortium (OGC) Styled Layer Descriptor (SLD) specification [6] defines a mechanism
for user-defined symbolization of feature data instead of named Layers and Styles. In brief, an SLD-enabled WMS
retrieves feature data from a Web Feature Service [7] and applies explicit styling information provided by the user in order
to render a map.
© ISO 2005 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 19128:2005(E)
Geographic information — Web map server interface
1 Scope
This International Standard specifies the behaviour of a service that produces spatially referenced maps
dynamically from geographic information. It specifies operations to retrieve a description of the maps offered
by a server to retrieve a map, and to query a server about features displayed on a map. This International
Standard is applicable to pictorial renderings of maps in a graphical format; it is not applicable to retrieval of
actual feature data or coverage data values.
2 Conformance
2.1 Conformance classes and requirements
This International Standard defines two conformance classes, one for a basic WMS, and the other for a
queryable WMS. Each has two subclasses, one for clients and the other for servers.
2.2 Basic WMS
A basic WMS shall support the basic service elements (see Clause 6), the GetCapabilities operation (see 7.2),
and the GetMap operation (see 7.3). To conform to this International Standard, a basic WMS shall satisfy the
requirements of A.1 of the Abstract Test Suite in Annex A.
2.3 Queryable WMS
A queryable WMS shall satisfy all the requirements for a basic WMS, and shall also support the
GetFeatureInfo operation (see 7.4). To conform to this International Standard, a queryable WMS shall satisfy
all requirements of the Abstract Test Suite in Annex A.
3 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 8601:2004, Data elements and interchange formats — Information interchange — Representation of
dates and times
ISO 19111, Geographic information — Spatial referencing by coordinates
ISO 19115:2003, Geographic information — Metadata
EPSG (February 2003), European Petroleum Survey Group Geodesy Parameters, Lott, R., Ravanas, B.,
Cain, J., Simonson, G, and Nicolai, R., eds., available at
IETF RFC 2045 (November 1996), Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies, Freed, N. and Borenstein, N., eds., available at
© ISO 2005 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO 19128:2005(E)
IETF RFC 2396 (August 1998), Uniform Resource Identifiers (URI): Generic Syntax, Berners-Lee, T.,
Fielding, N., and Masinter, L., eds., available at
IETF RFC 2616 (June 1999), Hypertext Transfer Protocol – HTTP/1.1, Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and Berners-Lee, T., eds., available at
UCUM, Unified Code for Units of Measure, Schadow, G. and McDonald, C.J. (eds.), version 1.5
XML 1.0, Extensible Markup Language (XML) 1.0, World Wide Web Consortium Recommendation, Bray, T.,
Paoli, J., Sperberg-McQueen, C.M., and Maler, E., eds., available at
XML Schema, XML Schema Part 1: Structures, World Wide Web Consortium Recommendation,
Thompson, H.S., Beech, D., Maloney, M., and Mendelsohn, N., eds., available at
4 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
4.1
client
software component that can invoke an operation from a server
4.2
coordinate reference system
coordinate system that is related to the real world by a datum
[ISO 19111]
4.3
coordinate system
set of mathematical rules for specifying how coordinates are to be assigned to points
[ISO 19111]
4.4
geographic information
information concerning phenomena implicitly or explicitly associated with a location relative to the Earth
[ISO 19101]
4.5
interface
named set of operations that characterize the behaviour of an entity
[ISO 19119]
4.6
layer
basic unit of geographic information that may be requested as a map from a server
4.7
map
portrayal of geographic information as a digital image file suitable for display on a computer screen
4.8
operation
specification of a transformation or query that an object may be called to execute
[ISO 19119]
2 © ISO 2005 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 19128:2005(E)
4.9
portrayal
presentation of information to humans
[ISO 19117]
4.10
request
invocation of an operation by a client
4.11
response
result of an operation returned from a server to a client
4.12
server
a particular instance of a service
4.13
service
distinct part of the functionality that is provided by an entity through interfaces
[ISO 14252]
4.14
service metadata
metadata describing the operations and geographic information available at a server
5 Abbreviated terms
CDATA XML Character Data
CRS Coordinate Reference System
CS Coordinate System
DCP Distributed Computing Platform
DTD Document Type Definition
EPSG European Petroleum Survey Group
GIF Graphics Interchange Format
GIS Geographic Information System
HTTP Hypertext Transfer Protocol
IANA Internet Assigned Numbers Authority
IERS International Earth Rotation Service
IETF Internet Engineering Task Force
ITRF International Terrestrial Reference Frame
ITRS IERS Terrestrial Reference System
© ISO 2005 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO 19128:2005(E)
JPEG Joint Photographic Experts Group
MIME Multipurpose Internet Mail Extensions
NAD North American Datum
OGC Open GIS Consortium
PNG Portable Network Graphics
RFC Request for Comments
SVG Scalable Vector Graphics
UCUM Unified Code for Units of Measure
URL Uniform Resource Locator
WebCGM Web Computer Graphics Metafile
WCS Web Coverage Service
WFS Web Feature Service
WGS World Geodetic System
WMS Web Map Service
XML Extensible Markup Language
6 Basic service elements
6.1 Introduction
This clause specifies aspects of Web Map Server behaviour that are independent of particular operations or
are common to several operations.
6.2 Version numbering and negotiation
6.2.1 Version number form and value
The Web Map Service (WMS) defines a protocol version number. The version number applies to the XML
schema and the request encodings defined in this International Standard. The version number contains three
non-negative integers, separated by decimal points, in the form “x.y.z”. The numbers “y” and “z” shall not
exceed 99.
Implementations of this International Standard shall use the value “1.3.0” as the protocol version number.
6.2.2 Version number changes
The protocol version number shall be changed with each revision of this International Standard. The number
shall increase monotonically and shall comprise no more than three integers separated by decimal points, with
the first integer being the most significant. There may be gaps in the numerical sequence. Some numbers
may denote draft versions. Servers and their clients need not support all defined versions, but shall obey the
negotiation rules below.
4 © ISO 2005 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 19128:2005(E)
6.2.3 Appearance in requests and in service metadata
The version number shall appear in at least two places: in the service metadata and in the parameter list of
client requests to a server. The version number used in a client’s request of a particular server shall be equal
to a version number which that server has declared it supports (except during negotiation, as described
below). A server may support several versions, whose values clients may discover according to the
negotiation rules.
6.2.4 Version number negotiation
A WMS client may negotiate with a server to determine a mutually agreeable protocol version. Negotiation is
performed using the GetCapabilities operation (described in 7.2) according to the following rules.
All service metadata shall include a protocol version number and shall comply with the XML DTD or Schema
defined for that version. In response to a GetCapabilities request (for which the VERSION parameter is
optional) that does not specify a version number, the server shall respond with the highest version it supports.
In response to a GetCapabilities request containing a version number that the server implements, the server
shall send that version. If the server does not support the requested version, the server shall respond with
output that conforms to a version it does support, as determined by the following rules:
⎯ If a version unknown to the server and higher than the lowest supported version is requested, the server
shall send the highest version it supports that is less than the requested version.
⎯ If a version lower than any of those known to the server is requested, then the server shall send the
lowest version it supports.
⎯ If the client does not support the version sent by the server, it may either cease communicating with the
server or send a new request with a different version number that the client does support.
The process may be repeated until a mutually understood version is reached, or until the client determines
that it will not or cannot communicate with that particular server.
EXAMPLE 1 Server understands versions 1, 2, 4, 5 and 8. Client understands versions 1, 3, 4, 6, and 7. Client
requests version 7. Server responds with version 5. Client requests version 4. Server responds with version 4, which the
client understands, and the negotiation ends successfully.
EXAMPLE 2 Server understands versions 4, 5 and 8. Client understands version 3. Client requests version 3. Server
responds with version 4. Client does not understand that version or any higher version, so negotiation fails and client
ceases communication with that server.
The VERSION parameter is mandatory in requests other than GetCapabilities.
6.3 General HTTP request rules
6.3.1 Introduction
This International Standard defines the implementation of the WMS on a distributed computing platform (DCP)
comprising Internet hosts that support the Hypertext Transfer Protocol (HTTP) (see IETF RFC 2616). Thus,
the Online Resource of each operation supported by a server is an HTTP Uniform Resource Locator (URL).
The URL may be different for each operation, or the same, at the discretion of the service provider. Each URL
shall conform to the description in IETF RFC 2616 (section 3.2.2 “HTTP URL”) but is otherwise
implementation-dependent; only the query portion comprising the service request itself is defined by this
International Standard.
HTTP supports two request methods: GET and POST. One or both of these methods may be offered by a
server, and the use of the Online Resource URL differs in each case. Support for the GET method is
mandatory; support for the POST method is optional.
© ISO 2005 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO 19128:2005(E)
6.3.2 Reserved characters in HTTP GET URLs
The URL specification (IETF RFC 2396) reserves particular characters as significant and requires that these
be escaped when they might conflict with their defined usage. This International Standard explicitly reserves
several of those characters for use in the query portion of WMS requests. When the characters “?”, “&”, “=”, “,”
and “+” appear in one of the roles defined in Table 1, they shall appear literally in the URL. When those
characters appear elsewhere (for example, in the value of a parameter), they shall be encoded as defined in
IETF RFC 2396.
The server shall be prepared to decode any character escaped in this manner, and to decode the “+”
character as a space.
Table 1 — Reserved characters in WMS query string
Character Reserved usage
? Separator indicating start of query string.
& Separator between parameters in query string.
= Separator between name and value of parameter.
, Separator between individual values in list-oriented parameters (such as BBOX, LAYERS and STYLES
in the GetMap request).
+ Shorthand representation for a space character.
6.3.3 HTTP GET
A WMS shall support the “GET” method of the HTTP protocol (IETF RFC 2616).
An Online Resource URL intended for HTTP GET requests is in fact only a URL prefix to which additional
parameters are appended in order to construct a valid Operation request. A URL prefix is defined in
accordance with IETF RFC 2396 as a string including, in order, the scheme (“http” or “https”), Internet Protocol
hostname or numeric address, optional port number, path, mandatory question mark “?”, and optional string
comprising one or more server-specific parameters ending in an ampersand “&”. The prefix defines the
network address to which request messages are to be sent for a particular operation on a particular server.
Each operation may have a different prefix. Each prefix is entirely at the discretion of the service provider.
This International Standard defines how to construct a query part that is appended to the URL prefix in order
to form a complete request message. Every WMS operation has several mandatory or optional request
parameters. Each parameter has a defined name. Each parameter may have one or more legal values, which
are either defined by this International Standard or are selected by the client based on service metadata. To
formulate the query part of the URL, a client shall append the mandatory request parameters, and any desired
optional parameters, as name/value pairs in the form “name=value&” (parameter name, equals sign,
parameter value, ampersand). The “&” is a separator between name/value pairs, and is therefore optional
after the last pair in the request string.
When the HTTP GET method is used, the client-constructed query part is appended to the URL prefix defined
by the server, and the resulting complete URL is invoked as defined by HTTP (IETF RFC 2616).
Table 2 summarizes the components of an operation request URL when HTTP GET is used.
6 © ISO 2005 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 19128:2005(E)
Table 2 — Structure of WMS request using HTTP GET
URL component Description
http://host[:port]/path[?{name[=value]&}] URL prefix of service operation. [ ] denotes 0 or 1 occurrence of an
optional part; {} denotes 0 or more occurrences.
name=value& One or more standard request parameter name/value pairs as defined
for each operation by this International Standard.
6.3.4 HTTP POST
A WMS may support the “POST” method of the HTTP protocol (IETF RFC 2616).
An Online Resource URL intended for HTTP POST requests is a complete URL (not merely a prefix as in the
HTTP GET case) that is valid according to IETF RFC 2396 to which clients transmit request parameters in the
body of the POST message. A WMS shall not require additional parameters to be appended to the URL in
order to construct a valid target for the operation request. When POST is used, the request message is
formulated as an XML document.
6.4 General HTTP response rules
Upon receiving a valid request, the server shall send a response corresponding exactly to the request as
detailed in Clause 7 of this International Standard, or send a service exception if unable to respond correctly.
Only in the case of Version Negotiation (see 6.2.4) may the server offer a differing result. Upon receiving an
invalid request, the server shall issue a service exception as described in 6.11.
A server may send an HTTP Redirect message (using HTTP response codes as defined in IETF RFC 2616)
to an absolute URL that is different from the valid request URL that was sent by the client. HTTP Redirect
causes the client to issue a new HTTP request for the new URL. Several redirects could in theory occur.
Practically speaking, the redirect sequence ends when the server responds with a WMS response. The final
response shall be a WMS response that corresponds exactly to the original request (or a service exception).
Response objects shall be accompanied by the appropriate Multipurpose Internet Mail Extensions (MIME)
type (IETF RFC 2045) for that object. A list of MIME types in common use on the internet is maintained by the
Internet Assigned Numbers Authority (IANA) [2]. Allowable types for operation responses and service
exceptions are discussed below. The basic structure of a MIME type is a string of the form “type/subtype”.
MIME allows additional parameters in a string of the form “type/subtype; param1=value1; param2=value2”. A
server may include parameterized MIME types in its list of supported output formats. In addition to any
parameterized variants, the server should offer the basic unparameterized version of the format.
Response objects should be accompanied by other HTTP entity headers as appropriate and to the extent
possible. In particular, the Expires and Last-Modified headers provide important information for caching;
Content-Length may be used by clients to know when data transmission is complete and to efficiently allocate
space for results, and Content-Encoding or Content-Transfer-Encoding may be necessary for proper
interpretation of the results.
6.5 Numeric and Boolean values
Integer numbers shall be represented in a manner consistent with the specification for integers in XML
Schema Datatypes ([8], section 3.3.13). This International Standard shall explicitly indicate where an integer
value is mandatory.
Real numbers shall be represented in a manner consistent with the specification for double-precision numbers
in XML Schema Datatypes ([8], section 3.2.5). This representation allows for integer, decimal and exponential
notations. A real value is allowed in all numeric fields defined by this International Standard unless the value is
explicitly restricted to integer.
Positive, negative and zero values are allowed unless explicitly restricted.
© ISO 2005 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO 19128:2005(E)
Boolean values shall be represented in a manner consistent with the specification for Boolean in XML Schema
Datatypes
...
NORME ISO
INTERNATIONALE 19128
Première édition
2005-12-01
Information géographique — Interface
de carte du serveur Web
Geographic information — Web map server interface
Numéro de référence
ISO 19128:2005(F)
©
ISO 2005
---------------------- Page: 1 ----------------------
ISO 19128:2005(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier
peut être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence
autorisant l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées
acceptent de fait la responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute
responsabilité en la matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info
du fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir
l'exploitation de ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation,
veuillez en informer le Secrétariat central à l'adresse donnée ci-dessous.
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2005
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous
quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Version française parue en 2008
Publié en Suisse
ii © ISO 2005 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO 19128:2005(F)
Sommaire Page
Avant-propos. iv
Introduction . v
1 Domaine d'application. 1
2 Conformité. 1
2.1 Classes et exigences de conformité. 1
2.2 WMS de base. 1
2.3 WMS interrogeable . 1
3 Références normatives . 1
4 Termes et définitions. 2
5 Abréviations . 3
6 Éléments de service de base. 4
6.1 Introduction . 4
6.2 Numérotation de version et négociation. 5
6.3 Règles générales de requête HTTP. 6
6.4 Règles générales de réponse HTTP. 8
6.5 Valeurs numériques et booléennes . 8
6.6 Formats de sortie. 8
6.7 Système de coordonnées . 9
6.8 Règles de paramètre de requête . 14
6.9 Paramètres de requête communs. 15
6.10 Résultat du service. 16
6.11 Exceptions de service . 16
7 Opérations Web Map Service . 16
7.1 Introduction . 16
7.2 GetCapabilities (obligatoire). 16
7.3 GetMap (obligatoire). 29
7.4 GetFeatureInfo (facultatif). 35
Annexe A (normative) Essais de conformité. 38
Annexe B (normative) Définitions CRS. 41
Annexe C (normative) Traitement des données multidimensionnelles . 48
Annexe D (normative) Profil WMS de l'ISO 8601. 54
Annexe E (normative) Schémas XML. 56
Annexe F (normative) Modèle UML . 67
Annexe G (informative) Exemples de mise en correspondance Web. 72
Annexe H (informative) Exemples XML. 75
Bibliographie . 80
© ISO 2005 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO 19128:2005(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée
aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du
comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par les comités techniques sont soumis aux comités membres pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des comités membres
votants.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable de ne
pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO 19128 a été élaborée par le comité technique ISO/TC 211, Information géographique/Géomatique, à
partir d’un document de base fourni par Open Geospatial Consortium, Inc.
iv © ISO 2005 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO 19128:2005(F)
Introduction
Web Map Service (WMS) produit des cartes de données spatiales référencées de manière dynamique à partir
d'informations géographiques. La présente Norme internationale définit une "carte" comme un portrait
d'informations géographiques sous la forme d'un fichier image numérique qu'il est possible d'afficher sur un
écran d'ordinateur. Une carte n'est pas la donnée elle-même. D'une manière générale, les cartes WMS sont
rendues dans un format image (PNG, GIF ou JPEG, par exemple) ou, éventuellement, sous la forme
d'éléments graphiques vectoriels aux formats SVG (Scalable Vector Graphics) ou WebCGM (Web Computer
Graphics Metafile).
La présente Norme internationale définit trois opérations: l'une renvoie des métadonnées au niveau du
service; la deuxième renvoie une carte dont les paramètres géographiques et dimensionnels sont bien définis;
et la troisième renvoie des informations relatives aux éléments particuliers qui s'affichent sur la carte. Web
Map Service peut être appelé à l'aide d'un navigateur Web standard. Il suffit de soumettre des requêtes sous
forme d'URL (Uniform Resource Locators). Le contenu de ces URL dépend de l'opération demandée. En
particulier, lorsqu'une carte est demandée, l'URL indique les informations à afficher sur la carte, la partie de la
Terre à cartographier, le système de références par coordonnées souhaité, ainsi que la largeur et la hauteur
de l'image de sortie. Lorsque deux cartes au moins sont produites avec les mêmes paramètres
géographiques et taille de sortie, les résultats peuvent être précisément superposés pour produire une carte
composite. L'utilisation des formats d'image prenant en charge des arrière-plans transparents (GIF ou PNG,
par exemple) permet d'afficher la superposition de cartes. De plus, des cartes individuelles peuvent être
demandées à partir de serveurs différents. Par conséquent, Web Map Service permet de créer un réseau de
serveurs de carte répartis à partir duquel les clients peuvent concevoir des cartes personnalisées. L'Annexe G
fournit des exemples d'URL de demande de carte et les cartes auxquelles elles permettent d'accéder.
La présente Norme internationale s'applique à une instance Web Map Service qui diffuse sa capacité à
produire des cartes plutôt qu'à accéder à des données retenues spécifiques. Un WMS de base classe ses
informations géographiques en "Couches" et offre un nombre fini de "Styles" prédéfinis dans lesquels afficher
ces couches. La présente Norme internationale ne prend en charge que les Couches et les Styles, et ne
contient pas de mécanisme de symbolisation définie par l'utilisateur des éléments.
NOTE La spécification Styled Layer Descriptor (SLD) de l'Open Geospatial Consortium (OGC) [6] définit un
mécanisme de symbolisation définie par l'utilisateur des éléments à la place des Couches et des Styles nommés. En
résumé, un WMS activé par SLD permet d'extraire des éléments d'un Web Feature Service [7] et applique les
informations de style explicites fournies par l'utilisateur afin de rendre une carte.
© ISO 2005 – Tous droits réservés v
---------------------- Page: 5 ----------------------
NORME INTERNATIONALE ISO 19128:2005(F)
Information géographique — Interface de carte du serveur Web
1 Domaine d'application
La présente Norme internationale spécifie le comportement d'un service qui produit des cartes à référence
spatiale de manière dynamique à partir d'informations géographiques. Elle précise les opérations d'extraction
d'une description des cartes proposées par un serveur et d'interrogation d'un serveur sur les éléments qui
s'affichent sur une carte. La présente Norme internationale s'applique aux rendus image des cartes dans un
format graphique. Elle ne concerne pas l'extraction d'éléments réels ou de données de couverture.
2 Conformité
2.1 Classes et exigences de conformité
La présente Norme internationale définit deux classes de conformité: l'une pour un WMS de base et l'autre
pour un WMS interrogeable. Chacune d'elles comporte deux sous-classes: l'une pour les clients et l'autre pour
les serveurs.
2.2 WMS de base
Un WMS de base doit prendre en charge les éléments de service de base (voir Article 6), l'opération
GetCapabilities (voir 7.2) et l'opération GetMap (voir 7.3). Pour être conforme à la présente Norme
internationale, un WMS de base doit obéir aux exigences de A.1 de la Suite d'essai sommaire (Annexe A).
2.3 WMS interrogeable
Un WMS interrogeable doit obéir à toutes les exigences relatives à un WMS de base et doit prendre en
charge l'opération GetFeatureInfo (voir 7.4). Pour être conforme à la présente Norme internationale, un WMS
interrogeable doit obéir à toutes les exigences de la Suite d'essai sommaire (Annexe A).
3 Références normatives
Les documents de référence suivants sont indispensables pour l'application du présent document. Pour les
références datées, seule l'édition citée s'applique. Pour les références non datées, la dernière édition du
document de référence (y compris les éventuels amendements) s'applique.
ISO 8601:2004, Éléments de données et formats d'échange — Échange d'informations — Représentation de
la date et de l'heure
ISO 19111:2007, Information géographique — Système de références spatiales par coordonnées
ISO 19115:2003, Information géographique — Métadonnées
EPSG (February 2003), European Petroleum Survey Group Geodesy Parameters, Lott, R., Ravanas, B.,
Cain, J., Simonson, G. and Nicolai, R. eds., available at
© ISO 2005 – Tous droits réservés 1
---------------------- Page: 6 ----------------------
ISO 19128:2005(F)
IETF RFC 2045 (November 1996), Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies, Freed, N. and Borenstein, N., eds., available at
IETF RFC 2396 (August 1998), Uniform Resource Identifiers (URI): Generic Syntax, Berners-Lee, T.,
Fielding, N. and Masinter, L., eds., available at
IETF RFC 2616 (June 1999), Hypertext Transfer Protocol — HTTP/1.1, Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and Berners-Lee, T., eds., available at
UCUM, Unified Code for Units of Measure, Schadow, G. and McDonald, C.J. (eds.), version 1.5
XML 1.0, Extensible Markup Language (XML) 1.0, World Wide Web Consortium Recommendation, Bray, T.,
Paoli, J., Sperberg-McQueen, C.M. and Maler, E., eds., available at
XML Schema, XML Schema Part 1: Structures, World Wide Web Consortium Recommendation,
Thompson, H.S., Beech, D., Maloney, M. and Mendelsohn, N., eds., available at
4 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
4.1
client
composant logiciel pouvant appeler une opération à partir d'un serveur
4.2
système de références par coordonnées
système de coordonnées associé au monde réel par une référence
[ISO 19111]
4.3
système de coordonnées
ensemble de règles mathématiques permettant de spécifier la manière dont des coordonnées doivent être
attribuées à un point
[ISO 19111]
4.4
informations géographiques
informations relatives à des phénomènes implicitement ou explicitement associés à un endroit par rapport
à la Terre
[ISO 19101]
4.5
interface
ensemble nommé d'opérations qui caractérisent le comportement d'une entité
[ISO 19119]
4.6
couche
unité de base des informations géographiques susceptible d'être demandée sous la forme d'une carte
à partir d'un serveur
2 © ISO 2005 – Tous droits réservés
---------------------- Page: 7 ----------------------
ISO 19128:2005(F)
4.7
carte
présentation d'informations géographiques sous la forme d'un fichier image numérique qu'il est possible
d'afficher sur l'écran d'un ordinateur
4.8
opération
spécification d'une transformation ou d'une requête selon laquelle l'exécution d'un objet peut être appelée
[ISO 19119]
4.9
présentation
présentation des informations aux êtres humains
[ISO 19117]
4.10
requête
appel d'une opération par un client
4.11
réponse
résultat d'une opération renvoyé d'un serveur à un client
4.12
serveur
instance particulière d'un service
4.13
service
partie distincte de la fonctionnalité fournie par une entité par l'intermédiaire d'interfaces
[ISO 14252]
4.14
métadonnées de service
métadonnées décrivant les opérations et informations géographiques disponibles sur un serveur
5 Abréviations
CDATA XML Character Data
CRS Coordinate Reference System (système de références par coordonnées)
CS Coordinate System (système de coordonnées)
DCP Distributed Computing Platform (plate-forme informatique distribuée)
DTD Document Type Definition
EPSG European Petroleum Survey Group
GIF Graphics Interchange Format
GIS Geographic Information System
© ISO 2005 – Tous droits réservés 3
---------------------- Page: 8 ----------------------
ISO 19128:2005(F)
HTTP Hypertext Transfer Protocol
IANA Internet Assigned Numbers Authority
IERS International Earth Rotation Service
IETF Internet Engineering Task Force
ITRF International Terrestrial Reference Frame
ITRS IERS Terrestrial Reference System
JPEG Joint Photographic Experts Group
MIME Multipurpose Internet Mail Extensions
NAD North American Datum
OGC Open GIS Consortium
PNG Portable Network Graphics
RFC Request for Comments
SVG Scalable Vector Graphics
UCUM Unified Code for Units of Measure
URL Uniform Resource Locator
WebCGM Web Computer Graphics Metafile
WCS Web Coverage Service
WFS Web Feature Service
WGS World Geodetic System
WMS Web Map Service
XML Extensible Markup Language
6 Éléments de service de base
6.1 Introduction
Le présent article précise les aspects du comportement WMS qui sont indépendants des opérations
particulières ou communs à plusieurs opérations.
4 © ISO 2005 – Tous droits réservés
---------------------- Page: 9 ----------------------
ISO 19128:2005(F)
6.2 Numérotation de version et négociation
6.2.1 Forme et valeur du numéro de version
Le service WMS (Web Map Service) définit un numéro de version de protocole. Ce numéro de version
s'applique au schéma XML et aux codages de requête définis dans la présente Norme internationale. Le
numéro de version comporte trois entiers positifs, séparés par des signes décimaux, sous la forme “x.y.z”. Les
numéros “y” et “z” ne doivent pas être supérieurs à 99.
Le numéro de version de protocole de la mise en œuvre de la présente Norme internationale doit être “1.3.0”.
6.2.2 Modifications du numéro de version
Le numéro de version de protocole doit être modifié à chaque révision de la présente Norme internationale.
Le numéro doit augmenter de manière monotone et ne pas comporter plus de trois entiers séparés par des
signes décimaux, le premier entier étant le plus significatif. La séquence numérique peut faire l'objet d'écarts.
Certains numéros peuvent désigner les versions du projet. Il n'est pas utile que les serveurs et leurs clients
prennent en charge toutes les versions définies. Néanmoins, ils doivent respecter les règles de négociation
ci-après.
6.2.3 Aspect des métadonnées des demandes et du service
Le numéro de version doit apparaître à au moins deux endroits: dans les métadonnées du service et dans la
liste des paramètres des requêtes client au serveur. Le numéro de version utilisé dans la requête client d'un
serveur particulier doit être égal à un numéro de version que ledit serveur déclare prendre en charge (sauf
pendant la négociation, comme décrit ci-dessous). Un serveur peut prendre en charge plusieurs versions,
dont les clients peuvent découvrir les valeurs conformément aux négociations.
6.2.4 Négociation du numéro de version
Un client WMS peut négocier avec un serveur pour déterminer une version de protocole mutuellement
acceptable. La négociation est réalisée à l'aide de l'opération GetCapabilities (décrite en 7.2) conformément
aux règles suivantes.
Toutes les métadonnées de service doivent contenir un numéro de version de protocole et être conformes au
DTD ou schéma XML défini pour ladite version. En réponse à une requête GetCapabilities (pour laquelle le
paramètre VERSION est facultatif) qui ne précise pas de numéro de version, le serveur doit répondre avec la
version la plus élevée qu'il prend en charge. En réponse à une requête GetCapabilities contenant un numéro
de version que le serveur implémente, le serveur doit envoyer la version correspondante. Si le serveur ne
prend pas en charge la version demandée, il doit répondre avec une sortie conforme à une version qu'il prend
en charge, comme l'indiquent les règles suivantes:
⎯ Si un numéro de version inconnu du serveur et ultérieur à la version la plus ancienne prise en charge est
demandé, le serveur doit envoyer la version la plus récente qu'il prend en charge et qui est antérieure à
la version demandée.
⎯ Si une version antérieure à celle connue du serveur est demandée, le serveur doit envoyer la version la
plus ancienne qu'il prend en charge.
⎯ Si le client ne prend pas en charge la version envoyée par le serveur, il peut interrompre la
communication avec le serveur ou envoyer une nouvelle requête avec un numéro de version différent
que le client prend en charge.
Le processus peut être répété tant qu'une version mutuellement comprise n'a pas été obtenue, ou tant que le
client n'a pas déterminé qu'il ne pourra pas ou ne peut pas communiquer avec ce serveur particulier.
© ISO 2005 – Tous droits réservés 5
---------------------- Page: 10 ----------------------
ISO 19128:2005(F)
EXEMPLE 1 Le serveur comprend les versions 1, 2, 4, 5 et 8 et le client les versions 1, 3, 4, 6 et 7. Le client demande
la version 7 et le serveur répond avec la version 5. Le client demande la version 4 et le serveur répond par la version 4,
que le client comprend, et la négociation aboutit.
EXEMPLE 2 Le serveur comprend les versions 4, 5 et 8 et le client la version 3. Le client demande la version 3 et le
serveur répond avec la version 4. Le client ne comprend pas cette version ou une version ultérieure. La négociation
n'aboutit donc pas et le client interrompt la communication avec ce serveur.
Le paramètre VERSION est obligatoire dans les demandes d'autres éléments que GetCapabilities.
6.3 Règles générales de requête HTTP
6.3.1 Introduction
La présente Norme internationale définit la mise en œuvre du service WMS sur une plate-forme informatique
distribuée (DCP) composée d'hôtes Internet prenant en charge le protocole HTTP (Hypertext Transfer
Protocol) (voir l’IETF RFC 2616). Par conséquent, les ressources en ligne de chaque opération prise en
charge par un serveur est une URL (Uniform Resource Locator) HTTP. L'URL peut être différente pour
chaque opération, ou identique, à la discrétion du fournisseur de services. Chaque URL doit être conforme à
la description de l'IETF RFC 2616 (section 3.2.2 “HTTP URL”), mais dépend de l'implémentation. Seule la
partie relative à la requête contenant la demande de service elle-même est définie par la présente Norme
internationale.
HTTP prend en charge deux méthodes de requête: GET et POST. L'une et/ou l'autre de ces deux méthodes
peut être proposée par un serveur, et l'utilisation de l'URL de ressources en ligne diffère dans chaque cas. La
prise en charge de la méthode GET est obligatoire, celle de la méthode POST étant facultative.
6.3.2 Caractères réservés dans les URL HTTP GET
La spécification URL (IETF RFC 2396) permet de réserver des caractères particuliers comme étant
significatifs et qui doivent être supprimés s'ils sont susceptibles d'aller à l'encontre de leur usage prévu. La
présente Norme internationale réserve plusieurs de ces caractères pour une utilisation dans la partie relative
à la requête des requêtes WMS. Si les caractères “?”, “&”, “=”, “,” et “+” apparaissent dans l'un des rôles
définis dans le Tableau 1, ils doivent apparaître littéralement dans l'URL. Si ces caractères apparaissent
ailleurs (dans la valeur du paramètre, par exemple), ils doivent être codés (voir l'IETF RFC 2396).
Le serveur doit être en mesure de décoder les caractères échappés de cette manière et de décoder le
caractère “+” comme un espace.
Tableau 1 — Caractères réservés dans une chaîne de requête WMS
Caractère Usage réservé
? Séparateur indiquant le début de la chaîne de requête.
Séparateur placé entre les paramètres de la chaîne de requête.
&
= Séparateur placé entre le nom et la valeur du paramètre.
, Séparateur placé entre des valeurs individuelles de paramètres orientés liste (BBOX, LAYERS et
STYLES de la requête GetMap, par exemple).
+ Représentation sténographique d'un caractère d'espace.
6 © ISO 2005 – Tous droits réservés
---------------------- Page: 11 ----------------------
ISO 19128:2005(F)
6.3.3 HTTP GET
Un service WMS doit prendre en charge la méthode “GET” du protocole HTTP (IETF RFC 2616).
Une ressource URL en ligne destinée aux requêtes HTTP GET n'est en réalité qu'un préfixe URL auquel sont
ajoutés des paramètres afin de construire une requête d'opération valide. Conformément à l'IETF RFC 2396,
un préfixe URL est défini comme une chaîne composée, dans l'ordre, du schéma (http ou https), du nom
d'hôte ou de l'adresse numérique du protocole Internet, du numéro de port facultatif, du chemin d'accès, du
point d'interrogation (?) obligatoire, et d'une chaîne facultative composée d'un ou de plusieurs paramètres
spécifiques au serveur se terminant par une esperluette (&). Le préfixe définit l'adresse réseau à laquelle
doivent être envoyés les messages de la requête pour une opération particulière sur un serveur particulier.
Chaque opération peut comporter un préfixe différent. Chaque préfixe est à l'entière discrétion du fournisseur
de services.
La présente Norme internationale définit la manière de construire une partie de requête ajoutée au préfixe de
l'URL afin de former un message de requête complet. Chaque opération WMS comporte plusieurs paramètres
de requête obligatoires ou facultatifs. Chaque paramètre comporte un nom défini. Chaque paramètre peut
avoir une ou plusieurs valeurs valides, identifiées par la présente Norme internationale ou sélectionnées par
le client en fonction des métadonnées de service. Pour formuler la partie de la requête de l'URL, un client doit
ajouter les paramètres de requête obligatoires et tous les paramètres facultatifs souhaités, comme les paires
nom/valeur sous la forme “name=value&” (nom du paramètre, signe égal, valeur du paramètre, esperluette).
Le signe “&” est un séparateur placé entre les paires nom/valeur. Il est donc facultatif après la dernière paire
de la chaîne de requête.
Si la méthode HTTP GET est utilisée, la partie de la requête construite par le client est ajoutée au préfixe de
l'URL par le serveur, et l'URL complète qui en résulte est appelée telle que définie par HTTP
(IETF RFC 2616).
Le Tableau 2 récapitule les composants d'une URL de requête d'opération lorsque HTTP GET est utilisé.
Tableau 2 — Structure d'une requête WMS utilisant HTTP GET
Composant URL Description
http://host[:port]/path[?{name[=value]&}] Préfixe de l'URL de l'opération du service. [ ] indique 0 ou 1
occurrence d'une partie facultative; {} indique 0 ou plusieurs
occurrences.
name=value& Une ou plusieurs paires nom/valeur du paramètre de requête
standard telle(s) que définie(s) pour chaque opération par la
présente Norme internationale.
6.3.4 HTTP POST
Un service WMS peut prendre en charge la méthode “POST” du protocole HTTP (IETF RFC 2616).
Une ressource URL en ligne destinée aux requêtes HTTP POST est une URL complète (pas simplement un
préfixe, comme pour HTTP GET) valide conformément à l'IETF RFC 2396 à laquelle les clients transmettent
les paramètres de requête dans le corps du message POST. Un système WMS ne doit pas exiger l'ajout de
paramètres supplémentaires à l'URL pour construire une cible valide pour la requête d'opération. Si POST est
utilisé, le message de requête est formulé sous la forme d'un document XML.
© ISO 2005 – Tous droits réservés 7
---------------------- Page: 12 ----------------------
ISO 19128:2005(F)
6.4 Règles générales de réponse HTTP
Lors de la réception d'une requête valide, le serveur doit envoyer une réponse correspondant exactement à la
requête (voir Article 7 de la présente Norme internationale) ou une exception de service s'il est en mesure de
répondre correctement. Le serveur peut offrir
...
SLOVENSKI oSIST ISO 19128:2006
PREDSTANDARD
oct 2006
Geografske informacije – Vmesnik za spletni kartografski strežnik
Geographic information -Web map server interface
ICS 35.240.70 Referenčna številka
oSIST ISO 19128:2006(en)
© Standard je založil in izdal Slovenski inštitut za standardizacijo. Razmnoževanje ali kopiranje celote ali delov tega dokumenta ni dovoljeno
---------------------- Page: 1 ----------------------
INTERNATIONAL ISO
STANDARD 19128
First edition
2005-12-01
Geographic information — Web map
server interface
Information géographique — Interface de carte du serveur web
Reference number
ISO 19128:2005(E)
©
ISO 2005
---------------------- Page: 2 ----------------------
ISO 19128:2005(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO 2005
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2005 – All rights reserved
---------------------- Page: 3 ----------------------
ISO 19128:2005(E)
Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Conformance. 1
2.1 Conformance classes and requirements . 1
2.2 Basic WMS. 1
2.3 Queryable WMS. 1
3 Normative references . 1
4 Terms and definitions. 2
5 Abbreviated terms . 3
6 Basic service elements . 4
6.1 Introduction . 4
6.2 Version numbering and negotiation . 4
6.3 General HTTP request rules . 5
6.4 General HTTP response rules . 7
6.5 Numeric and Boolean values. 7
6.6 Output formats. 8
6.7 Coordinate systems. 8
6.8 Request parameter rules. 12
6.9 Common request parameters. 13
6.10 Service result . 14
6.11 Service exceptions . 14
7 Web Map Service operations. 14
7.1 Introduction . 14
7.2 GetCapabilities (mandatory). 14
7.3 GetMap (mandatory). 25
7.4 GetFeatureInfo (optional). 31
Annex A (normative) Conformance tests . 34
Annex B (normative) CRS Definitions. 37
Annex C (normative) Handling multi-dimensional data . 44
Annex D (normative) Web Map Service profile of ISO 8601. 50
Annex E (normative) XML Schemas. 52
Annex F (normative) UML model . 63
Annex G (informative) Web Mapping Examples. 68
Annex H (informative) XML examples . 71
Bibliography . 76
© ISO 2005 – All rights reserved iii
---------------------- Page: 4 ----------------------
ISO 19128:2005(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 19128 was prepared by Technical Committee ISO/TC 211, Geographic information/Geomatics, from a
base document supplied by the Open Geospatial Consortium, Inc.
iv © ISO 2005 – All rights reserved
---------------------- Page: 5 ----------------------
ISO 19128:2005(E)
Introduction
A Web Map Service (WMS) produces maps of spatially referenced data dynamically from geographic
information. This International Standard defines a “map” to be a portrayal of geographic information as a
digital image file suitable for display on a computer screen. A map is not the data itself. WMS-produced maps
are generally rendered in a pictorial format such as PNG, GIF or JPEG, or occasionally as vector-based
graphical elements in Scalable Vector Graphics (SVG) or Web Computer Graphics Metafile (WebCGM)
formats.
This International Standard defines three operations: one returns service-level metadata; another returns a
map whose geographic and dimensional parameters are well-defined; and an optional third operation returns
information about particular features shown on a map. Web Map Service operations can be invoked using a
standard web browser by submitting requests in the form of Uniform Resource Locators (URLs). The content
of such URLs depends on which operation is requested. In particular, when requesting a map the URL
indicates what information is to be shown on the map, what portion of the Earth is to be mapped, the desired
coordinate reference system, and the output image width and height. When two or more maps are produced
with the same geographic parameters and output size, the results can be accurately overlaid to produce a
composite map. The use of image formats that support transparent backgrounds (e.g. GIF or PNG) allows
underlying maps to be visible. Furthermore, individual maps can be requested from different servers. The Web
Map Service thus enables the creation of a network of distributed map servers from which clients can build
customized maps. Illustrative examples of map request URLs and their resulting maps are shown in Annex G.
This International Standard applies to a Web Map Service instance that publishes its ability to produce maps
rather than its ability to access specific data holdings. A basic WMS classifies its geographic information
holdings into “Layers” and offers a finite number of predefined “Styles” in which to display those layers. This
International Standard supports only named Layers and Styles, and does not include a mechanism for
user-defined symbolization of feature data.
NOTE The Open Geospatial Consortium (OGC) Styled Layer Descriptor (SLD) specification [6] defines a mechanism
for user-defined symbolization of feature data instead of named Layers and Styles. In brief, an SLD-enabled WMS
retrieves feature data from a Web Feature Service [7] and applies explicit styling information provided by the user in order
to render a map.
© ISO 2005 – All rights reserved v
---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO 19128:2005(E)
Geographic information — Web map server interface
1 Scope
This International Standard specifies the behaviour of a service that produces spatially referenced maps
dynamically from geographic information. It specifies operations to retrieve a description of the maps offered
by a server to retrieve a map, and to query a server about features displayed on a map. This International
Standard is applicable to pictorial renderings of maps in a graphical format; it is not applicable to retrieval of
actual feature data or coverage data values.
2 Conformance
2.1 Conformance classes and requirements
This International Standard defines two conformance classes, one for a basic WMS, and the other for a
queryable WMS. Each has two subclasses, one for clients and the other for servers.
2.2 Basic WMS
A basic WMS shall support the basic service elements (see Clause 6), the GetCapabilities operation (see 7.2),
and the GetMap operation (see 7.3). To conform to this International Standard, a basic WMS shall satisfy the
requirements of A.1 of the Abstract Test Suite in Annex A.
2.3 Queryable WMS
A queryable WMS shall satisfy all the requirements for a basic WMS, and shall also support the
GetFeatureInfo operation (see 7.4). To conform to this International Standard, a queryable WMS shall satisfy
all requirements of the Abstract Test Suite in Annex A.
3 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 8601:2004, Data elements and interchange formats — Information interchange — Representation of
dates and times
ISO 19111, Geographic information — Spatial referencing by coordinates
ISO 19115:2003, Geographic information — Metadata
EPSG (February 2003), European Petroleum Survey Group Geodesy Parameters, Lott, R., Ravanas, B.,
Cain, J., Simonson, G, and Nicolai, R., eds., available at
IETF RFC 2045 (November 1996), Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies, Freed, N. and Borenstein, N., eds., available at
© ISO 2005 – All rights reserved 1
---------------------- Page: 7 ----------------------
ISO 19128:2005(E)
IETF RFC 2396 (August 1998), Uniform Resource Identifiers (URI): Generic Syntax, Berners-Lee, T.,
Fielding, N., and Masinter, L., eds., available at
IETF RFC 2616 (June 1999), Hypertext Transfer Protocol – HTTP/1.1, Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and Berners-Lee, T., eds., available at
UCUM, Unified Code for Units of Measure, Schadow, G. and McDonald, C.J. (eds.), version 1.5
XML 1.0, Extensible Markup Language (XML) 1.0, World Wide Web Consortium Recommendation, Bray, T.,
Paoli, J., Sperberg-McQueen, C.M., and Maler, E., eds., available at
XML Schema, XML Schema Part 1: Structures, World Wide Web Consortium Recommendation,
Thompson, H.S., Beech, D., Maloney, M., and Mendelsohn, N., eds., available at
4 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
4.1
client
software component that can invoke an operation from a server
4.2
coordinate reference system
coordinate system that is related to the real world by a datum
[ISO 19111]
4.3
coordinate system
set of mathematical rules for specifying how coordinates are to be assigned to points
[ISO 19111]
4.4
geographic information
information concerning phenomena implicitly or explicitly associated with a location relative to the Earth
[ISO 19101]
4.5
interface
named set of operations that characterize the behaviour of an entity
[ISO 19119]
4.6
layer
basic unit of geographic information that may be requested as a map from a server
4.7
map
portrayal of geographic information as a digital image file suitable for display on a computer screen
4.8
operation
specification of a transformation or query that an object may be called to execute
[ISO 19119]
2 © ISO 2005 – All rights reserved
---------------------- Page: 8 ----------------------
ISO 19128:2005(E)
4.9
portrayal
presentation of information to humans
[ISO 19117]
4.10
request
invocation of an operation by a client
4.11
response
result of an operation returned from a server to a client
4.12
server
a particular instance of a service
4.13
service
distinct part of the functionality that is provided by an entity through interfaces
[ISO 14252]
4.14
service metadata
metadata describing the operations and geographic information available at a server
5 Abbreviated terms
CDATA XML Character Data
CRS Coordinate Reference System
CS Coordinate System
DCP Distributed Computing Platform
DTD Document Type Definition
EPSG European Petroleum Survey Group
GIF Graphics Interchange Format
GIS Geographic Information System
HTTP Hypertext Transfer Protocol
IANA Internet Assigned Numbers Authority
IERS International Earth Rotation Service
IETF Internet Engineering Task Force
ITRF International Terrestrial Reference Frame
ITRS IERS Terrestrial Reference System
© ISO 2005 – All rights reserved 3
---------------------- Page: 9 ----------------------
ISO 19128:2005(E)
JPEG Joint Photographic Experts Group
MIME Multipurpose Internet Mail Extensions
NAD North American Datum
OGC Open GIS Consortium
PNG Portable Network Graphics
RFC Request for Comments
SVG Scalable Vector Graphics
UCUM Unified Code for Units of Measure
URL Uniform Resource Locator
WebCGM Web Computer Graphics Metafile
WCS Web Coverage Service
WFS Web Feature Service
WGS World Geodetic System
WMS Web Map Service
XML Extensible Markup Language
6 Basic service elements
6.1 Introduction
This clause specifies aspects of Web Map Server behaviour that are independent of particular operations or
are common to several operations.
6.2 Version numbering and negotiation
6.2.1 Version number form and value
The Web Map Service (WMS) defines a protocol version number. The version number applies to the XML
schema and the request encodings defined in this International Standard. The version number contains three
non-negative integers, separated by decimal points, in the form “x.y.z”. The numbers “y” and “z” shall not
exceed 99.
Implementations of this International Standard shall use the value “1.3.0” as the protocol version number.
6.2.2 Version number changes
The protocol version number shall be changed with each revision of this International Standard. The number
shall increase monotonically and shall comprise no more than three integers separated by decimal points, with
the first integer being the most significant. There may be gaps in the numerical sequence. Some numbers
may denote draft versions. Servers and their clients need not support all defined versions, but shall obey the
negotiation rules below.
4 © ISO 2005 – All rights reserved
---------------------- Page: 10 ----------------------
ISO 19128:2005(E)
6.2.3 Appearance in requests and in service metadata
The version number shall appear in at least two places: in the service metadata and in the parameter list of
client requests to a server. The version number used in a client’s request of a particular server shall be equal
to a version number which that server has declared it supports (except during negotiation, as described
below). A server may support several versions, whose values clients may discover according to the
negotiation rules.
6.2.4 Version number negotiation
A WMS client may negotiate with a server to determine a mutually agreeable protocol version. Negotiation is
performed using the GetCapabilities operation (described in 7.2) according to the following rules.
All service metadata shall include a protocol version number and shall comply with the XML DTD or Schema
defined for that version. In response to a GetCapabilities request (for which the VERSION parameter is
optional) that does not specify a version number, the server shall respond with the highest version it supports.
In response to a GetCapabilities request containing a version number that the server implements, the server
shall send that version. If the server does not support the requested version, the server shall respond with
output that conforms to a version it does support, as determined by the following rules:
⎯ If a version unknown to the server and higher than the lowest supported version is requested, the server
shall send the highest version it supports that is less than the requested version.
⎯ If a version lower than any of those known to the server is requested, then the server shall send the
lowest version it supports.
⎯ If the client does not support the version sent by the server, it may either cease communicating with the
server or send a new request with a different version number that the client does support.
The process may be repeated until a mutually understood version is reached, or until the client determines
that it will not or cannot communicate with that particular server.
EXAMPLE 1 Server understands versions 1, 2, 4, 5 and 8. Client understands versions 1, 3, 4, 6, and 7. Client
requests version 7. Server responds with version 5. Client requests version 4. Server responds with version 4, which the
client understands, and the negotiation ends successfully.
EXAMPLE 2 Server understands versions 4, 5 and 8. Client understands version 3. Client requests version 3. Server
responds with version 4. Client does not understand that version or any higher version, so negotiation fails and client
ceases communication with that server.
The VERSION parameter is mandatory in requests other than GetCapabilities.
6.3 General HTTP request rules
6.3.1 Introduction
This International Standard defines the implementation of the WMS on a distributed computing platform (DCP)
comprising Internet hosts that support the Hypertext Transfer Protocol (HTTP) (see IETF RFC 2616). Thus,
the Online Resource of each operation supported by a server is an HTTP Uniform Resource Locator (URL).
The URL may be different for each operation, or the same, at the discretion of the service provider. Each URL
shall conform to the description in IETF RFC 2616 (section 3.2.2 “HTTP URL”) but is otherwise
implementation-dependent; only the query portion comprising the service request itself is defined by this
International Standard.
HTTP supports two request methods: GET and POST. One or both of these methods may be offered by a
server, and the use of the Online Resource URL differs in each case. Support for the GET method is
mandatory; support for the POST method is optional.
© ISO 2005 – All rights reserved 5
---------------------- Page: 11 ----------------------
ISO 19128:2005(E)
6.3.2 Reserved characters in HTTP GET URLs
The URL specification (IETF RFC 2396) reserves particular characters as significant and requires that these
be escaped when they might conflict with their defined usage. This International Standard explicitly reserves
several of those characters for use in the query portion of WMS requests. When the characters “?”, “&”, “=”, “,”
and “+” appear in one of the roles defined in Table 1, they shall appear literally in the URL. When those
characters appear elsewhere (for example, in the value of a parameter), they shall be encoded as defined in
IETF RFC 2396.
The server shall be prepared to decode any character escaped in this manner, and to decode the “+”
character as a space.
Table 1 — Reserved characters in WMS query string
Character Reserved usage
? Separator indicating start of query string.
& Separator between parameters in query string.
= Separator between name and value of parameter.
, Separator between individual values in list-oriented parameters (such as BBOX, LAYERS and STYLES
in the GetMap request).
+ Shorthand representation for a space character.
6.3.3 HTTP GET
A WMS shall support the “GET” method of the HTTP protocol (IETF RFC 2616).
An Online Resource URL intended for HTTP GET requests is in fact only a URL prefix to which additional
parameters are appended in order to construct a valid Operation request. A URL prefix is defined in
accordance with IETF RFC 2396 as a string including, in order, the scheme (“http” or “https”), Internet Protocol
hostname or numeric address, optional port number, path, mandatory question mark “?”, and optional string
comprising one or more server-specific parameters ending in an ampersand “&”. The prefix defines the
network address to which request messages are to be sent for a particular operation on a particular server.
Each operation may have a different prefix. Each prefix is entirely at the discretion of the service provider.
This International Standard defines how to construct a query part that is appended to the URL prefix in order
to form a complete request message. Every WMS operation has several mandatory or optional request
parameters. Each parameter has a defined name. Each parameter may have one or more legal values, which
are either defined by this International Standard or are selected by the client based on service metadata. To
formulate the query part of the URL, a client shall append the mandatory request parameters, and any desired
optional parameters, as name/value pairs in the form “name=value&” (parameter name, equals sign,
parameter value, ampersand). The “&” is a separator between name/value pairs, and is therefore optional
after the last pair in the request string.
When the HTTP GET method is used, the client-constructed query part is appended to the URL prefix defined
by the server, and the resulting complete URL is invoked as defined by HTTP (IETF RFC 2616).
Table 2 summarizes the components of an operation request URL when HTTP GET is used.
6 © ISO 2005 – All rights reserved
---------------------- Page: 12 ----------------------
ISO 19128:2005(E)
Table 2 — Structure of WMS request using HTTP GET
URL component Description
http://host[:port]/path[?{name[=value]&}] URL prefix of service operation. [ ] denotes 0 or 1 occurrence of an
optional part; {} denotes 0 or more occurrences.
name=value& One or more standard request parameter name/value pairs as defined
for each operation by this International Standard.
6.3.4 HTTP POST
A WMS may support the “POST” method of the HTTP protocol (IETF RFC 2616).
An Online Resource URL intended for HTTP POST requests is a complete URL (not merely a prefix as in the
HTTP GET case) that is valid according to IETF RFC 2396 to which clients transmit request parameters in the
body of the POST message. A WMS shall not require additional parameters to be appended to the URL in
order to construct a valid target for the operation request. When POST is used, the request message is
formulated as an XML document.
6.4 General HTTP response rules
Upon receiving a valid request, the server shall send a response corresponding exactly to the request as
detailed in Clause 7 of this International Standard, or send a service exception if unable to respond correctly.
Only in the case of Version Negotiation (see 6.2.4) may the server offer a differing result. Upon receiving an
invalid request, the server shall issue a service exception as described in 6.11.
A server may send an HTTP Redirect message (using HTTP response codes as defined in IETF RFC 2616)
to an absolute URL that is different from the valid request URL that was sent by the client. HTTP Redirect
causes the client to issue a new HTTP request for the new URL. Several redirects could in theory occur.
Practically speaking, the redirect sequence ends when the server responds with a WMS response. The final
response shall be a WMS response that corresponds exactly to the original request (or a service exception).
Response objects shall be accompanied by the appropriate Multipurpose Internet Mail Extensions (MIME)
type (IETF RFC 2045) for that object. A list of MIME types in common use on the internet is maintained by the
Internet Assigned Numbers Authority (IANA) [2]. Allowable types for operation responses and service
exceptions are discussed below. The basic structure of a MIME type is a string of the form “type/subtype”.
MIME allows additional parameters in a string of the form “type/subtype; param1=value1; param2=value2”. A
server may include parameterized MIME types in its list of supported output formats. In addition to any
parameterized variants, the server should offer the basic unparameterized version of the format.
Response objects should be accompanied by other HTTP entity headers as appropriate and to the extent
possible. In particular, the Expires and Last-Modified headers provide important information for caching;
Content-Length may be used by clients to know when data transmission is complete and to efficiently allocate
space for results, and Content-Encoding or Content-Transfer-Encoding may be necessary for proper
interpretation of the results.
6.5 Numeric and Boolean values
Integer numbers shall be represented in a manner consistent with the specification for integers in XML
Schema Datatypes ([8], section 3.3.13). This International Standard shall explicitly indicate where an integer
value is mandatory.
Real numbers shall be represented in a manner consistent with the specification for double-precision numbers
in XML Schema Datatypes ([8], section 3.2.5). This representation allows for integer, decimal and exponential
nota
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.