EN ISO 19128:2008

SLOVENSKI STANDARD
01-oktober-2008
Geografske informacije - Vmesnik za spletni kartografski strežnik (ISO 19128:2005)
Geographic information - Web map server interface (ISO 19128:2005)
Geoinformation - Web Map server interface (ISO 19128:2005)
Information géographique - Interface de carte du serveur web (ISO 19128:2005)
Ta slovenski standard je istoveten z: EN ISO 19128:2008
ICS:
35.240.70 Uporabniške rešitve IT v IT applications in science
znanosti
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN ISO 19128
NORME EUROPÉENNE
EUROPÄISCHE NORM
January 2008
ICS 35.240.70
English Version
Geographic information - Web map server interface (ISO
19128:2005)
Information géographique - Interface de carte du serveur
web (ISO 19128:2005)
This European Standard was approved by CEN on 15 December 2007.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national
standards may be obtained on application to the CEN Management Centre or to any CEN member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CEN member into its own language and notified to the CEN Management Centre has the same status as the
official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,
Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2008 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 19128:2008: E
worldwide for CEN national Members.

Foreword
The text of ISO 19128:2005 has been prepared by Technical Committee ISO/TC 211
"Geographic information/Geomatics” of the International Organization for Standardization (ISO)
and has been taken over as EN ISO 19128:2008 by Technical Committee CEN/TC 287
"Geographic Information", the secretariat of which is held by NEN.

This European Standard shall be given the status of a national standard, either by publication of
an identical text or by endorsement, at the latest by July 2008, and conflicting national
standards shall be withdrawn at the latest by July 2008.
Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any
or all such patent rights.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of
the following countries are bound to implement this European Standard: Austria, Belgium,
Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece,
Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and the United
Kingdom.
Endorsement notice
The text of ISO 19128:2005 has been approved by CEN as EN ISO 19128:2008 without any
modifications.
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
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

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 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

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.
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 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

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 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

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 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

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 19128:2005(E)
Boolean values shall be represented in a manner consistent with the specification for Boolean in XML Schema
Datatypes ([8], section 3.2.2). The values “0” and “false” are equivalent. The values “1” and “true” are
equivalent. Absence of an optional value is equivalent to logical false. This International Standard shall
explicitly indicate where a Boolean value is mandatory.
6.6 Output formats
The response to a Web Map Service request is always a computer file that is transferred over the Internet
from the server to the client. The file may contain text, or the file may represent a map image. As stated in 6.4,
the type of the returned file shall be indicated by a MIME type string.
Text output formats are usually formatted as Extensible Markup Language (XML; MIME type text/xml). Text
formats are used to convey service metadata, descriptions of error conditions, or responses to queries for
information about features shown on a map.
Allowed map formats are either “picture” formats or “graphic element” formats. Picture formats constitute a
rectangular pixel array of fixed size. Picture formats include file types such as Graphics Interchange Format
(GIF; MIME type “image/gif”), Portable Network Graphics (PNG; MIME type “image/png”), Joint Photographics
Expert Group (JPEG; MIME type “image/jpeg”), all of which can be displayed by common Web browsers, and
file types such as Tagged Image File Format (TIFF: MIME type “image/tiff”) that may require additional
software (beyond a basic Web browser) for display. Graphic element formats constitute a scale-independent
description of the graphic elements to be displayed (including points, lines, curves, text and images), such that
the size of the display may be modified while preserving the relative arrangement of the graphic elements.
Graphic element formats include Scalable Vector Graphics (SVG; MIME type “image/svg+xml”) or Web
Computer Graphics Metafile (WebCGM; MIME type “image/cgm;Version=4;ProfileId=WebCGM”) formats.
NOTE 1 SVG is expressed using XML, and could therefore be considered to be a text output format, but for the
purposes of this International Standard SVG is considered to be a map format.
NOTE 2 WebCGM is a profile of ISO/IEC 8632.
A server may offer multiple map formats. The formats it offers are enumerated in elements in its
service metadata. Use of a specific format is not required by this International Standard. However, for maps
that portray vector features the server should offer at least one format that supports transparency in order that
maps may be overlaid without obscuring other maps below (see the discussion about transparency in 7.3.3.9).
Also, for ease of use, the server should offer at least one format that can be displayed by common Web
browsers without additional software. Based on these considerations, the server should offer at least the PNG
format.
6.7 Coordinate systems
6.7.1 Introduction
This International Standard uses two principal classes of Coordinate Systems: a Map CS applicable to the
map portrayal generated by the WMS, and a Layer CRS for a Bounding Box applied to the source data.
During a portrayal operation, a WMS converts or transforms geographic information from a Layer CRS into a
Map CS. In addition, a Layer may have an associated vertical, temporal or other coordinate system.
6.7.2 Map CS
A Map CS is a coordinate reference system for a map produced by a WMS. A WMS map is a rectangular grid
of pixels displayed on a computer screen (or a digital file that could be so displayed). The Map CS has a
horizontal axis denoted i, and a vertical axis denoted j. i and j shall have only nonnegative integer values. The
origin (i,j) = (0,0) is the pixel in the upper left corner of the map; i increases to the right and j increases
downward. The Map CS is defined using ISO 19111 terminology in B.2. The Map CS is identified by the label
“CRS:1”.
8 © ISO 2005 – All rights reserved

ISO 19128:2005(E)
The usual orientation of the Map CS shall be such that the i axis is parallel to the East-to-West axis of the
Layer CRS and increases Eastward, and the j axis is parallel to the North-to-South axis of the Layer CRS and
increases Southward. This orientation will not be possible in some cases, as (for example) in an orthographic
projection over the South Pole. The convention to be followed is that, wherever possible, East shall be to the
right edge and North shall be toward the upper edge of the Map CS.
The WIDTH and HEIGHT parameters used in the GetMap request (see 7.3.3.8) and by inclusion in the
GetFeatureInfo request (7.4.3.3) correspond to i and j as follows:
⎯ WIDTH denotes the size of the map image in pixels along the i axis (that is, WIDTH-1 is the maximum
value of i).
⎯ HEIGHT denotes the size of the map image in pixels along the j axis (that is, HEIGHT-1 is the maximum
value of j).
The I and J parameters used in the GetFeatureInfo request (see 7.4.3.7) denote integer values along the i and
j axes, respectively, of the Map CS.
6.7.3 Layer CRS
6.7.3.1 Introduction
A Layer CRS is a horizontal coordinate reference system for the geographic information that serves as the
source for a map. As discussed below, many Layer CRSs are possible. A Layer CRS appears in the following
entities relevant to the WMS:
⎯ the element in the service metadata (7.2.4.6.8);
⎯ the CRS parameter in the GetMap request (7.3.3.5);
⎯ the CRS parameter in the map request part of the GetFeatureInfo request (7.4.3.3).
A WMS must support at least one CRS, and maps from multiple servers may be overlaid only if all the
selected servers have at least one CRS in common. This International Standard does not mandate support for
any particular Layer CRS(s). Instead, it only defines how CRSs are identified and discusses several optional
Layer CRSs, in this clause and in Annex B. Map providers may support the CRSs that are most useful and
appropriate to their geographic locale or information community. To maximize interoperability among servers,
providers should also support geographic coordinates by geocentric coordinate systems such as “CRS:84”
(see 6.7.3.2), “EPSG:4326” (see 6.7.3.3) or other ITRF-based systems.
Every Layer CRS has an identifier that is a character string. Two types of Layer CRS identifiers are permitted:
“label” and “URL” identifiers:
⎯ Label: The identifier includes a namespace prefix, a colon, a numeric or string code, and in some
instances a comma followed by additional parameters. This International Standard defines three
namespaces: CRS, EPSG and AUTO2, as discussed below.
⎯ URL: The identifier is a fully-qualified URL that references a publicly-accessible file containing a definition
of the CRS that is compliant with ISO 19111.
The Layer CRS has two axes, denoted x and y. The x axis is the first axis in the CRS definition, the y axis is
the second axis. Depending on the particular CRS, the x axis may or may not be oriented West-to-East, and
the y axis may or may not be oriented South-to-North. The WMS portrayal operation shall account for axis
order, origin and direction in the Layer CRS when projecting geographic information from a Layer CRS to the
Map CS.
Coordinates shall be listed in the order defined by the CRS and shall be mapped appropriately to the Map CS
i and j axes, swapping axis order as needed during the projection operation. Many projected coordinate
ISO 19128:2005(E)
reference systems have an axis and coordinate order other than easting, northing. For example, the Uniform
Coordinate System used in Finland (EPSG:2393) orders northing before easting. EPSG geographic
coordinate reference systems follow ISO 6709 and always list latitude before longitude.
Most coordinate reference systems are orientated with one axis positive east (easting) and the other axis
positive north (northing). These map conveniently to the bounding box i and j axes, respectively. However,
some CRSs have coordinates incrementing in other directions. For example, the Hartebeesthoek94/Lo25
system used in South Africa (EPSG:2051) has axes with coordinates incrementing to the west and south.
Tests for valid bounding box areas shall recognise and account for the positive orientation of the CRS axes.
In a geographic CRS, latitude shall have values within the range [-90, 90] and longitude shall have values
within the range [-180, 180] degrees or equivalent if the CRS definition is in other units. See 7.3.5 regarding
the projection of Layer CRS that is a geographic CRS into the Map CS. When the CRS code specifies a
geographic 2D coordinate reference system with axes in units other than degrees or in a degree
representation other than decimal degrees the representation shall be converted to decimal degrees.
NOTE The use of geographic CRSs with axis order of longitude before latitude differs from historical convention.
Users in the international aviation and marine sectors may expect latitude to be before longitude, and a different
coordinate display may have safety implications, especially in an emergency response situation. Although this
International Standard does not specify human user interfaces, developers of user interfaces for WMSs are cautioned that
all references to latitude and longitude, for example user input of bounding box or readout of cursor coordinates, should
show latitude before longitude.
6.7.3.2 CRS namespace for CRS
The “CRS” namespace prefix refers to coordinate reference systems that are defined in Annex B of this
International Standard. These definitions are in the form specified by ISO 19111. Geographic CRSs in the
“CRS” namespace are defined in Annex B for the WGS 84, NAD27 and NAD83 datums.
A “CRS” CRS label comprises the “CRS” prefix, the colon, and a numeric or string code.
EXAMPLE “CRS:84” refers to WGS 84 geographic longitude and latitude expressed in decimal degrees, with
longitude ranging from −180 degrees to +180 degrees and latitude from −90 degrees to +90 degrees.
6.7.3.3 EPSG namespace for CRS
The “EPSG” namespace prefix refers to the European Petroleum Survey Group geodetic dataset (EPSG),
which defines numeric identifiers (the EPSG “CRS code,” corresponding to the field
“COORD_REF_SYS_CODE” in the EPSG dataset) for many common coordinate reference systems. Defining
geodetic, map projection and coordinate reference system data is related to each CRS identifier.
An “EPSG” CRS label comprises the “EPSG” prefix, the colon, and a numeric code.
EXAMPLE EPSG:4326 refers to WGS 84 geographic latitude, then longitude. That is, in this CRS the x axis
corresponds to latitude, and the y axis to longitude.
NOTE EPSG geographic coordinate reference systems with axes of “degree – vendor-defined representation” are
taken in this International Standard to be in decimal degrees.
6.7.3.4 AUTO2 namespace for CRS
The “AUTO2” namespace is used for “automatic” coordinate reference systems; that is, for a class of CRSs
that include a user-selected centre of projection. Several “AUTO2” CRSs ar
...