License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.


 

i. Abstract

This Standard provides an updated version of WKT representation of coordinate reference systems that follows the provisions of ISO 19111:2007 and ISO 19111-2:2009. It extends the earlier WKT to allow for the description of coordinate operations. This International Standard defines the structure and content of well-known text strings. It does not prescribe how implementations should read or write these strings.

The jointly developed draft has also been submitted by ISO TC211 for publication as an International Standard document. The version incorporates comments made during both the OGC Public Comment Period as well as the ISO ballot for DIS (ISO TC211 document N3750).

ii. Keywords

ogcdoc, ocg documents, iso, 19162, crs, wkt

iii. Submitting organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

International Association of Oil and Gas Producers (IOGP)

iv. Submitters

All questions regarding this submission should be directed to the editor or the submitters:

Name Representing OGC member
Roger Lott IOGP Yes

v. Changes to the OGC® Abstract Specification

The OGC® Abstract Specification does not require changes to accommodate this OGC® standard.

This document is jointly branded between OGC and ISO TC 211. Below is the title page information from the version published by ISO TC 211.

ISO TC 211    

Date:   2015-03-13

ISO 19162:2015(E)

ISO TC 211/SC /WG 9

Secretariat:   SN

Geographic information — Well known text representation of coordinate reference systems

Information géographique — Représentation textuelle bien lisible de systèmes de référence par coordonnées


Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The OGC shall not be held responsible for identifying any or all such patent rights. Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

This standard was jointly developed by the Open Geospatial Consortium (OGC) and ISO TC 211: Geographic information / Geomatics. ISO 19162 is the ISO document designation.

 

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.

 

Introduction

Well-known Text (WKT) offers a compact machine- and human-readable representation of geometric objects. WKT may also be used for succinctly describing the critical elements of coordinate reference system (CRS) definitions. 

WKT was described in the Open Geospatial Consortium implementation specifications 99-036 through 06-103r4 and International Standard ISO 19125-1:2004, “Geographic information – Simple feature access – Part 1: Common architecture”. The WKT representation of coordinate reference systems was subsequently extended in Open Geospatial Consortium implementation specification 01-009 “Coordinate Transformation Services” and this extension was later adopted in the Open Geospatial Consortium GeoAPI 3.0 implementation standard 09-083r3 and GeoPackage 1.0 implementation standard 12-128r10. The WKT representation of coordinate reference systems as defined in ISO 19125-1:2004 and OGC specification 01-009 is inconsistent with the terminology and technical provisions of ISO 19111:2007 and OGC Abstract Specification topic 2 (08-015r2), “Geographic information – Spatial referencing by coordinates”.

This International Standard provides an updated version of WKT representation of coordinate reference systems that follows the provisions of ISO 19111:2007 and ISO 19111-2:2009. It extends earlier WKT to allow for the description of coordinate operations. This International Standard defines the structure and content of well-known text strings. It does not prescribe how implementations should read or write these strings.


1. Scope

This International Standard defines the structure and content of a text string implementation of the abstract model for coordinate reference systems described in ISO 19111:2007 and ISO 19111-2:2009. The string defines frequently needed types of coordinate reference systems and coordinate operations in a self-contained form that is easily readable by machines and by humans. The essence is its simplicity; as a consequence there are some constraints upon the more open content allowed in ISO 19111:2007. To retain simplicity in the well-known text (WKT) description of coordinate reference systems and coordinate operations, the scope of this International Standard excludes parameter grouping and pass-through coordinate operations. The text string provides a means for humans and machines to correctly and unambiguously interpret and utilise a coordinate reference system definition with look-ups or cross references only to define coordinate operation mathematics. Because it omits metadata about the source of the data and may omit metadata about the applicability of the information, the WKT string is not suitable for the storage of definitions of coordinate reference systems or coordinate operations.

2. Conformance requirements

This International Standard defines eleven classes of conformance (see Annex A) in three groups:

  1.   Any WKT string claiming conformance of coordinate reference system definition shall satisfy the requirements in Annex A as shown in Table 1.
    Table : Conformance requirements for coordinate reference systems
    Coordinate reference system type Conformance requirements given in
    geodetic A.1
    projected A.2
    vertical A.3
    engineering A.4
    image A.5
    parametric A.6
    temporal A.7
    derived geodetic, derived vertical, derived engineering, derived parametric, derived temporal A.8
    compound A.9

     
  2.   Any WKT string claiming conformance of coordinate operation definition shall satisfy the requirements given in A.10.
  3.   Any WKT string claiming conformance of coordinate transformation bound to a coordinate reference system definition shall satisfy the requirements given in A.11.

Conformance is applicable to the WKT string. Recommended practices for implementations writing or reading coordinate reference system WKT strings are given in Annex B.

3. Normative References

The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. 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/IEC 9075-1:2011,
Information technology ―Database languages ―SQL ― Part 1: Framework (SQL/Framework)
ISO/IEC 9075-2:2011,
Information technology ―Database languages ―SQL ― Part 2: Foundation (SQL/Foundation)
ISO/IEC 10646:2012,
Information technology ―Universal Coded Character Set (UCS)
ISO 19111:2007,
Geographic information ― Spatial referencing by coordinates
ISO 19111-2:2009,
Geographic information ― Spatial referencing by coordinates ―Part 2: Extension for parametric values

4. Definitions and abbreviations

4.1 Definitions

For the purposes of this document, the following terms and definitions apply.

4.1.1 affine coordinate system

coordinate system (4.1.8) in Euclidean space with straight axes that are not necessarily mutually perpendicular

[SOURCE: ISO 19111:2007, 4.1]

4.1.2 bearing

horizontal angle at a point relative to a specified direction

Note 1 to entry:    The direction is usually specified to be north. In some communities the term bearing refers specifically to grid north and directions relative to true north are then termed ‘azimuth’; in other communities a bearing refers specifically to true north. In this International Standard bearing is used for any specified reference direction. The angle may be reckoned positive clockwise or positive counter-clockwise depending upon the application.

4.1.3 Cartesian coordinate system

coordinate system (4.1.8) which gives the position of points relative to n mutually perpendicular axes that each has zero curvature

Note 1 to entry:    n is 2 or 3 for the purposes of this International Standard.

4.1.4 compound coordinate reference system

coordinate reference system (4.1.7) using at least two independent coordinate reference systems

Note 1 to entry:    Coordinate reference systems are independent of each other if coordinate values in one cannot be converted or transformed into coordinate values in the other.

[SOURCE: ISO 19111:2007, 4.3]

4.1.5 coordinate conversion

coordinate operation (4.1.6) in which both coordinate reference systems (4.1.7) are based on the same datum(4.1.11)

EXAMPLE         Conversion from an ellipsoidal coordinate reference system based on the WGS 84 datum to a Cartesian coordinate reference system also based on the WGS 84 datum, or change of units such as from radians to degrees or feet to metres.

Note 1 to entry:    A coordinate conversion uses parameters which have specified values that are not determined empirically.

[SOURCE: ISO 19111:2007, 4.6]

4.1.6 coordinate operation

change of coordinates, based on a one-to-one relationship, from one coordinate reference system (4.1.7) to another

Note 1 to entry:    Supertype of coordinate transformation (4.1.9) and coordinate conversion (4.1.5).

[SOURCE: ISO 19111:2007, 4.7]

4.1.7 coordinate reference system

coordinate system (4.1.8) that is related to an object by a datum(4.1.11)

Note 1 to entry:    For geodetic and vertical datums (4.1.19, 4.1.39), the object will be the Earth.

[SOURCE: ISO 19111:2007, 4.8]

4.1.8 coordinate system

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

[SOURCE: ISO 19111:2007, 4.10]

4.1.9 coordinate transformation

coordinate operation (4.1.6) in which the two coordinate reference systems (4.1.7) are based on different datums(4.1.11)

Note 1 to entry:    A coordinate transformation uses parameters which are derived empirically by a set of points with known coordinates in both coordinate reference systems.

[SOURCE: ISO 19111:2007, 4.11]

4.1.10 cylindrical coordinate system

three-dimensional coordinate system (4.1.8) with two distance and one angular coordinates

[SOURCE: ISO 19111:2007, 4.13]

4.1.11 datum

parameter or set of parameters that define the position of the origin, the scale, and the orientation of a coordinate system (4.1.8)

[SOURCE: ISO 19111:2007, 4.14]

4.1.12 ellipsoid

surface formed by the rotation of an ellipse about a main axis

Note 1 to entry:    In this International Standard, ellipsoids are always oblate, meaning that the axis of rotation is always the minor axis.

[SOURCE: ISO 19111:2007, 4.17]

4.1.13 ellipsoidal coordinate system

geodetic coordinate system

coordinate system (4.1.8) in which position is specified by geodetic latitude(4.1.20), geodetic longitude (4.1.21) and (in the three-dimensional case) ellipsoidal height (4.1.14)

[SOURCE: ISO 19111:2007, 4.18]

4.1.14 ellipsoidal height

geodetic height

h

distance of a point from the ellipsoid (4.1.12) measured along the perpendicular from the ellipsoid to this point, positive if upwards or outside of the ellipsoid

Note 1 to entry:    Only used as part of a three-dimensional ellipsoidal coordinate system (4.1.13) and never on its own.

[SOURCE: ISO 19111:2007, 4.19]

4.1.15 engineering coordinate reference system

coordinate reference system (4.1.7) based on an engineering datum(4.1.16)

EXAMPLES       Local engineering and architectural grids; coordinate reference system local to a ship or an orbiting spacecraft.

[SOURCE: ISO 19111:2007, 4.20]

4.1.16 engineering datum

local datum

datum(4.1.11) describing the relationship of a coordinate system (4.1.8) to a local reference

Note 1 to entry:    Engineering datum excludes both geodetic and vertical datums (4.1.19, 4.1.39).

EXAMPLE         A system for identifying relative positions within a few kilometres of the reference point.

[SOURCE: ISO 19111:2007, 4.21]

4.1.17 flattening

f

ratio of the difference between the semi-major (a) and semi-minor axis (4.1.33) (b) of an ellipsoid (4.1.12) to the semi-major axis (4.1.32); f = (a – b)/a

Note 1 to entry:    Sometimes inverse flattening 1/f= a/(a-b) is given instead; 1/f is also known as reciprocal flattening.

[SOURCE: ISO 19111:2007, 4.22]

4.1.18 geodetic coordinate reference system

coordinate reference system (4.1.7) based on a geodetic datum(4.1.19)

[SOURCE: ISO 19111:2007, 4.23]

4.1.19 geodetic datum

datum(4.1.11) describing the relationship of a two- or three-dimensional coordinate system (4.1.8) to the Earth

[SOURCE: ISO 19111:2007, 4.24]

4.1.20 geodetic latitude

ellipsoidal latitude

φ

angle from the equatorial plane to the perpendicular to the ellipsoid (4.1.12) through a given point, northwards treated as positive

[SOURCE: ISO 19111:2007, 4.25]

4.1.21 geodetic longitude

ellipsoidal longitude

λ

angle from the prime meridian (4.1.30) plane to the meridian plane of a given point, eastward treated as positive

[SOURCE: ISO 19111:2007, 4.26]

4.1.22 image coordinate reference system

coordinate reference system (4.1.7) based on an image datum(4.1.23)

[SOURCE: ISO 19111:2007, 4.30]

4.1.23 image datum

engineering datum (4.1.16) which defines the relationship of a coordinate system (4.1.8) to an image

[SOURCE: ISO 19111:2007, 4.31]

4.1.24 linear coordinate system

one-dimensional coordinate system (4.1.8) in which a linear feature forms the axis

EXAMPLES       Distances along a pipeline; depths down a deviated oil well bore.

[SOURCE: ISO 19111:2007, 4.32]

4.1.25 map projection

coordinate conversion (4.1.4) from an ellipsoidal coordinate system (4.1.13) to a plane

[SOURCE: ISO 19111:2007, 4.33]

4.1.26 parametric coordinate reference system

coordinate reference system (4.1.7) based on a parametric datum(4.1.28)

[SOURCE: ISO 19111-2:2009, 4.2]

4.1.27 parametric coordinate system

one-dimensional coordinate system (4.1.8) where the axis units are parameter values which are not inherently spatial

[SOURCE: ISO 19111-2:2009, 4.1]

4.1.28 parametric datum

datum(4.1.11) describing the relationship of a parametric coordinate system (4.1.27) to an object

Note 1 to entry:    The object is normally the Earth.

[SOURCE: ISO 19111-2:2009, 4.3]

4.1.29 polar coordinate system

two-dimensional coordinate system (4.1.8) in which position is specified by distance and direction from the origin

Note 1 to entry:    For the three-dimensional case, see spherical coordinate system (4.1.35).

[SOURCE: ISO 19111:2007, 4.37]

4.1.30 prime meridian

zero meridian

meridian from which the longitudes of other meridians are quantified

[SOURCE: ISO 19111:2007, 4.38]

4.1.31 projected coordinate reference system

coordinate reference system (4.1.7) derived from a two-dimensional geodetic coordinate reference system (4.1.18) by applying a map projection (4.1.25)

[SOURCE: ISO 19111:2007, 4.39]

4.1.32 semi-major axis

a

semi-diameter of the longest axis of an ellipsoid (4.1.12)

Note 1 to entry:    This equates to the semi-diameter of the ellipsoid measured in its equatorial plane.

[SOURCE: ISO 19111:2007, 4.40]

4.1.33 semi-minor axis

b

semi-diameter of the shortest axis of an ellipsoid (4.1.12)

Note 1 to entry:    The shortest axis coincides with the rotation axis of the ellipsoid and therefore contains both poles.

[SOURCE: ISO 19111:2007, 4.41]

4.1.34 spatio-parametric coordinate reference system

compound coordinate reference system (4.1.4) in which one constituent coordinate reference system (4.1.7) is a parametric coordinate reference system (4.1.26) and one is a spatial coordinate reference system

Note 1 to entry:    Normally the spatial component is “horizontal” and the parametric component is “vertical”.

[SOURCE: ISO 19111-2:2009, 4.4]

4.1.35 spherical coordinate system

three-dimensional coordinate system (4.1.8) with one distance measured from the origin and two angular coordinates, commonly associated with a geodetic coordinate reference system (4.1.18)

Note 1 to entry:    Not to be confused with an ellipsoidal coordinate system (4.1.13) based on an ellipsoid (4.1.12) ‘degenerated’ into a sphere.

[SOURCE: ISO 19111:2007, 4.44]

4.1.36 spheroid

closed surface that differs only slightly from that of a sphere

4.1.37 vertical coordinate reference system

one-dimensional coordinate reference system (4.1.7) based on a vertical datum(4.1.39)

[SOURCE: ISO 19111:2007, 4.47]

4.1.38 vertical coordinate system

one-dimensional coordinate system (4.1.8) used for gravity-related height or depth measurements

[SOURCE: ISO 19111:2007, 4.48]

4.1.39 vertical datum

datum(4.1.11) describing the relation of gravity-related heights or depths to the Earth

Note 1 to entry:    In most cases, the vertical datum will be related to mean sea level. Ellipsoidal heights (4.1.14) are treated as related to a three-dimensional ellipsoidal coordinate system (4.1.13) referenced to a geodetic datum (4.1.19). Vertical datums include sounding datums (used for hydrographic purposes), in which case the heights may be negative heights or depths.

[SOURCE: ISO 19111:2007, 4.49]

4.1.40 white space

consecutive sequences of one or more characters that have no glyphs

[SOURCE: ISO/IEC 9075-2:2011, 3.1.6.48]

4.2 Abbreviations

The following symbols and abbreviated are used in this standard;

BNF
     Backus-Naur form
CRS
     coordinate reference system
CS
     coordinate system
EPSG
     European Petroleum Survey Group geodetic parameter dataset now maintained at
www.epsg-registry.org by the International Association of Oil and Gas Producers
IRM
     international reference meridian
OGC
     Open Geospatial Consortium, www.opengeospatial.org
UTC
     Coordinated Universal Time
WKT
     Well-known text

5. Backus-Naur Form notation and syntax

The WKT representation of coordinate reference systems and coordinate operations is defined in this International Standard using the extended version of Backus-Naur form (BNF) notation that is defined in ISO/IEC 9075-1:2011, 6.2. The BNF provides the mechanism for generating a WKT string. The production  rules in ISO/IEC 9075-1:2011, 6.2 apply.

In this extended version of BNF the characters have the meaning:

In the BNF notation spaces are used to separate syntactic elements. Multiple spaces and line breaks are treated as a single space. These spaces do not form part of the resulting WKT string. All other characters in the BNF stand for themselves. The order of syntactic elements in the BNF is significant; it defines the format of the WKT string.

6. WKT string form

6.1 Overview

The WKT string is a representation of the definition of a CRS or coordinate operation. A string describes one CRS or coordinate operation object. Each object is represented by a token comprised of a keyword followed by a set of attributes of the object, the set enclosed by delimiters. Some objects are composed of other objects so the result may be a nested structure. Nesting may continue to any depth.

EXAMPLE         KEYWORD1[attribute1,KEYWORD2[attribute2,attribute3]]

Keywords are case-insensitive. Where human readability of the string is important, as in this International Standard, keywords are normally in upper case.

The delimiters are normally <left bracket> and <right bracket>. Implementations are free to substitute parentheses for brackets.

Attributes may be from an enumeration, be numbers or be text. Text is enclosed in double quotes. Two forms of text are defined, one restricted to the Latin1 character set and the other permitting any Unicode character set. Attributes are separated by a comma.

A WKT string contains no white space outside of double quotes. However padding with white space to improve human readability is permitted; the examples of WKT that are included in this document have spaces and line feeds inserted to improve clarity. Any padding is stripped out or ignored by parsers – refer to Annex B.

6.2 Encoding

All WKT strings are realized as a sequence of characters, or a character string. It is not the goal of this standard to specify any encoding used in a given implementation. The only restriction is that the same encoding shall be used throughout the entire WKT definition.

Requirements:

i)       A WKT string shall use one encoding throughout the entire string.

ii)      The characters used in a WKT string shall be wholly contained within the domain of a specific character set. This character set shall exist as a subset of the repertoire of the Universal Character Set specified by ISO 10646:2012.

6.3 Characters used in WKT

Basic characters

The basic characters in a CRS WKT string are taken directly from ISO 9075-2:2011, 5.1 and 5.3.

<simple Latin upper case letter>

::=

A | B | C | D | E | F | G | H | I | J | K | L | M |

N | O | P | Q | R | S | T | U | V | W | X | Y | Z

!! ISO/IEC 10646:2012 character identifiers U+0041 through U+005A

<simple Latin lower case letter>

::=

a | b | c | d | e | f | g | h | i | j | k | l | m |

n | o | p | q | r | s | t | u | v | w | x | y | z

!! ISO/IEC 10646:2012 character identifiers U+0061 through U+007A

<digit>

::=

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

!! ISO/IEC 10646:2012 character identifiers U+0030 through U+0039

<space>

::=

SP

!! ISO/IEC 10646:2012 character identifier U+0020

 

<double quote>

::=

"    

!! ISO/IEC 10646:2012 character identifier U+0022

 

<number sign>

::=

#   

!! ISO/IEC 10646:2012 character identifier U+0023

 

<percent>

::=

%     

!! ISO/IEC 10646:2012 character identifier U+0025

 

<ampersand>

::=

&

!! ISO/IEC 10646:2012 character identifier U+0026

 

<quote>

::=

'

!! ISO/IEC 10646:2012 character identifier U+0027

 

<left paren>

::=

(     

!! ISO/IEC 10646:2012 character identifier U+0028

 

<right paren>

::=

)    

!! ISO/IEC 10646:2012 character identifier U+0029

 

<asterisk>

::=

*

!! ISO/IEC 10646:2012 character identifier U+002A

 

<plus sign>

::=

+    

!! ISO/IEC 10646:2012 character identifier U+002B

 

<comma>

::=

,    

!! ISO/IEC 10646:2012 character identifier U+002C

 

<minus sign>       ::-    <hyphen>

::=

-    

!! ISO/IEC 10646:2012 character identifier U+002D

 

<period>

::=

.    

!! ISO/IEC 10646:2012 character identifier U+002E

 

<solidus>

::=

/    

!! ISO/IEC 10646:2012 character identifier U+002F

 

<colon>

::=

:    

!! ISO/IEC 10646:2012 character identifier U+003A

 

<semicolon>

::=

;    

!! ISO/IEC 10646:2012 character identifier U+003B

 

<less than operator>

::=

<    

!! ISO/IEC 10646:2012 character identifier U+003C

 

<equals operator>

::=

=    

!! ISO/IEC 10646:2012 character identifier U+003D

 

<greater than operator>

::=

>    

!! ISO/IEC 10646:2012 character identifier U+003E

 

<question mark>

::=

?    

!! ISO/IEC 10646:2012 character identifier U+003F

 

<left bracket>

::=

[    

!! ISO/IEC 10646:2012 character identifier U+005B

 

<reverse solidus>

::=

\      

!! ISO/IEC 10646:2012 character identifier U+005C

 

<right bracket>

::=

]    

!! ISO/IEC 10646:2012 character identifier U+005D

 

<circumflex>

::=

^    

!! ISO/IEC 10646:2012 character identifier U+005E

 

<underscore>

::=

_    

!! ISO/IEC 10646:2012 character identifier U+005F

 

<left brace>

::=

{    

!! ISO/IEC 10646:2012 character identifier U+007B

 

<vertical bar>

::=

|    

!! ISO/IEC 10646:2012 character identifier U+007C

 

<right brace>

::=

}    

!! ISO/IEC 10646:2012 character identifier U+007D

 

<degree symbol>

::=

°    

!! ISO/IEC 10646:2012 character identifier U+00B0

 

Numbers

<number> ::= <signed numeric literal> | <unsigned numeric literal>  
<signed numeric literal> ::= [ <sign> ] <unsigned numeric literal>  
<unsigned numeric literal> ::= <exact numeric literal> | <approximate numeric literal>  
<approximate numeric literal> ::= <mantissa> E <exponent>  
<mantissa> ::= <exact numeric literal>  
<exponent> ::= <signed integer>  
<signed integer> ::= [ <sign> ] <unsigned integer>  
<exact numeric literal> ::= <unsigned integer> [ <period> [ <unsigned integer> ] ] | <period> <unsigned integer>  
<unsigned integer> ::= <digit>...  
<sign> ::= <plus sign> | <minus sign>  

The integer and fractional parts of a number are separated by a <period>; a comma is not permitted. No other separator (e.g. for thousands or multiples thereof) is allowed.

Date and time

In this International Standard calendar dates and times are restricted to the Gregorian calendar, the 24-hour clock and UTC as defined in ISO 8601:2004. Only the ISO 8601 extended format (separators between date units and between sexagesimal time units) is permitted; truncation and extension is not catered for. Any precision is allowed. Other date formats such as geological eras or calendars other than Gregorian may be stated through a free format quoted text string.

NOTE 1     It is anticipated that a more exhaustive treatment of date and time may be made in a revision to this International Standard which could follow the deliberations of the OGC Temporal domain working group and/or an update of ISO 19108:2002.

<datetime> ::= <Gregorian calendar datetime> | <Gregorian ordinal datetime>
<Gregorian calendar datetime> ::= <Gregorian calendar date> [ <24 hour clock> ]
<Gregorian calendar date> ::= <year> [ <hyphen> <month> [ <hyphen> <day> ] ]
<year> ::= <unsigned integer>         !! four digits
<month> ::= <unsigned integer> !! two digits including leading zero if less than 10
<day> ::= <unsigned integer>    !! two digits including leading zero if less than 10
<Gregorian ordinal datetime> ::= <Gregorian ordinal date> [ <24 hour clock> ]
<Gregorian ordinal date> ::= <year> [ <hyphen> <ordinal day> ]
<ordinal day> ::= <unsigned integer> !! three digits including leading zeroes if less than 100
<24 hour clock> ::= <time designator> <hour> [ <colon> <minute> [ <colon> <second> ] ] <time zone designator>
<time designator> ::= T
<hour> ::= <unsigned integer> !! two digits including leading zero if less than 10
<minute> ::= <unsigned integer> !! two digits including leading zero if less than 10
<second> ::= <seconds integer> [ <period> [ <seconds fraction> ] ] !! In this International Standard the separator between the integer and fractional parts of a second value shall be a period. The ISO 8601 preference for comma is not permitted.
<seconds integer> ::= <unsigned integer> !! two digits including leading zero if less than 10
<seconds fraction> ::= <unsigned integer>
<time zone designator> ::= <utc designator> | <local time zone designator>
<utc designator> ::= Z
<local time zone designator> ::= { <plus sign> | <minus sign> } <hour> [ <colon> <minute> ]

NOTE 2     In ISO 8601 time zone designator may be omitted, in which case local time is assumed but unspecified. In this International Standard a time zone designator is mandatory.

EXAMPLE 1    2014                            (Precision = year)

EXAMPLE 2    2014-01                         (Calendar date, precision = month)

EXAMPLE 3    2014-03-01                      (Calendar date, precision = day)

EXAMPLE 4    2014-060                        (Ordinal date, precision = day)

EXAMPLE 5    2014-05-06T23Z              (Calendar date, precision = hour)

EXAMPLE 6    2014-157T23Z                    (Ordinal date, precision = hour)

EXAMPLE 7    2014-07-12T16:00Z               (Precision = minute, UTC)

EXAMPLE 8    2014-07-12T17:00+01         (Precision = minute, local time one hour ahead of UTC)

EXAMPLE 9    2014-09-18T08:17:56Z            (Precision = second)

EXAMPLE 10  2014-11-23T00:34:56.789Z        (Precision = 1/1000 second)

CRS WKT characters

The characters permitted in elements of a CRS WKT string formed from those in 6.3.1, 6.3.2 and 6.3.3 are:

<left delimiter> ::= <left bracket> | <left paren> !!  In this International Standard the preferred left delimiter is <left bracket>. <left paren> is permitted for backward compatibility. Implementations shall be able to read both forms.  
<right delimiter> ::= <right bracket> | <right paren>                  !! See 6.4
<wkt separator> ::= <comma>
<quoted Latin text> ::= <double quote> <wkt Latin text character>… <double quote>  
<wkt Latin text character> ::= <simple Latin upper case letter> | <simple Latin lower case letter> | <digit> | <underscore> | <left bracket> | <right bracket> | <left paren> | <right paren> | <left brace> | <right brace> | <less than operator> | <equals operator> | <greater than operator> | <period> | <comma> | <colon> | <semicolon> | <plus sign> | <minus sign> | <space> | <number sign> | <percent> | <ampersand> | <quote> | <asterisk> | <circumflex> | <solidus> | <reverse solidus> | <question mark> | <vertical bar>  | <degree symbol> | <doublequote symbol>  
<quoted Unicode text> ::= <double quote> { <wkt Unicode text character> }… <double quote>
<wkt Unicode text character> ::= <nondoublequote character> | <doublequote symbol>  
<nondoublequote character> ::= !! A <nondoublequote character> is any character of the source language character set other than a <double quote>.  
<doublequote symbol> ::= ""   !! two consecutive <double quote> characters

Double quote

Requirement: If a double quote is required within a <quoted Latin text> or <quoted Unicode text> string, a <doublequote symbol> shall be used.

EXAMPLE         “Datum origin is 30°25’20”“N, 130°25’20”“E.”         

6.4 Delimiter

In WKT strings the attributes for an item are included within a pair of left and right delimiters. The delimiters should normally be <left bracket> and <right bracket>. Implementations are free to substitute parentheses for brackets. If <left bracket> is used as a <left delimiter> then <right bracket> must be used as the corresponding <right delimiter>; if <left paren> is used as a <left delimiter> then <right paren> must be used as the corresponding <right delimiter>. A nested token must use the same type of delimiter as the token in which it is nested.

Requirement:  A CRS WKT string shall include only one of the two forms of delimiter, brackets or parentheses, allowed in 6.3.4.

6.5 Case sensitivity

WKT keywords are case insensitive. KEYWORD is equivalent to keyword is equivalent to KeyWord and to kEYwORd. Where human readability is important (as in the examples in this International Standard) keywords should be written in only the <simple Latin upper case letter> set. KEYWORD is not equivalent to KEY_WORD; the underscore character is significant.

WKT enumerations are case insensitive. CARTESIAN is equivalent to cartesian is equivalent to Cartesian; NORTH is equivalent to north is equivalent to North.

Within quoted text, case is significant. “H” is not equivalent to “h”.

Requirement: Outside ofquoted text, characters in a WKT string shall not be case sensitive.

6.6 Reserved keywords

The keywords defined in Clauses 7 through 18 of this International Standard for coordinate reference systems, coordinate operations, their component elements and their attributes are summarised here. Those formed from multiple words or abbreviations are given in camel case to aid understanding; see 6.5 for implementation in a WKT string.

Keyword BNF element Clause in which defined
abridgedTransformation <abridged transformation keyword> 18
anchor <datum anchor keyword> 8, 10, 11, 12 and 13
angleUnit <angle unit keyword> 7
area <area description keyword> 7
axis <axis keyword> 7
baseEngCRS <base engineering crs keyword> 15
baseGeodCRS <base geodetic crs keyword> 9 and 15
baseParamCRS <base parametric crs keyword> 15
baseProjCRS <base projected crs keyword> 15
baseTimeCRS <base temporal crs keyword> 15
baseVertCRS <base vertical crs keyword> 15
bBox <geographic bounding box keyword> 7
bearing <bearing keyword> 7
boundCRS <bound crs keyword> 18
citation <citation keyword> 7
compoundCRS <compound crs keyword> 16
conversion <map projection keyword> 9
coordinateOperation <operation keyword> 17
cs <cs keyword> (coordinate system) 7
datum <geodetic datum keyword> 8
derivingConversion <deriving conversion keyword> 15
eDatum <engineering datum keyword> 11
ellipsoid <ellipsoid keyword> 8
engCRS <engineering crs keyword> 11 and 15
engineeringCRS Alternative keyword for engineering crs 11 and 15
engineeringDatum Alternative keyword for engineering datum 11
geodCRS <geodetic crs keyword> 8 and 15
geodeticCRS Alternative keyword for geodetic crs 8 and 15
geodeticDatum Alternative keyword for geodetic datum 8
id <identifier keyword> 7
iDatum <image datum keyword> 12
imageCRS <image crs keyword> 12
imageDatum Alternative keyword for image datum 12
interpolationCRS <interpolation crs keyword> 17
lengthUnit <length unit keyword> 7
meridian <meridian keyword> 7
method (i) <map projection method keyword> 9
  (ii) <operation method keyword> 15 and 17
operationAccuracy <operation accuracy keyword> 17
order <axis order keyword> 7
parameter <parameter keyword> 9, 15 and 17
parameterFile <parameter file keyword> 15 and 17
parametricCRS <parametric crs keyword> 13 and 15
parametricDatum Alternative keyword for parametric datum 13
parametricUnit <parametric unit keyword> 7
pDatum <parametric datum keyword> 13
primeM <prime meridian keyword> 8
primeMeridian Alternative keyword for prime meridian 8
projCRS <projected crs keyword> 9
projectedCRS Alternative keyword for projected crs 9
projection Alternative keyword for map projection method 9
remark <remark keyword> 7
scaleUnit <scale unit keyword> 7
scope <scope keyword> 7
sourceCRS <source crs keyword> 17
spheroid Alternative keyword for ellipsoid 8
targetCRS <target crs keyword> 17
tDatum <temporal datum keyword> 14
timeCRS <temporal crs keyword> 14 and 15
timeDatum Alternative keyword for temporal datum 14
timeExtent <temporal extent keyword> 7
timeOrigin <temporal origin keyword> 14
timeUnit <temporal unit keyword> 7
unit Alternative keyword for all units 7
uri <uri keyword> 7
vDatum <vertical datum keyword> 10
vertCRS <vertical crs keyword> 10 and 15
verticalCRS Alternative keyword for vertical crs 10 and 15
verticalDatum Alternative keyword for vertical datum 10
verticalExtent <vertical extent keyword> 7

 

6.7 Backward compatibility

This document makes several references to backward compatibility. Backward compatibility means that an implementation of the text strings in this International Standard would be able to read CRS WKT strings conforming to the old (ISO 19125-1:2004) syntax. It does not mean that a parser of a string compliant to ISO 19125-1:2004 could read WKT strings written in conformance with this International Standard. It also does not require an implementation of the text strings in this International Standard to be able to output an object according to the old syntax. Annex B.8 gives guidance on determining the version of a CRS WKT string. A mapping of older syntaxes to this International Standard is given in Annex C.

7. WKT representation of common attributes

7.1 Introduction

The WKT representation of attributes that are common to coordinate reference systems and coordinate operations is described in 7.2 to 7.4. Coordinate systems are described in 7.5. Attributes specific to coordinate reference systems and to coordinate operations are described in Clauses 8 to 17.

7.2 Name

From a computational perspective name is redundant information provided for human readability. For example an ellipsoid is defined by the values of the semi-major axis and inverse flattening, and the ellipsoid name is redundant information. However the name may be used to verify the defining values against those from an authoritative source. Comment on the comparison of text strings is given in Annex B.

NOTE        Name is a required attribute for the CRS object as well as for some component objects. Depending upon the convention adopted for CRS naming, this may result in duplication of name within the CRS WKT string.

7.3 Scope, extent, identifier and remark

Introduction

The BNF element <scope extent identifier remark> is a collection of four optional attributes which may be applied to a coordinate reference system, a coordinate operation or a boundCRS. <scope> is described in 7.3.2, <extent> in 7.3.3, <identifier> in 7.3.4 and <remark> in 7.3.5. The <scope extent identifier remark> collection is to simplify the BNF through grouping; each of the four attributes may appear separately in a WKT string.

Requirement: The WKT representation of a <scope extent identifier remark> element shall be:

<scope extent identifier remark> ::= [ <wkt separator> <scope> ]  [ { <wkt separator> <extent> } ]...  [ { <wkt separator> <identifier> } ]…  [ <wkt separator> <remark>]

Scope

Scope is an optional attribute which describes the purpose or purposes for which a CRS or a coordinate operation is applied.

Requirement: The WKT representation of a <scope> shall be:

<scope> ::= <scope keyword> <left delimiter> <scope text description> <right delimiter>  
<scope keyword> ::= SCOPE
<scope text description> ::= <quoted Latin text>

EXAMPLE         SCOPE["Large scale topographic mapping and cadastre."]

Extent

Introduction

Extent describes the spatial applicability of a CRS or a coordinate operation. Extent in this International Standard uses the concepts described in ISO 19115:2003, Geographic information – Metadata. However this International Standard permits horizontal extent to be described by description or geographic bounding box, but not by polygon because of string length considerations. It also allows for vertical and temporal extent. These extent attributes are all optional. Multiple extent attributes may be provided, but there is a constraint that these must be of different types.

Requirement: The WKT representation of an <extent> shall be:

<extent> ::= <area description> | <geographic bounding box> | <vertical extent> | <temporal extent> !! Constraint: each extent type shall have a maximum occurrence of 1.

Area description

Area description is an optional attribute which describes a geographic area over which a CRS or coordinate operation is applicable. 

Requirement: The WKT representation of an <area description> shall be:

<area description> ::= <area description keyword> <left delimiter> <area text description> <right delimiter>  
<area description keyword> ::= AREA
<area text description> ::= <quoted Latin text>

EXAMPLE         AREA["Netherlands offshore."]

Geographic bounding box

The geographic bounding box is an optional attribute which describes a “north up” area. Upper right latitude will be greater than the lower left latitude. Generally the upper right longitude will be greater than the lower left longitude. However when the area crosses the 180° meridian, the value of the lower left longitude will be greater than the value of the upper right longitude.

The geographic bounding box is an approximate description of location. For most purposes a coordinate precision of two decimal places of a degree is sufficient. At this resolution the identification of the geodetic CRS to which the bounding box coordinates are referenced is not required.

Requirement: The WKT representation of a <geographic bounding box> shall be:

<geographic bounding box> ::= <geographic bounding box keyword> <left delimiter> <lower left latitude> <wkt separator> <lower left longitude> <wkt separator> <upper right latitude> <wkt separator> <upper right longitude> <right delimiter>  
<geographic bounding box keyword> ::= BBOX
<lower left latitude> ::= <number>          !! See text
<lower left longitude> ::= <number>          !! See text
<upper right latitude> ::= <number>          !! See text
<upper right longitude> ::= <number>          !! See text

Requirement: bounding box latitude coordinates shall be given in decimal degrees in the range -90 to +90, longitude coordinates shall be given in decimal degrees in the range -180 to +180 relative to the international reference meridian.

EXAMPLE         BBOX[51.43,2.54,55.77,6.40] for a geographic bounding box enveloping offshore Netherlands.

Vertical extent

Vertical extent is an optional attribute which describes a height range over which a CRS or coordinate operation is applicable. Depths have negative height values. Vertical extent is an approximate description of location; heights are relative to an unspecified mean sea level.

Requirement: The WKT representation of a <vertical extent> shall be:

<vertical extent> ::= <vertical extent keyword> <left delimiter> <vertical extent minimum height> <wkt separator> <vertical extent maximum height> [ <wkt separator> <length unit> ] <right delimiter>  
<vertical extent keyword> ::= VERTICALEXTENT
<vertical extent minimum height> ::= <number>
<vertical extent maximum height> ::= <number>

Requirement: If vertical extent units are not stated they shall be assumed to be metres.

EXAMPLE 1      VERTICALEXTENT[-1000,0,LENGTHUNIT[“metre”,1.0]]

EXAMPLE 2      VERTICALEXTENT[-1000,0]                                       (where the heights are implicitly in metres).

Temporal extent

Temporal extent is an optional attribute which describes a date or time range over which a CRS or coordinate operation is applicable. The format for date and time values is defined in ISO 9075-2. Start time is earlier than end time.

Requirement: The WKT representation of a <temporal extent> shall be:

<temporal extent> ::= <temporal extent keyword> <left delimiter> <temporal extent start> <wkt separator> <temporal extent end> <right delimiter>  
<temporal extent keyword> ::= TIMEEXTENT
<temporal extent start> ::= <datetime> | <quoted Latin text>
<temporal extent end> ::= <datetime> | <quoted Latin text>

EXAMPLE 1      TIMEEXTENT[2013-01-01,2013-12-31]

EXAMPLE 2      TIMEEXTENT[“Jurassic”,“Quaternary”]

Identifier

Identifier is an optional attribute which references an external description of the object and which may be applied to a coordinate reference system, a coordinate operation or a boundCRS. It may also be utilised for components of these objects although this is not recommended except for coordinate operation methods (including map projections) and parameters. Multiple identifiers may be given for any object.

When an identifier is given for a coordinate reference system, coordinate operation or boundCRS, it applies to the whole object including all of its components.

Should any attributes or values given in the cited identifier be in conflict with attributes or values given explicitly in the WKT description, the WKT values shall prevail.

Requirement: The WKT representation of an <identifier> shall be:

<identifier> ::= <identifier keyword> <left delimiter> <authority name> <wkt separator> <authority unique identifier>  [ <wkt separator> <version> ] [ <wkt separator> <authority citation> ] [ <wkt separator> <id uri> ] <right delimiter>  
<identifier keyword> ::= ID
<authority name> ::= <quoted Latin text>
<authority unique identifier> ::= <number> | <quoted Latin text>
<version> ::= <number> | <quoted Latin text>
<authority citation> ::= <citation keyword> <left delimiter> <citation> <right delimiter>  
<citation keyword> ::= CITATION
<citation> ::= <quoted Latin text>
<id uri> ::= <uri keyword> <left delimiter> <uri> <right delimiter> }  
<uri keyword> ::= URI
<uri> ::= <quoted Latin text>

Version is an optional attribute indicating the version of the repository or object that is cited. Citation is an optional attribute that may be used to give further details of the authority. URI is an optional attribute that may be used to give reference to an online resource.

NOTE        In previous specifications the authority object was defined more narrowly than is identifier in this International Standard. See Annex C.

EXAMPLE 1      ID[“Authority name”,“Abcd_Ef”,7.1]

EXAMPLE 2      ID[“EPSG”,4326]

EXAMPLE 3      ID[“EPSG”,4326,URI[“urn:ogc:def:crs:EPSG::4326”]]

EXAMPLE 4      ID[“EuroGeographics”,“ES_ED50 (BAL99) to ETRS89”,“2001-04-20”]

Further examples are included in Clauses 8 to 17.

Remark

<remark> an optional attribute. Any information contained in a <remark> is informative. It does not modify the defining parameters of an object.

A <remark> may be applied to a coordinate reference system, coordinate operation or boundCRS as a whole. A <remark> should not be included in the WKT for components of a coordinate reference system or coordinate operation, but a remark in the coordinate reference system or coordinate operation object may include information about these components.

NOTE        A <remark> can be included within the descriptions of source and target CRS embedded within a coordinate transformation as well as within the coordinate transformation itself.

Any character other than a <wkt Latin text character> that is to be contained in a CRS WKT string may be included only as part of <quoted Unicode text> within a <remark>.

Requirement: The WKT representation of a <remark> shall be:

<remark> ::= <remark keyword> <left delimiter> <quoted Unicode text> <right delimiter>  
<remark keyword> ::= REMARK

EXAMPLE 1      REMARK[“A remark in ASCII”]

EXAMPLE 2      REMARK["Замечание на русском языке"]

EXAMPLE 3 

    GEODCRS[“S-95”,
   DATUM[“Pulkovo 1995”,
     ELLIPSOID[“Krassowsky 1940”,6378245,298.3, 
       LENGTHUNIT[“metre”,1.0]]],
   CS[ellipsoidal,2],
     AXIS[“latitude”,north,ORDER[1]],
     AXIS[“longitude”,east,ORDER[2]],
     ANGLEUNIT[“degree”,0.0174532925199433],
   REMARK[“Система Геодеэических Координвт года 1995(СК-95)”]]

Further examples including remarks are included in Clauses 8 to 17.

7.4 Unit and unit conversion factor

Some attributes of coordinate reference systems and coordinate operations are numbers which require the unit to be specified.

Requirement: The WKT representation of a <unit> description shall be:

<unit> ::= <angle unit> | <length unit> | <scale unit> | <parametric unit> | <time unit>  
<angle unit> ::= <angle unit keyword> <left delimiter> <unit name> <wkt separator> <conversion factor> [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<length unit> ::= <length unit keyword> <left delimiter> <unit name> <wkt separator> <conversion factor> [ { <wkt separator> <identifier> } ]…  <right delimiter  
<scale unit> ::= <scale unit keyword> <left delimiter> <unit name> <wkt separator> <conversion factor> [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<parametric unit> ::= <parametric unit keyword> <left delimiter> <unit name> <wkt separator> <conversion factor> [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<time unit> ::= <time unit keyword> <left delimiter> <unit name> <wkt separator> <conversion factor> [ { <wkt separator> <identifier> } ]… <right delimiter>  
<angle unit keyword> ::= ANGLEUNIT | UNIT !!  In this International Standard the preferred keyword is ANGLEUNIT. UNIT is permitted for backward compatibility. Implementations shall be able to read both forms.  
<length unit keyword> ::= LENGTHUNIT | UNIT !!  In this International Standard the preferred keyword is LENGTHUNIT. UNIT is permitted for backward compatibility. Implementations shall be able to read both forms.  
<scale unit keyword> ::= SCALEUNIT | UNIT !!  In this International Standard the preferred keyword is SCALEUNIT. UNIT is permitted for backward compatibility. Implementations shall be able to read both forms.  
<parametric unit keyword> ::= PARAMETRICUNIT
<time unit keyword> ::= TIMEUNIT
<unit name> ::= <quoted Latin text>
<conversion factor> ::= <unsigned numeric literal>  
<conversion factor> is the number of SI standard units per unit.
<identifier> is described in 7.3.4.

Requirements: If the unit is linear its conversion factor shall be to metres and is the number of metres per unit. If the unit is angular its conversion factor shall be to radians and is the number of radians per unit. For other unit types the appropriate SI standard unit shall be used. For scale, unity shall be used.

EXAMPLE 1      LENGTHUNIT["metre",1]

EXAMPLE 2      LENGTHUNIT[“German legal metre”,1.0000135965]

EXAMPLE 3      ANGLEUNIT[“degree”,0.0174532925199433]

EXAMPLE 4      SCALEUNIT[“parts per million”,1E-06]

EXAMPLE 5      PARAMETRICUNIT[“hectopascal”,100]

Further examples are included in Clauses 8 to 17.

7.5 Coordinate system

Syntax

Requirement: The WKT representation of a coordinate system shall be:

<coordinate system> ::= <cs keyword> <left delimiter> <cs type> <wkt separator> <dimension> [ { <wkt separator> <identifier> } ]…  <right delimiter> { <wkt separator> <axis> }… [ <wkt separator> <cs unit> ]  
<cs keyword> ::= CS
<cs type> ::= affine | Cartesian | cylindrical | ellipsoidal | linear | parametric | polar | spherical | temporal | vertical !! See 7.5.2 for constraints
<dimension> ::= 1 | 2 | 3           !! Unsigned integer. See 7.5.2 for constraints.  
<axis> ::= <axis keyword> <left delimiter>  <axis nameAbbrev> <wkt separator> <axis direction> [ <wkt separator> <axis order> ] [ <wkt separator> <axis unit> ] [ { <wkt separator> <identifier> } ]…  <right delimiter> !! See 7.5.3, 7.5.4 and 7.5.5 for constraints  
<axis keyword> ::= AXIS
<axis nameAbbrev>   <double quote> { <axis name> | <axis abbreviation> | <axis name and abbrev> } <double quote>  
<axis name> ::= <wkt Latin text character>…
<axis abbreviation> ::= <left paren> <simple Latin letter>… <right paren>  
<axis name and abbrev> ::= <axis name> <space> <axis abbreviation>
<axis direction>   north [ { <wkt separator> <meridian> } ] | northNorthEast | northEast | eastNorthEast | east | eastSouthEast | southEast | southSouthEast | south [ { <wkt separator> <meridian> } ] | southWest | westSouthWest | west | westNorthWest | northWest | northNorthWest | geocentricX | geocentricY | geocentricZ | up | down | forward | aft | port | starboard | clockwise <wkt separator> <bearing> | counterClockwise <wkt separator> <bearing> | columnPositive | columnNegative | rowPositive | rowNegative | displayRight | displayLeft | displayUp | displayDown | future | past | towards | awayFrom | unspecified !! See 7.5.4 for constraints  
<meridian> ::= <meridian keyword> <left delimiter> <number> <wkt separator> <angle unit> <right delimiter> !! See 7.5.4 for constraints
<meridian keyword> ::= MERIDIAN
<bearing> ::= <bearing keyword> <left delimiter> <number> <right delimiter> !! See 7.5.4 for constraints  
<bearing keyword> ::= BEARING
<axis order> ::= <axis order keyword> <left delimiter> <unsigned integer> <right delimiter> !! See 7.5.5 for constraints  
<axis order keyword> ::= ORDER
<axis unit> ::= <unit>              !! See 7.4 and 7.5.6 for constraints
<cs unit> ::= <unit>              !! See 7.4 and 7.5.6 for constraints

An <ellipsoidal 2D coordinate system> is a special case of <coordinate system> required in the construct of the <geographic 2D crs> element of a compound CRS (Clause 16):

<ellipsoidal 2D coordinate system> ::= <cs keyword> <left delimiter> <ellipsoidal 2D cs type> <wkt separator> <ellipsoidal 2D dimension> [ { <wkt separator> <identifier> } ]…  <right delimiter> { <wkt separator> <axis> }… [ <wkt separator> <cs unit> ]  
<ellipsoidal 2D cs type> ::= ellipsoidal
<ellipsoidal 2D dimension> ::= 2

Coordinate system type and dimension

For various types of CRS the type of coordinate system that may be used is constrained, as is the permissible number of axes. These constraints are summarised in Table 2.

Table : Permitted coordinate system type and dimension by CRS
CRS type Permitted CS type(s) Dimension
(number of axes)
geodetic Cartesian
ellipsoidal
spherical 		3
2 or 3
3
projected Cartesian 2
vertical vertical 1
engineering affine
Cartesian
cylindrical
linear
polar
spherical 		2 or 3
2 or 3
3
1
2
3
image affine
Cartesian 		2
2
parametric parametric 1
temporal time 1

 

See 6.5 for comment on case sensitivity.

Axis name and abbreviation

ISO 19111 requires the name and abbreviation for each axis. In this International Standard, name and/or abbreviation is permitted. They are contained in a single quoted text string. If abbreviation is included in the text string it is given in parentheses.

EXAMPLE 1      “easting”

EXAMPLE 2      “(X)”

EXAMPLE 3      “easting (X)”

Requirement:The following constraints shall apply:

  1.     In WKT strings all axis abbreviations shall be from the <wkt Latin text character> set.
  2.     For geodetic CRSs having a two-dimensional ellipsoidal coordinate system, the two-dimensional ellipsoidal coordinate system axes are geodetic latitude and geodetic longitude. In WKT strings the values of axis name shall be ‘latitude’ and ‘longitude’ respectively.

    NOTE     ISO 19111:2007 specifies the lower case Greek letters φ and λ as symbols for geodetic latitude and geodetic longitude. In this International Standard the abbreviations to be used in WKT strings must be from the Latin character set. P and L are the transliterations of the Greek letters phi and lambda. B for Breite and L for Länge are the standard German abbreviations and used in academic texts worldwide. ‘lat’ and ‘lon’ are in common usage.

  3.    For geodetic CRSs having a three-dimensional ellipsoidal coordinate system, the name and abbreviation of the horizontal axes in a WKT string shall follow the requirements in (ii). The vertical axis name shall be ‘ellipsoidal height’; the vertical axis abbreviation shall be ‘h’ and should be included when abbreviations for the horizontal axes are included.
  4.    For geodetic CRSs having a geocentric Cartesian coordinate system, in WKT strings the axis name should be omitted as it is given through the mandatory axis direction, see 7.5.4(iii), but the axis abbreviation, respectively ‘X’, ‘Y’ and ‘Z’, shall be given.
  5.    For projected CRSs, the two-dimensional Cartesian coordinate system axes names shall be ‘northing’ or ‘southing’ and ‘easting’ or ‘westing’ and shall be given when the axis direction and order are not east first, north second. Axis name may be omitted from WKT strings when the axis direction and order are east first, north second with abbreviations ‘E’ and ‘N’ respectively. Axis abbreviation shall be given.
  6.    For vertical CRSs, the axis direction is up or down, see 7.5.4. In WKT strings the value of axis name shall be ‘gravity-related height’ and ‘depth’ respectively. Axis abbreviation may be omitted but if given for height it shall not be ‘h’ (which is used for the ellipsoidal height component of an ellipsoidal 3D coordinate system, see 7.5.3(iii) above); the abbreviation for gravity-related height should normally be ‘H’.

Recommendations:

  1.    For engineering CRSs using a polar coordinate system where the lower case Greek letter θ is conventionally used as the symbol for direction, the letter ‘U’ from the Latin character set should be used as a one-character abbreviation in WKT strings.
  2.    For geodetic and engineering CRSs using a spherical coordinate system where the Greek letters φ and θ are conventionally used as the symbols for direction, the letters ‘U’ and ‘V’ respectively from the Latin character set should be used as a one-character abbreviations in WKT strings.

Axis direction

Axis direction indicates the positive increment along an axis. The handedness of a 2- or 3-dimensional coordinate system may be derived from the directions.

Requirement: the following constraints shall apply:

  1.     For geodetic CRSs having an ellipsoidal 2-D coordinate system, the two-dimensional ellipsoidal coordinate system axes are geodetic latitude, positive northwards, and geodetic longitude, positive eastwards. Axis direction shall be ‘north’ and ‘east’ respectively.
  2.     For geodetic CRSs having an ellipsoidal 3-D coordinate system, the three-dimensional ellipsoidal coordinate system axes are geodetic latitude, positive northwards, geodetic longitude, positive eastwards, and ellipsoidal height, positive upwards. Axis direction shall be ‘north’, ‘east’ and ‘up’ respectively.
  3.    For geodetic CRSs having a geocentric Cartesian coordinate system, in WKT strings the axis directions shall be ‘geocentricX’, ‘geocentricY’ and ‘geocentricZ’ respectively. The first axis of the earth-centred 3D Cartesian coordinate system lies in the equatorial plane such that a vector pointing in the positive direction passes through the intersection of the equator and the prime meridian. The second axis is in the equatorial plane such that a vector pointing in the positive direction passes through the intersection of the equator and the meridian of 90°E. The third axis is perpendicular to the first two such that it completes a right-handed coordinate system; it is approximately parallel to the earth’s rotation axis, positive towards the north pole.
  4.    For projected CRSs, except for coordinate systems centred on a pole, the axis direction shall be ‘north’ or ‘south’ and ‘east’ or ‘west’.

    For coordinate systems centred on a pole the direction for both axes will be ‘south’ (for the north pole case) or ‘north’ (for the south pole case); the axes direction shall be supplemented with a <meridian> description. This is the value of the meridian that the axis follows from the pole. The prime meridian from which the meridian value is reckoned is given through the <prime meridian> object; if no <prime meridian> object is in the WKT string then the IRM or Greenwich meridian shall be assumed.

  5.    For vertical CRSs, the axis direction shall be ‘up’ or ‘down’.
  6.    For temporal CRSs, the axis direction shall be ‘future’ or ‘past’.
  7.   In engineering CRSs the horizontal directions are only approximate, the set of directions indicating whether the coordinate system is left-handed or right-handed. (In the 2D case, the handedness is when viewed from above the plane of the system). For engineering CRSs with polar coordinate systems the direction of the rotational axis shall be ‘clockwise’ or ‘counterClockwise’. The specified direction from which the rotation is measured shall be given through the supplementary object <bearing>; the bearing value shall be given in the unit defined through <axis unit>.

See 6.5 for comment on case sensitivity.

NOTE        The requirements in 7.5.4, iv) for projected CRSs with a coordinate system centred on a pole and in 7.5.4, vi) for engineering CRSs with a polar coordinate system require the enumeration for <axis direction> in 7.5.1 to be an extended version of the codelist given in ISO 19111:2007, 9.4.

Axis order

Axis is repeated in a sequence. The number of axes in the sequence is the same as the dimensions of the coordinate system.

<axis order> identifies the order in which the coordinates of a point in a dataset are given and therefore is significant. In this International Standard it is defined in the BNF as an optional attribute to allow backward compatibility with OGC 01-009, however it is recommended that it should be explicitly included in a CRS WKT string.

Requirement:The following constraints shall apply:

  1. For coordinate systems with more than one axis, either every axis description shall include an <order> or none of the axes descriptions shall include an <order>. If <order> is included a sequence value shall not be repeated.
  2. When <axis order> is present in the WKT string the <axis> descriptions shall be ordered according to the axis order sequence.
  3. If <axis order> is omitted from the WKT string the sequence of <axis> descriptions shall imply the order of the axes and of coordinates referenced to the CRS.
  4. For compound CRSs, the axes are described through each component CRS description and the order values shall apply to each component system, not to the compound system. The order of the axes in the compound system shall be inferred from firstly the order of the component CRSs then secondly the order of axes within each component CRS.

EXAMPLE      A compound CRS consists of a projected CRS with a vertical CRS, the component CRSs described in that order. The axes of the projected CRS are northing first, easting second. The only and therefore first axis of the vertical CRS is gravity-related height. The axis order for the compound CRS is northing first, easting second and gravity-related height third.

Axis unit and coordinate system unit

This International Standard provides two methods for specifying the coordinate system axis units. <axis unit> is an optional attribute which may be applied to each axis description and if applied shall describe the unit for that axis. <cs unit> is an optional attribute which if applied shall specify the unit for all axes of the coordinate system.

Requirement:The following constraints shall apply:

  1. A CRS WKT string shall include either <axis unit> for each axis or <cs unit> applying to all axes.
  2. <cs unit> shall not be used if the unit does not apply to all axes. In these cases <axis unit> shall be used.

EXAMPLE 1          A polar polar coordinate system requires one axis to be an angle and the other axis to be a length.

EXAMPLE 2          A three-dimensional ellipsoidal coordinate system requires two axes (geodetic latitude and geodetic longitude) to be angles and the third axis (ellipsoidal height) to be a length.

For coordinate systems in which all axes have the same units, the use of <axis unit> leads to duplication of unit name and conversion factor. Duplication is avoided through the use of <cs unit>.

<axis unit> and <cs unit> are subsets of <unit> which is described in 7.4. <axis unit> or <cs unit> may also specify the unit for implied map projection parameter values, as described in 9.3.

Examples of WKT describing coordinate systems

Coordinate systems for geodetic CRSs

EXAMPLE 1      Earth centred earth fixed Cartesian CS. Axis order is implied, <cs unit> is used.

                   CS[Cartesian,3],
                     AXIS["(X)",geocentricX],
                     AXIS["(Y)",geocentricY],
                     AXIS["(Z)",geocentricZ],
                     LENGTHUNIT[“metre”,1.0]

EXAMPLE 2      Topocentric Cartesian CS. Axis order is implied, <cs unit> is used.

                   CS[Cartesian,3],
                     AXIS["(X)“,east],AXIS[”(Y)“,north],AXIS[”(Z)",up],
                     LENGTHUNIT[“metre”,1.0]

EXAMPLE 3      3D ellipsoidal CS. Axis order is explicit, <axis unit> is used, first two axes have name but no abbreviation.

                   CS[ellipsoidal,3],
                     AXIS[“latitude”,north,ORDER[1],ANGLEUNIT["degree",0.0174532925199433]],
                     AXIS[“longitude”,east,ORDER[2],ANGLEUNIT["degree",0.0174532925199433]],
                     AXIS[“ellipsoidal height (h)”,up,ORDER[3],LENGTHUNIT[“metre”,1.0]]

EXAMPLE 4      2D ellipsoidal CS. Axis order is implied, <cs unit> is used, axes have abbreviation but no name.

                   CS[ellipsoidal,2],
                     AXIS["(lat)",north],
                     AXIS["(lon)",east],
                     ANGLEUNIT["degree",0.0174532925199433]

EXAMPLE 5      Spherical CS. Axis order is explicit, <axis unit> is used, axes have name and abbreviation.

                   CS[spherical,3],
                     AXIS["distance (r)",awayFrom,ORDER[1],LENGTHUNIT[“kilometre”,1000]],
                     AXIS["longitude (U)",counterClockwise,BEARING[0],ORDER[2],
                       ANGLEUNIT[“degree”,0.0174532925199433]]
                     AXIS["elevation (V)",up,ORDER[3],
                       ANGLEUNIT[“degree”,0.0174532925199433]

Coordinate systems for projected CRSs

EXAMPLE 1 

      CS[Cartesian,2],
                 AXIS["(E)",east,ORDER[1],LENGTHUNIT[“metre”,1.0]],
                 AXIS["(N)",north,ORDER[2],LENGTHUNIT[“metre”,1.0]]         (using <axis unit>)

 

EXAMPLE 2 

      CS[Cartesian,2],
                 AXIS["(E)",east],
                 AXIS["(N)",north],
                 LENGTHUNIT[“metre”,1.0]]                                  (using <cs unit>)

 

EXAMPLE 3 

      CS[Cartesian,2],
                 AXIS["northing (X)",north,ORDER[1]],
                 AXIS["easting (Y)",east,ORDER[2]],
                 LENGTHUNIT["German legal metre",1.0000135965]

EXAMPLE 4      For an azimuthal projection centred on the north pole: 

               CS[Cartesian,2],
                 AXIS["easting (X)",south,
                   MERIDIAN[90,ANGLEUNIT[“degree”,0.0174532925199433]],
                   ORDER[1]],
                 AXIS["northing (Y)",south,
                   MERIDIAN[180,ANGLEUNIT[“degree”,0.0174532925199433]],
                   ORDER[2]],
                 LENGTHUNIT[“metre”,1.0]

Coordinate systems for vertical CRSs

EXAMPLE 1 

      CS[vertical,1],
                 AXIS["gravity-related height (H)",up],
                 LENGTHUNIT[“metre”,1.0]                                   (using <cs unit>)

EXAMPLE 2 

      CS[vertical,1],
                 AXIS["depth (D)",down,
                   LENGTHUNIT[“metre”,1.0]]                                (using <axis unit>)

Coordinate systems for engineering CRSs

EXAMPLE 1 

      CS[Cartesian,2],
                 AXIS["site north (x)",southeast,ORDER[1]],
                 AXIS["site east (y)",southwest,ORDER[2]],
                 LENGTHUNIT[“metre”,1.0]

EXAMPLE 2 

      CS[polar,2],
                 AXIS["distance (r)",awayFrom,ORDER[1],LENGTHUNIT[“metre”,1.0]],
                 AXIS["bearing (U)",clockwise,BEARING[234],ORDER[2],
                   ANGLEUNIT[“degree”,0.0174532925199433]]

EXAMPLE 3 

      CS[Cartesian,3],
                 AXIS["ahead (x)",forward,ORDER[1]],
                 AXIS["right (y)",starboard,ORDER[2]],
                 AXIS["down (z)",down,ORDER[3]],
                 LENGTHUNIT[“metre”,1.0]]

Coordinate systems for temporal CRSs

EXAMPLE         CS[temporal,1],AXIS[“time (t)”,future],TIMEUNIT[“second”,1.0]

8. WKT representation of geodetic coordinate reference systems

8.1 Overview

Requirement: The WKT representation of a geodetic coordinate reference system shall be:

<geodetic crs> ::= <geodetic crs keyword> <left delimiter> <crs name> <wkt separator> <geodetic datum> <wkt separator> <coordinate system> <scope extent identifier remark> <right delimiter>  
<geodetic crs keyword> ::= GEODCRS | GEODETICCRS !!  In this International Standard for brevity the preferred keyword is GEODCRS. GEODETICCRS is permitted. Implementations should be prepared to read both forms.  
<crs name> ::= <quoted Latin text>                                       !! See 7.2

<scope extent identifier remark> is described in 7.3.

8.2 Geodetic datum

Ellipsoid

The <ellipsoid> object is an attribute of <geodetic datum>. It is not used with other types of datum.

Requirement: The WKT representation of an ellipsoid shall be:

<ellipsoid> ::= <ellipsoid keyword> <left delimiter> <ellipsoid name> <wkt separator> <semi-major axis> <wkt separator> <inverse flattening> [ <wkt separator> <length unit> ]  [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<ellipsoid keyword> ::= ELLIPSOID | SPHEROID !!  In this International Standard the preferred keyword is ELLIPSOID. SPHEROID is permitted for backward compatibility. Implementations should be prepared to read both forms.
<ellipsoid name> ::= <quoted Latin text>                      !! See 7.2
<semi-major axis>    ::= <unsigned numeric literal>            !! See below for constraint
<inverse flattening>  ::= <unsigned numeric literal>            !! See below for constraint

ISO 19111:2007 allows an oblate ellipsoid to be defined through semi-major axis (a) and either semi-minor axis (b) or inverse flattening (1/f). If semi-minor axis is used as the second defining parameter the value for inverse flattening to be shown in the WKT string should be calculated from 1/f  =  a / (a – b).

ISO 19111:2007 also allows for the earth model to be a sphere, for which 1/f is infinite. In this International Standard if the earth model is a sphere <inverse flattening> shall be given an artificial value of zero.

Requirements:

  1.    The WKT representation of a sphere shall have an <inverse flattening> value of 0.
  2.    <length unit> is an optional attribute, optional for reasons of backward compatibility, but it is recommended that it is explicitly included in WKT strings. If it is omitted then the value for semi-major axis shall be given in metres. Conversely, if it is omitted then the value for the semi-major axis shall be assumed to be in metres. Its <conversion factor> shall be to metres and is the number of metres per unit. <length unit> is described in 7.4.

EXAMPLE 1  

    
    ELLIPSOID[“GRS 1980”,6378137,298.257222101,LENGTHUNIT[“metre”,1.0]]

EXAMPLE 2   

    (unit = metre is implied)
    SPHEROID[“GRS 1980”,6378137.0,298.257222101]

EXAMPLE 3 

    ELLIPSOID[“Clark 1866”,20925832.164,294.97869821,
    LENGTHUNIT[“US survey foot”,0.304800609601219]]

EXAMPLE 4  

    ELLIPSOID[“Sphere”,6371000,0,LENGTHUNIT[“metre”,1.0]]

The full requirements of planetary mapping are out of scope of ISO 19111. However a definition of WKT for a triaxial ellipsoid is given in informative Annex D.

Prime meridian

The prime meridian is the meridian with a value of zero longitude. The prime meridian is usually defined to be the international reference meridian which for the Earth passes near Greenwich, but this may not always be the case. The <prime meridian> object is conditional.

 

Requirements:

  1.    Prime meridian shall not be given for any type of datum and CRS other than geodetic.

    NOTE     For projected CRSs the prime meridian is inherited through the base geodetic CRS.

  2.    It shall be given if the CRS type is geodetic and the prime meridian is not the international reference meridian. It may be given if the CRS type is geodetic and the prime meridian is the international reference meridian.
  3.   Conversely if the CRS type is geodetic and prime meridian is not given, the prime meridian shall be assumed to be the international reference meridian.
  4.   The WKT representation of a prime meridian shall be:

<prime meridian> ::= <prime meridian keyword> <left delimiter> <prime meridian name> <wkt separator> <irm longitude> [ <wkt separator> <angle unit> ]  [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<prime meridian keyword> ::= PRIMEM | PRIMEMERIDIAN !!  In this International Standard the preferred keyword is PRIMEM for backward compatibility. PRIMEMERIDIAN is permitted. Implementations should be prepared to read both forms.
<prime meridian name> ::= <quoted Latin text>                                       !! See 7.2
<irm longitude> ::= <signed numeric literal> [ <wkt separator> <angle unit> ]

<irm longitude> is the longitude of the prime meridian measured from the international reference meridian, positive eastward.

<angle unit> is an optional attribute, optional for reasons of backward compatibility, but it is recommended that it is included in WKT strings. If it is omitted then the value for <irm longitude> shall be taken from the geodetic CRS axis unit. If the subtype of the geodetic CRS to which the prime meridian is an attribute is geographic, the prime meridian’s <irm longitude> value shall be given in the same angular units as those for the horizontal axes of the geographic CRS; if the geodetic CRS subtype is geocentric the prime meridian’s <irm longitude> value shall be given in degrees. Its <conversion factor> shall be to radians and is the number of radians per unit. <angle unit> is described in 7.4.

EXAMPLE 1      PRIMEM["Ferro",-17.6666667]             (taking the CRS axis unit of degrees)

EXAMPLE 2      PRIMEM["Paris",2.5969213]               (taking the CRS axis unit of grads)

EXAMPLE 3      PRIMEM["Paris",2.5969213,ANGLEUNIT[“grad”,0.015707963267949]]

EXAMPLE 4      PRIMEM["Greenwich",0.0]                 (taking the CRS axis unit of degrees)

NOTE        When the prime meridian name is “Greenwich” or the longitude of the international reference meridian in the geodetic CRS is zero, the inclusion of the prime meridian object in a WKT string is optional, so this example string should not normally be present. It is included here for backward compatibility reasons as the prime meridian object was mandatory in earlier CRS WKT specifications.

Datum

Requirement: The WKT representation of a geodetic datum shall be:

<geodetic datum>                          ::= <geodetic datum keyword> <left delimiter> <datum name> <wkt separator> <ellipsoid> [ <wkt separator> <datum anchor> ] [ { <wkt separator> <identifier> } ]…  <right delimiter> { <wkt separator> <prime meridian> }  
<geodetic datum keyword>                          ::= DATUM | GEODETICDATUM !! In this International Standard for compatibility with previous versions of WKT the preferred keyword is DATUM, but for consistency with the other datum types described in Clauses 10 to 14 GEODETICDATUM is permitted. Implementations should be prepared to read both forms.
<datum name> ::= <quoted Latin text>                                       !! See 7.2
<datum anchor> ::= <datum anchor keyword> <left delimiter> <datum anchor description> <right delimiter>  
<datum anchor keyword> ::= ANCHOR
<datum anchor description> ::= <quoted Latin text>

<geodetic datum> is used when the CRS type is geodetic. For a projected CRS, the geodetic datum is included in the Base Geodetic CRS, see Clause 9.

<ellipsoid> is described in 8.2.1.

<prime meridian> is a conditional attribute; see 8.2.2. Following the data model of ISO 19111 it would be nested within the geodetic datum object. In this International Standard its nesting follows previous versions of CRS WKT.

EXAMPLE 1 

      DATUM[“North American Datum 1983”,
                ELLIPSOID[“GRS 1980”,6378137,298.257222101,LENGTHUNIT[“metre”,1.0]]]

EXAMPLE 2 

    DATUM[“World Geodetic System 1984”,
                ELLIPSOID[“WGS 84”,6378388.0,298.257223563,LENGTHUNIT[“metre”,1.0]]],
              PRIMEM["Greenwich",0.0]

NOTE        When the prime meridian name is “Greenwich” or the longitude of the IRM meridian in the geodetic CRS is zero, the inclusion of the prime meridian object in a WKT string is optional, so this example string may omit the prime meridian object, as shown in example 1.

 

EXAMPLE 3  

   DATUM[“Tananarive 1925”,
                ELLIPSOID[“International 1924”,6378388.0,297.0,
                  LENGTHUNIT[“metre”,1.0]],
                ANCHOR[“Tananarive observatory:21.0191667gS, 50.23849537gE (of Paris)”]],
                PRIMEM[“Paris”,2.5969213,ANGLEUNIT[“grad”,0.015707963267949]]

8.3 Coordinate systems for geodetic CRSs

<coordinate system> is described in 7.5. Several constraints and recommendations for coordinate systems used in geodetic CRSs are described there.

8.4 Examples of WKT describing a geodetic CRS

EXAMPLE 1      Geodetic CRS with Cartesian coordinate system

   GEODETICCRS[“JGD2000”,
     DATUM[“Japanese Geodetic Datum 2000”,
       ELLIPSOID[“GRS 1980”,6378137,298.257222101]],
     CS[Cartesian,3],
       AXIS["(X)",geocentricX],
       AXIS["(Y)",geocentricY],
       AXIS["(Z)",geocentricZ],
       LENGTHUNIT[“metre”,1.0],
     SCOPE["Geodesy, topographic mapping and cadastre"],
     AREA[“Japan”],
     BBOX[17.09,122.38,46.05,157.64],
     TIMEEXTENT[2002-04-01,2011-10-21],
     ID[“EPSG”,4946,URI[“urn:ogc:def:crs:EPSG::4946”]],
     REMARK["注：JGD2000ジオセントリックは現在JGD2011に代わりました。"]]

NOTE        Non-Latin characters may only be included within remarks.

 

EXAMPLE 2      Geodetic CRS with ellipsoidal 3D coordinate system, no optional attributes

   GEODCRS[“WGS 84”,
     DATUM[“World Geodetic System 1984”,
       ELLIPSOID[“WGS 84”,6378137,298.257223563,
         LENGTHUNIT[“metre”,1.0]]],
     CS[ellipsoidal,3],
       AXIS["(lat)“,north,ANGLEUNIT[”degree",0.0174532925199433]],
       AXIS["(lon)“,east,ANGLEUNIT[”degree",0.0174532925199433]],
       AXIS[“ellipsoidal height (h)”,up,LENGTHUNIT[“metre”,1.0]]]

 

EXAMPLE 3      Geodetic CRS with IRM as prime meridian and ellipsoidal 2D coordinate system in degrees

    GEODCRS[“NAD83”,
     DATUM[“North American Datum 1983”,
       ELLIPSOID[“GRS 1980”,6378137,298.257222101,LENGTHUNIT[“metre”,1.0]]],
     CS[ellipsoidal,2],
       AXIS[“latitude”,north],
       AXIS[“longitude”,east],
       ANGLEUNIT[“degree”,0.017453292519943],
     ID[“EPSG”,4269],
     REMARK[“1986 realisation”]]

 

EXAMPLE 4      Geodetic CRS with prime meridian other than IRM and ellipsoidal 2D coordinate system in grads

    GEODCRS[“NTF (Paris)”,
     DATUM[“Nouvelle Triangulation Francaise”,
       ELLIPSOID[“Clarke 1880 (IGN)”,6378249.2,293.4660213]],
     PRIMEM[“Paris”,2.5969213],
     CS[ellipsoidal,2],
       AXIS[“latitude”,north,ORDER[1]],
       AXIS[“longitude”,east,ORDER[2]],
       ANGLEUNIT[“grad”,0.015707963267949],
     REMARK[“Nouvelle Triangulation Française”]]

NOTE:       Non-Latin characters may only be included within remarks

9. WKT representation of projected CRSs

9.1 Overview

A projected CRS is a special case of a derived CRS. Because of its importance to geographic information and particularly for backward compatibility reasons necessitating a different string structure it is treated separately from the general case described in Clause 15. The structures of WKT strings for principal and derived CRSs are compared in 15.1, to which the reader is referred. 

Requirement: The WKT representation of a projected coordinate reference system shall be:

<projected crs> ::= <projected crs keyword> <left delimiter> <crs name> <wkt separator> <base geodetic crs> <wkt separator> <map projection> <wkt separator> <coordinate system> <scope extent identifier remark> <right delimiter>  
<projected crs keyword> ::= PROJCRS | PROJECTEDCRS !!  In this International Standard for brevity the preferred keyword is PROJCRS. PROJECTEDCRS is permitted. Implementations should be prepared to read both forms.  
<crs name> ::= <quoted Latin text>                                       !! See 7.2

 

9.2 Base CRS

General

Requirement: The WKT representation of a projected coordinate reference system’s base geodetic CRS shall be:

<base geodetic crs> ::= <base geodetic crs keyword> <left delimiter> <base crs name> <wkt separator> <geodetic datum> [ <wkt separator> <ellipsoidal cs unit> ] <right delimiter>  
<base geodetic crs keyword> ::= BASEGEODCRS
<base crs name> ::= <quoted Latin text>                                       !! See 7.2
<ellipsoidal cs unit> ::= <angle unit>

<geodetic datum> is described in 8.2. It includes ellipsoid and prime meridian descriptions.

Ellipsoidal CS unit

The base geodetic CRS <ellipsoidal cs unit> is that in which geodetic latitude and longitude would be quoted in the geodetic CRS. It is defined as an optional attribute for backward compatibility reasons (see 9.3).

<angle unit> is described in 7.4.

Requirement: The base geodetic CRS <ellipsoidal cs unit> shall be included in projected CRS WKT strings when the units of the map projection angular parameters are not explicitly given within those parameters.

Recommendation: The units of the map projection angular parameters should be explicitly included in the projected CRS WKT string and when this is done the base geodetic CRS <ellipsoidal cs unit> should not be included in the string.

9.3 Map projection

Introduction

Map projection is a specialised subset of coordinate operation (see 17.1) in which the source and target CRSs are by definition the base geodetic CRS and the projected CRS respectively; these are therefore implied rather than explicitly stated in the WKT string. Additionally, for reasons of backward compatibility, in map projections the parameter units may be implied.

Requirement: The WKT representation of a map projection shall be:

 

<map projection> ::= <map projection keyword> <left delimiter> <map projection name> <wkt separator> <map projection method> { <wkt separator> <map projection parameter> }… [ { <wkt separator> <identifier> } ]… <right delimiter>  
<map projection keyword> ::= CONVERSION
<map projection name> ::= <quoted Latin text>                                       !! See 7.2
<map projection method> ::= <map projection method keyword> <left delimiter> <map projection method name>  [ { <wkt separator> <identifier> } ]… <right delimiter>  
<map projection method keyword> ::= METHOD | PROJECTION !! In this International Standard the preferred keyword is METHOD. PROJECTION is permitted for backward compatibility. Implementations should be prepared to read both forms.
<map projection method name>  ::= <quoted Latin text>                                       !! See 7.2
<map projection parameter> ::= <parameter keyword>  <left delimiter> <parameter name> <wkt separator> <parameter value> [ <wkt separator> <map projection parameter unit> ] [ { <wkt separator> <identifier> } ]… <right delimiter>  
<parameter keyword>  ::= PARAMETER
<parameter name>  ::= <quoted Latin text>                                       !! See 7.2
<parameter value> ::= <signed numeric literal>
<map projection parameter unit> ::= <length unit> | <angle unit> | <scale unit> !! See 9.3.4 for constraints

 

EXAMPLE 1       Identifier given for the method and each parameter.

              CONVERSION["UTM zone 10N",
                METHOD["Transverse Mercator",ID[“EPSG”,9807]],
                PARAMETER["Latitude of natural origin",0,
                  ANGLEUNIT["degree",0.0174532925199433],
                  ID[“EPSG”,8801]],
                PARAMETER["Longitude of natural origin",-123,
                  ANGLEUNIT["degree",0.0174532925199433],ID[“EPSG”,8802]],
                PARAMETER["Scale factor at natural origin",0.9996,
                  SCALEUNIT["unity",1.0],ID[“EPSG”,8805]],
                PARAMETER["False easting",500000,
                  LENGTHUNIT["metre",1.0],ID[“EPSG”,8806]],
                PARAMETER["False northing",0,LENGTHUNIT["metre",1.0],ID[“EPSG”,8807]]]

 

EXAMPLE 2    Identifier given for conversion as a whole.

              CONVERSION["UTM zone 10N",
                METHOD["Transverse Mercator"],
                PARAMETER["Latitude of natural origin",0,
                  ANGLEUNIT["degree",0.0174532925199433]],
                PARAMETER["Longitude of natural origin",-123,
                  ANGLEUNIT["degree",0.0174532925199433]],
                PARAMETER["Scale factor at natural origin",0.9996,
                  SCALEUNIT["unity",1.0]],
                PARAMETER["False easting",500000,LENGTHUNIT["metre",1.0]],
              PARAMETER["False northing",0,LENGTHUNIT["metre",1.0]],
                ID[“EPSG”,16010]]

Further examples are included in 9.5.

Map projection name and identifier

Map projection (zone) encompasses the collection of method and parameter values. Its name is for human readability. Depending upon the naming convention in use it may also be included as part of the projected CRS name.

<identifier> is described in 7.3.4. It is an optional attribute. If an identifier is provided as an attribute within the <map projection conversion> object, because it is expected to describe a complete collection of zone name, method, parameters and parameter values, it shall override any identifiers given within the map projection method and map projection parameter objects.

Map projection method

Method name is for human readability. For interoperability it is the method formula that is critical in determining the equivalence of methods; this may be given through a map projection method <identifier>.

<identifier> is described in 7.3.4. It is an optional attribute. However if an identifier is included as an attribute within the <map projection conversion> object (9.3.1), it will take precedence over any identifier within the map projection method object.

If a map projection method <identifier> is not given, the WKT description is potentially ambiguous, relying on interpretation of method name. It is recommended that a map projection conversion identifier or a map projection method identifier is included in WKT strings. Identifiers for commonly encountered map projection methods are given in E.2.

Map projection parameter

Parameter name is for human readability. For interoperability it is the method formula and its parameters that are critical in determining the equivalence of methods. See Annex E. Identifiers for commonly encountered map projection methods are given in E.2; their parameters are listed in E.3.

The map projection parameters required are specific to the map projection method and will be listed sequentially. The order within the sequence is not significant but should be logical.

<map projection parameter unit> is an optional attribute for reasons of backward compatibility. It is recommended that it is included explicitly in WKT strings. If omitted then:

 

Requirements: If <map projection parameter unit> is omitted from the <map projection parameter>s a CRS WKT string then:

  1.  Map parameter values that are lengths shall be given in the unit for the projected CRS axes.
  2.  Map projection parameter values that are angles shall be given in the unit for the base geographic CRS of the projected CRS; sexagesimal degree representations shall be given as decimal values.
  3.  Map projection parameters that are unitless (for example scale factor) shall be given as a number which is close to or is unity (1.0).

The parameter unit type is included in E.3.

<identifier> is described in 7.3.4. It is an optional attribute. If an identifier is included as an attribute within the map projection conversion object (9.3.1) or map projection method object (9.3.3), it will take precedence over any identifier within the map projection parameter object.

9.4 Coordinate systems for projected CRSs

<coordinate system> is described in 7.5. Several constraints and recommendations for coordinate systems used in projected CRSs are described there.

9.5 Examples of WKT describing a projected CRS

EXAMPLE 1    

PROJCRS["ETRS89 Lambert Azimuthal Equal Area CRS",  BASEGEODCRS["ETRS89",
     DATUM["ETRS89",
       ELLIPSOID[“GRS 80”,6378137,298.257222101,LENGTHUNIT[“metre”,1.0]]]],
   CONVERSION[“LAEA”,
     METHOD["Lambert Azimuthal Equal Area",ID[“EPSG”,9820]],
     PARAMETER[“Latitude of origin”,52.0,
       ANGLEUNIT[“degree”,0.0174532925199433]],
     PARAMETER[“Longitude of origin”,10.0,
      ANGLEUNIT[“degree”,0.0174532925199433]],
     PARAMETER[“False easting”,4321000.0,LENGTHUNIT[“metre”,1.0]],
     PARAMETER[“False northing”,3210000.0,LENGTHUNIT[“metre”,1.0]]],
   CS[Cartesian,2],
     AXIS["(Y)",north,ORDER[1]],
     AXIS["(X)",east,ORDER[2]],
     LENGTHUNIT[“metre”,1.0],
   SCOPE[“Description of a purpose”],
   AREA[“An area description”],
   ID[“EuroGeographics”,"ETRS-LAEA"]]

EXAMPLE 2  

  PROJCRS["NAD27 / Texas South Central",
   BASEGEODCRS["NAD27",
     DATUM[“North American Datum 1927”,
       ELLIPSOID[“Clarke 1866”,20925832.164,294.97869821,
         LENGTHUNIT[“US survey foot”,0.304800609601219]]]],
   CONVERSION["Texas South Central SPCS27",
     METHOD["Lambert Conic Conformal (2SP)“,ID[”EPSG",9802]],
     PARAMETER[“Latitude of false origin”,27.83333333333333,
      ANGLEUNIT[“degree”,0.0174532925199433],ID[“EPSG”,8821]],
     PARAMETER[“Longitude of false origin”,-99.0,
       ANGLEUNIT[“degree”,0.0174532925199433],ID[“EPSG”,8822]],
     PARAMETER[“Latitude of 1st standard parallel”,28.383333333333,
      ANGLEUNIT[“degree”,0.0174532925199433],ID[“EPSG”,8823]],
     PARAMETER[“Latitude of 2nd standard parallel”,30.283333333333,
      ANGLEUNIT[“degree”,0.0174532925199433],ID[“EPSG”,8824]],
     PARAMETER[“Easting at false origin”,2000000.0,
       LENGTHUNIT[“US survey foot”,0.304800609601219],ID[“EPSG”,8826]],
     PARAMETER[“Northing at false origin”,0.0,
       LENGTHUNIT[“US survey foot”,0.304800609601219],ID[“EPSG”,8827]]],
   CS[Cartesian,2],
     AXIS["(X)",east],
     AXIS["(Y)",north],
     LENGTHUNIT[“US survey foot”,0.304800609601219],
   REMARK[“Fundamental point: Meade’s Ranch KS, latitude 39°13’26.686”"N,
   longitude 98°32’30.506“”W."]]

EXAMPLE 3 

     PROJCRS[“NAD83 UTM 10”,
     BASEGEODCRS[“NAD83(86)”,
       DATUM[“North American Datum 1983”,
         ELLIPSOID[“GRS 1980”,6378137,298.257222101]],         (default length unit is metre)
       ANGLEUNIT[“degree”,0.0174532925199433]],                (for angular parameter units)
       PRIMEM[“Greenwich”,0],
     CONVERSION[“UTM zone 10N”,ID[“EPSG”,16010],
       METHOD[“Transverse Mercator”],
       PARAMETER[“Latitude of natural origin”,0.0],            (unit taken from base CRS)
       PARAMETER[“Longitude of natural origin”,-123.0],        (unit taken from base CRS)
       PARAMETER[“Scale factor”,0.9996],                       (unit conversion is to unity)
       PARAMETER[“False easting”,500000.0],                    (unit taken from CS axis)
       PARAMETER[“False northing”,0.0]],                       (unit taken from CS axis)
     CS[Cartesian,2],
       AXIS["(E)",east,ORDER[1]],
       AXIS["(N)",north,ORDER[2]],
       LENGTHUNIT[“metre”,1.0],                                (for linear parameter units)
     REMARK[“In this example units are implied. This is allowed for backward compatibility. 
             It is recommended that units are explicitly given in the string, i
             as in the previous two examples.”]]

 

NOTE        This example is included for backwards compatibility to show the implicit description of parameter units. It is recommended that units are explicitly given in the string, as in the previous two examples.

10. WKT representation of vertical CRSs

10.1 Overview

Requirement: The WKT representation of a vertical coordinate reference system shall be:

<vertical crs> ::= <vertical crs keyword> <left delimiter> <crs name> <wkt separator> <vertical datum> <wkt separator> <coordinate system> <scope extent identifier remark> <right delimiter>  
<vertical crs keyword> ::= VERTCRS | VERTICALCRS !!  In this International Standard for brevity the preferred keyword is VERTCRS. VERTICALCRS is permitted. Implementations should be prepared to read both forms.  
<crs name> ::= <quoted Latin text>                                       !! See 7.2

<scope extent identifier remark> is described in 7.3.

10.2 Vertical datum

Requirement: The WKT representation of a vertical datum shall be:

<vertical datum> ::= <vertical datum keyword> <left delimiter> <datum name> [ <wkt separator> <datum anchor> ] [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<vertical datum keyword> ::= VDATUM | VERTICALDATUM !! In this International Standard for brevity the preferred keyword is VDATUM, but VERTICALDATUM is permitted. Implementations should be prepared to read both forms.
<datum name> ::= <quoted Latin text>                                       !! See 7.2
<datum anchor> ::= <datum anchor keyword> <left delimiter> <datum anchor description> <right delimiter>  
<datum anchor keyword> ::= ANCHOR
<datum anchor description> ::= <quoted Latin text>

EXAMPLE 1      VDATUM[“Newlyn”]

EXAMPLE 1      VERTICALDATUM[“Newlyn”,ANCHOR[“Mean Sea Level 1915 to 1921.”]]

10.3 Vertical coordinate system

<coordinate system> is described in 7.5. Several constraints and recommendations for coordinate systems used in vertical CRSs are described there.

10.4 Example of WKT describing a vertical CRS

EXAMPLE         VERTCRS[“NAVD88”,

     VDATUM[“North American Vertical Datum 1988”],
     CS[vertical,1],
       AXIS["gravity-related height (H)“,up],LENGTHUNIT[”metre",1.0]]

11. WKT representation of engineering CRSs

11.1 Overview

Requirement: The WKT representation of an engineering coordinate reference system shall be:

<engineering crs> ::= <engineering crs keyword> <left delimiter> <crs name> <wkt separator> <engineering datum> <wkt separator> <coordinate system> <scope extent identifier remark> <right delimiter>  
<engineering crs keyword> ::= ENGCRS | ENGINEERINGCRS !!  In this International Standard for brevity the preferred keyword is ENGCRS. ENGINEERINGCRS is permitted. Implementations should be prepared to read both forms.  
<crs name> ::= <quoted Latin text>                                       !! See 7.2

<scope extent identifier remark> is described in 7.3.

11.2 Engineering datum

Requirement: The WKT representation of an engineering datum shall be:

<engineering datum> ::= <engineering datum keyword> <left delimiter> <datum name> [ <wkt separator> <datum anchor> ] [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<engineering datum keyword> ::= EDATUM | ENGINEERINGDATUM !! In this International Standard for brevity the preferred keyword is EDATUM, but ENGINEERINGDATUM is permitted. Implementations should be prepared to read both forms.
<datum name> ::= <quoted Latin text>                                       !! See 7.2
<datum anchor> ::= <datum anchor keyword> <left delimiter> <datum anchor description> <right delimiter>  
<datum anchor keyword> ::= ANCHOR
<datum anchor description> ::= <quoted Latin text>

11.3 Coordinate systems for engineering CRSs

<coordinate system> is described in 7.5. Several constraints and recommendations for coordinate systems used in engineering CRSs are described there.

11.4 Examples of WKT describing an engineering CRS

EXAMPLE 1      ENGCRS[“A construction site CRS”,

     EDATUM[“P1”,ANCHOR[“Peg in south corner”]],
     CS[Cartesian,2],
       AXIS[“site east”,southWest,ORDER[1]],
       AXIS[“site north”,southEast,ORDER[2]],
       LENGTHUNIT[“metre”,1.0],
     TIMEEXTENT[“date/time t1”,“date/time t2”]]

 

EXAMPLE 2    ENGINEERINGCRS[“Astra Minas Grid”,

     ENGINEERINGDATUM[“Astra Minas”],
     CS[Cartesian,2],
       AXIS["northing (X)",north,ORDER[1]],
       AXIS["westing (Y)",west,ORDER[2]],
       LENGTHUNIT[“metre”,1.0],
     ID[“EPSG”,5800]]

 

EXAMPLE 3      ENGCRS[“A ship-centred CRS”,

     EDATUM[“Ship reference point”,ANCHOR[“Centre of buoyancy”]],
     CS[Cartesian,3],
       AXIS["(x)",forward],
       AXIS["(y)",starboard],
       AXIS["(z)",down],
       LENGTHUNIT[“metre”,1.0]]

12. WKT representation of image CRSs

12.1 Overview

Requirement: The WKT representation of an image coordinate reference system shall be:

<image crs> ::= <image crs keyword> <left delimiter> <crs name> <wkt separator> <image datum> <wkt separator> <coordinate system> <scope extent identifier remark> <right delimiter>  
<image crs keyword> ::= IMAGECRS  
<crs name> ::= <quoted Latin text>                                       !! See 7.2

<scope extent identifier remark> is described in 7.3.

12.2 Image datum

Requirement: The WKT representation of an image datum shall be:

<image datum> ::= <image datum keyword> <left delimiter> <datum name> <wkt separator> <pixelincell> [ <wkt separator> <datum anchor> ] [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<image datum keyword> ::= IDATUM | IMAGEDATUM !! In this International Standard for brevity the preferred keyword is IDATUM, but IMAGEDATUM is permitted. Implementations should be prepared to read both forms.  
<datum name> ::= <quoted Latin text>                                       !! See 7.2
<pixelincell> ::= cellCentre | cellCenter | cellCorner
<datum anchor> ::= <datum anchor keyword> <left delimiter> <datum anchor description> <right delimiter>  
<datum anchor keyword> ::= ANCHOR
<datum anchor description> ::= <quoted Latin text>

12.3 Coordinate systems for image CRSs

<coordinate system> is described in 7.5. Several constraints and recommendations for coordinate systems used in image CRSs are described there.

13. WKT representation of parametric CRSs

13.1 Overview

Requirement: The WKT representation of a parametric coordinate reference system shall be:

<parametric crs> ::= <parametric crs keyword> <left delimiter> <crs name> <wkt separator> <parametric datum> <wkt separator> <coordinate system> <scope extent identifier remark> <right delimiter>  
<parametric crs keyword> ::= PARAMETRICCRS
<crs name> ::= <quoted Latin text>                                       !! See 7.2

<scope extent identifier remark> is described in 7.3.

13.2 Parametric datum

Requirement: The WKT representation of a parametric datum shall be:

<parametric datum> ::= <parametric datum keyword> <left delimiter> <datum name> [ <wkt separator> <datum anchor> ] [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<parametric datum keyword> ::= PDATUM | PARAMETRICDATUM !! In this International Standard for brevity the preferred keyword is PDATUM, but PARAMETRICLDATUM is permitted. Implementations should be prepared to read both forms.
<datum name> ::= <quoted Latin text>                                       !! See 7.2
<datum anchor> ::= <datum anchor keyword> <left delimiter> <datum anchor description> <right delimiter>  
<datum anchor keyword> ::= ANCHOR
<datum anchor description> ::= <quoted Latin text>

13.3 Parametric coordinate system

<coordinate system> is described in 7.5. Several constraints and recommendations for coordinate systems used in parametric CRSs are described there.

13.4 Example of WKT describing a parametric CRS

EXAMPLE 

         PARAMETRICCRS[“WMO standard atmosphere layer 0”,
               PDATUM["Mean Sea Level“,ANCHOR[”1013.25 hPa at 15°C"]],
               CS[parametric,1],
               AXIS["pressure (hPa)“,up],PARAMETRICUNIT[”HectoPascal",100.0]]

14. WKT representation of temporal CRSs

14.1 Overview

Requirement: The WKT representation of a temporal coordinate reference system shall be:

<temporal crs> ::= <temporal crs keyword> <left delimiter> <crs name> <wkt separator> <temporal datum> <wkt separator> <coordinate system> <scope extent identifier remark> <right delimiter>  
<temporal crs keyword> ::= TIMECRS
<crs name> ::= <quoted Latin text>                                       !! See 7.2

<scope extent identifier remark> is described in 7.3.

14.2 Temporal datum

Requirement: The WKT representation of a temporal datum shall be:

<temporal datum> ::= <temporal datum keyword> <left delimiter> <datum name> [ <wkt separator> <temporal origin> ] [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<temporal datum keyword> ::= TDATUM | TIMEDATUM !! In this International Standard for brevity the preferred keyword is TDATUM, but TIMEDATUM is permitted. Implementations should be prepared to read both forms.
<datum name> ::= <quoted Latin text>                                       !! See 7.2
<temporal origin > ::= <temporal origin keyword> <left delimiter> <temporal origin description> <right delimiter>  
<temporal origin keyword> ::= TIMEORIGIN
<temporal origin description> ::= <datetime> | <quoted Latin text>

14.3 Temporal coordinate system

<coordinate system> is described in 7.5. Several constraints and recommendations for coordinate systems used in temporal CRSs are described there.

14.4 Example of WKT describing a temporal CRS

EXAMPLE   

       TIMECRS[“GPS Time”,
                  TDATUM[“Time origin”,TIMEORIGIN[1980-01-01T00:00:00.0Z]],
                  CS[temporal,1],AXIS[“time”,future],TIMEUNIT[“day”,86400.0]]

 

15. WKT representation of derived CRSs

15.1 Overview

ISO 19111:2007 includes a modelling concept of a Derived CRS. A Derived CRS is a CRS which cannot exist in its own right but is defined through a coordinate conversion from another coordinate reference system.

A projected CRS is a special case of a derived CRS. Because of its importance to geographic information and particularly for backward compatibility reasons necessitating a different string structure it is treated separately from the general case and is described in Clause 9.

NOTE        Georeferenced image coordinates are not referenced to a derived CRS but to an image CRS. The georeferencing is accomplished through a coordinate transformation between the image CRS and the (usually geodetic or projected) CRS to which the image is georeferenced.

This International Standard implements this modelling concept through the inclusion of a ‘base CRS’ description within the description of the CRS. Table 3 compares the general structure of WKT for the principal CRS types described in Clauses 8 and 10 through 14 with the general structure of WKT for a Derived CRS.

Table : Comparison of general structure of WKT for principal and derived CRSs
Structure for principal CRSs Structure for Derived CRSs
a)    keyword a)    keyword
b)    name b)    name
c)    datum c)    Base CRS including its datum
d)    conversion
d)    coordinate system e)    coordinate system
e)    optional metadata f)    optional metadata

 

In Derived CRSs the Base CRS detail includes the name and datum of the Base CRS from which the Derived CRS is derived but not the coordinate system detail or optional metadata detail for that Base CRS, and the conversion is a special case of coordinate conversion described in Clause 17.

15.2 Derived CRS conversion

Introduction

The conversion in a derived CRS is a specialised subset of coordinate operation (see 17.1) in which the source and target CRSs are by definition the Base CRS and the Derived CRS respectively; these are therefore implied rather than explicitly stated in the WKT string. Attributes required for coordinate transformations but not coordinate conversions are also not relevant and are excluded from the deriving conversion WKT string. A map projection (see 9.3) is a particular case of a deriving conversion.

Requirement: The WKT representation of a <deriving conversion> shall be:

<deriving conversion >   ::= <deriving conversion keyword> <left delimiter> <deriving conversion name> <wkt separator> <operation method> { <wkt separator> <operation parameter> | <operation parameter file> }…  [ { <wkt separator> <identifier> } ]… <right delimiter>  
<deriving conversion keyword> ::= DERIVINGCONVERSION
<deriving conversion name> ::= <quoted Latin text>                                       !! See 7.2

Operation method, operation parameter and operation parameter file are described in 15.2.2 through 15.2.4 and are identical to that in 17.2.3 through 17.2.5. Identifier is described in 7.3.4.

Derived CRS conversion method

Requirement: The WKT representation of a derived CRS conversion method shall be:

<operation method> ::= <operation method keyword> <left delimiter> <operation method name> [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<operation method keyword> ::= METHOD
<operation method name> ::= <quoted Latin text>                                       !! See 7.2

Method name is for human readability. For interoperability it is the method formula that is critical in determining the equivalence of methods; this may be given through an operation method <identifier>.

<identifier> is described in 7.3.4. It is an optional attribute. If an identifier is included as an attribute within the derived CRS conversion object (15.2.1), it shall take precedence over any identifier within the operation method object.

If an <identifier> is omitted for both derived CRS conversion and derived CRS conversion method, the WKT description is potentially ambiguous, relying on interpretation of method name. It is recommended that either a derived CRS conversion identifier or a derived CRS conversion method identifier is included in WKT strings. Identifiers for commonly encountered coordinate transformation methods are given in E.4.

Derived CRS conversion parameter

Requirement: The WKT representation of a derived CRS conversion parameter shall be:

<operation parameter> ::= <parameter keyword>  <left delimiter> <parameter name> <wkt separator><parameter value> <wkt separator> <parameter unit>  [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<parameter keyword>  ::= PARAMETER
<parameter name> ::= <quoted Latin text>                                       !! See 7.2
<parameter value> ::= <signed numeric literal>
<parameter unit> ::= <length unit> | <angle unit> | <scale unit> | <time unit> | <parametric unit>

Units are described in 7.4.

Parameter name is for human readability. For interoperability it is the method formula and its parameters that are critical in determining the equivalence of methods. See Annex E. Identifiers for commonly encountered coordinate operation methods and their parameters are given in E.4; the parameters are listed in E.5. The coordinate operation parameters required are specific to the coordinate operation method and are listed sequentially. The order within the sequence is not significant but should be logical. Implementations should be prepared to read any order. For those methods included in Annex E the parameter order given in E.4 is recommended.

Requirements:

  1.    In derived CRS conversion WKT strings <parameter value>s shall be given in the sense Base CRS to Derived CRS. If the parameter unit is linear its conversion factor shall be to metres and is the number of metres per unit. If the parameter unit is angular its conversion factor shall be to radians and is the number of radians per unit. If the parameter is a scaling unit the conversion factor shall be to unity, for example parts per million (ppm) shall be given as 10-6. For commonly-encountered parameters the parameter type is included in E.5.
  2.    <identifier> is described in 7.3.4. It is an optional attribute. If an identifier is included as an attribute within the derived CRS conversion object (15.2.1) or coordinate operation method object (15.2.2), it shall take precedence over any identifier within the derived CRS conversion parameter object.

Derived CRS conversion parameter file

Requirement: The WKT representation of a derived CRS conversion parameter file shall be:

<operation parameter file> ::= <parameter file keyword> <left delimiter> <parameter name> <wkt separator> <parameter file name>  [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<parameter file keyword> ::= PARAMETERFILE
<parameter name> ::= <quoted Latin text>                                       !! See 7.2
<parameter file name> ::= <quoted Latin text>

For <parameter name> and <identifier> the requirements given in 15.2.3 shall apply.

Derived CRS conversion example

EXAMPLE         

          DERIVINGCONVERSION["conversion name",
                METHOD["method name",
                  ID[“authority”,123]],
                PARAMETER["parameter 1 name",0,
                  ANGLEUNIT["degree",0.0174532925199433],
                  ID[“authority”,456]],
                PARAMETER["parameter 2 name",-123,
                  ANGLEUNIT["degree",0.0174532925199433],
                  ID[“authority”,789]]]

 

15.3 Derived CRS of type geodetic

Representation

Requirement: The WKT representation of a derived geodetic coordinate reference system shall be:

<derived geodetic crs> ::= <geodetic crs keyword> <left delimiter> <derived crs name> <wkt separator> <base geodetic crs> <wkt separator> <deriving conversion> <wkt separator> <coordinate system> <scope extent identifier remark> <right delimiter>  
<geodetic crs keyword> ::= GEODCRS | GEODETICCRS          !! See 8.1
<derived crs name> ::= <quoted Latin text>                                       !! See 7.2
<base geodetic crs> ::= <base geodetic crs keyword> <left delimiter> <base crs name> <wkt separator> <geodetic datum> [ <wkt separator> <ellipsoidal cs unit> ] <right delimiter> !! <ellipsoidal cs unit> is an optional attribute included in the definition of <base geodetic crs> for projected CRS backward compatibility reasons. It may be given when the derived CRS type is a projected CRS (see Clause 9) but when, as here, the derived CRS type is geodetic it should not be given.  
<base geodetic crs keyword> ::= BASEGEODCRS
<base crs name> ::= <quoted Latin text>                                       !! See 7.2

<coordinate system> is described in 7.5; the constraints for geodetic CRSs apply to geodetic derived CRSs.

<geodetic datum> is described in 8.2; it includes ellipsoid and prime meridian descriptions.

<deriving conversion> is described in 15.2,  <scope extent identifier remark> in 7.3.

Example of WKT describing a derived geodetic CRS

EXAMPLE         Derived geodetic CRS with rotated pole

   GEODCRS["ETRS89 Lambert Azimuthal Equal Area CRS",
     BASEGEODCRS["WGS 84",
       DATUM["WGS 84",
         ELLIPSOID[“WGS 84”,6378137,298.2572236,LENGTHUNIT[“metre”,1.0]]]],
     DERIVINGCONVERSION[“Atlantic pole”,
       METHOD["Pole rotation",ID[“Authority”,1234]],
       PARAMETER[“Latitude of rotated pole”,52.0,
         ANGLEUNIT[“degree”,0.0174532925199433]],
       PARAMETER[“Longitude of rotated pole”,-30.0,
        ANGLEUNIT[“degree”,0.0174532925199433]],
       PARAMETER[“Axis rotation”,-25.0,
        ANGLEUNIT[“degree”,0.0174532925199433]]],
     CS[ellipsoidal,2],
       AXIS[“latitude”,north,ORDER[1]],
       AXIS[“longitude”,east,ORDER[2]],
       ANGLEUNIT[“degree”,0.0174532925199433]]

 

15.4 Derived CRS of type vertical

Requirement: The WKT representation of a derived vertical coordinate reference system shall be:

<derived vertical crs> ::= <vertical crs keyword> <left delimiter> <derived crs name> <wkt separator> <base vertical crs> <wkt separator> <deriving conversion> <wkt separator> <coordinate system> <scope extent identifier remark> <right delimiter>  
<vertical crs keyword> ::= VERTCRS | VERTICALCRS           !! See 10.1
<derived crs name> ::= <quoted Latin text>                                       !! See 7.2
<base vertical crs> ::= <base vertical crs keyword> <left delimiter> <base crs name> <wkt separator> <vertical datum> <right delimiter>  
<base vertical crs keyword> ::= BASEVERTCRS
<base crs name> ::= <quoted Latin text>                                       !! See 7.2

<coordinate system> is described in 7.5; the constraints for vertical CRSs apply to vertical derived CRSs.

<vertical datum> is described in 10.2, <deriving conversion> in 15.2 and <scope extent identifier remark> in 7.3.

15.5 Derived CRS of type engineering

Representation

Requirement: The WKT representation of a derived geodetic coordinate reference system shall be:

<derived engineering crs> ::= <engineering crs keyword> <left delimiter> <derived crs name> <wkt separator> { <base projected crs> | <base geodetic crs>  | <base engineering crs> } <wkt separator> <deriving conversion> <wkt separator> <coordinate system> <scope extent identifier remark> <right delimiter>  
<engineering crs keyword> ::= ENGCRS | ENGINEERINGCRS         !! See 11.1
<derived crs name> ::= <quoted Latin text>                                       !! See 7.2
<base projected crs> ::= <base projected crs keyword> <left delimiter> <base crs name> <wkt separator> <base geodetic crs> <wkt separator> <map projection> <right delimiter>  
<base projected crs keyword> ::= BASEPROJCRS
<base geodetic crs> ::= <base geodetic crs keyword> <left delimiter> <base crs name> <wkt separator> <geodetic datum> [ <wkt separator> <ellipsoidal cs unit> ] <right delimiter> !! <ellipsoidal cs unit> is an optional attribute included in the definition of <base geodetic crs> for projected CRS backward compatibility reasons. It may be given when the derived CRS type is a projected CRS (see Clause 9) but when, as here, the derived CRS type is engineering it should not be given.  
<base geodetic crs keyword> ::= BASEGEODCRS
<base engineering crs> ::= <base engineering crs keyword> <left delimiter> <base crs name> <wkt separator> <engineering datum> <right delimiter>  
<base engineering crs keyword> ::= BASEENGCRS
<base crs name> ::= <quoted Latin text>                                       !! See 7.2

<coordinate system> is described in 7.5; the constraints for engineering CRSs apply to engineering derived CRSs.

<engineering datum> is described in 11.2. <geodetic datum> is described in 8.2; it includes ellipsoid and prime meridian descriptions. <deriving conversion> is described in 15.2; <scope extent identifier remark> in 7.3.

Examples of WKT describing a derived engineering CRS

EXAMPLE 1      Seismic bin grid, an engineering CRS derived from a projected CRS

     ENGCRS[“Gulf of Mexico speculative seismic survey bin grid”,
     BASEPROJCRS["NAD27 / Texas South Central",
       BASEGEODCRS["NAD27",
         DATUM[“North American Datum 1927”,
           ELLIPSOID[“Clarke 1866”,20925832.164,294.97869821,
             LENGTHUNIT[“US survey foot”,0.304800609601219]]]],
       CONVERSION["Texas South CentralSPCS27",
         METHOD["Lambert Conic Conformal (2SP)“,ID[”EPSG",9802]],
         PARAMETER[“Latitude of false origin”,27.83333333333333,
          ANGLEUNIT[“degree”,0.0174532925199433],ID[“EPSG”,8821]],
         PARAMETER[“Longitude of false origin”,-99.0,
           ANGLEUNIT[“degree”,0.0174532925199433],ID[“EPSG”,8822]],
         PARAMETER[“Latitude of 1st standard parallel”,28.383333333333,
          ANGLEUNIT[“degree”,0.0174532925199433],ID[“EPSG”,8823]],
         PARAMETER[“Latitude of 2nd standard parallel”,30.283333333333,
          ANGLEUNIT[“degree”,0.0174532925199433],ID[“EPSG”,8824]],
         PARAMETER[“Easting at false origin”,2000000.0,
           LENGTHUNIT[“US survey foot”,0.304800609601219],ID[“EPSG”,8826]],
         PARAMETER[“Northing at false origin”,0.0,
           LENGTHUNIT[“US survey foot”,0.304800609601219],ID[“EPSG”,8827]]]],
     DERIVINGCONVERSION[“Gulf of Mexico speculative survey bin grid”,
       METHOD[“P6 (I = J-90°) seismic bin grid transformation”,ID[“EPSG”,1049]],
       PARAMETER[“Bin grid origin I”,5000,SCALEUNIT[“Bin”,1.0],ID[“EPSG”,8733]],
       PARAMETER[“Bin grid origin J”,0,SCALEUNIT[“Bin”,1.0],ID[“EPSG”,8734]],
       PARAMETER[“Bin grid origin Easting”,871200,
         LENGTHUNIT[“US survey foot”,0.304800609601219],ID[“EPSG”,8735]],
       PARAMETER[“Bin grid origin Northing”, 10280160,
         LENGTHUNIT[“US survey foot”,0.304800609601219],ID[“EPSG”,8736]],
       PARAMETER[“Scale factor of bin grid”,1.0,
         SCALEUNIT[“Unity”,1.0],ID[“EPSG”,8737]],
       PARAMETER[“Bin width on I-axis”,82.5,
         LENGTHUNIT[“US survey foot”,0.304800609601219],ID[“EPSG”,8738]],
       PARAMETER[“Bin width on J-axis”,41.25,
         LENGTHUNIT[“US survey foot”,0.304800609601219],ID[“EPSG”,8739]],
       PARAMETER[“Map grid bearing of bin grid J-axis”,340,
         ANGLEUNIT[“degree”,0.0174532925199433],ID[“EPSG”,8740]],
       PARAMETER[“Bin node increment on I-axis”,1.0,
         SCALEUNIT[“Bin”,1.0],ID[“EPSG”,8741]],
       PARAMETER[“Bin node increment on J-axis”,1.0,
         SCALEUNIT[“Bin”,1.0],ID[“EPSG”,8742]]],
     CS[Cartesian,2],
       AXIS["(I)",northNorthWest],
       AXIS["(J)",westSouthWest],
       SCALEUNIT[“Bin”,1.0]]

 

NOTE        A similar approach may be used to describe any grid referencing system based on a projected CRS. The grid cell size and placement are defined through the deriving conversion

EXAMPLE 2      Derived engineering CRS where the topocentric CS origin is defined in terms of a geographic 3D CRS.

   ENGCRS["Topocentric example A",
     BASEGEODCRS["WGS 84",
       DATUM["WGS 84",
         ELLIPSOID[“WGS 84”,6378137,298.2572236,LENGTHUNIT[“metre”,1.0]]]],
     DERIVINGCONVERSION["Topocentric example A",
       METHOD[“Geographic/topocentric conversions”,ID[“EPSG”,9837]],
       PARAMETER[“Latitude of topocentric origin”,55.0,
         ANGLEUNIT[“degree”,0.0174532925199433]],
       PARAMETER[“Longitude of topocentric origin”,5.0,
         ANGLEUNIT[“degree”,0.0174532925199433]],
       PARAMETER[“Ellipsoidal height of topocentric origin”,0.0,
        LENGTHUNIT[“metre”,1.0]]],
     CS[Cartesian,3],
       AXIS["Topocentric East (U)",north,ORDER[1]],
       AXIS["Topocentric North (V)",east,ORDER[2]],
       AXIS["Topocentric height (W)",east,ORDER[3]],
       LENGTHUNIT[“metre”,1.0]]

15.6 Derived CRS of type parametric

Requirement: The WKT representation of a derived parametric coordinate reference system shall be:

<derived parametric crs> ::= <parametric crs keyword> <left delimiter> <derived crs name> <wkt separator> <base parametric crs> <wkt separator> <deriving conversion> <wkt separator> <coordinate system> <scope extent identifier remark> <right delimiter>  
<parametric crs keyword> ::= PARAMETRICCRS                  !! See 13.1
<derived crs name> ::= <quoted Latin text>                                       !! See 7.2
<base parametric crs> ::= <base parametric crs keyword> <left delimiter> <base crs name> <wkt separator> <parametric datum> <right delimiter>  
<base parametric crs keyword> ::= BASEPARAMCRS
<base crs name> ::= <quoted Latin text>                                       !! See 7.2

<coordinate system> is described in 7.5; the constraints for parametric CRSs apply to parametric derived CRSs.

<parametric datum> is described in 13.2, <deriving conversion> in 15.2 and <scope extent identifier remark> in 7.3.

15.7 Derived CRS of type temporal

Requirement: The WKT representation of a derived temporal coordinate reference system shall be:

<derived temporal crs> ::= <temporal crs keyword> <left delimiter> <derived crs name> <wkt separator> <base temporal crs> <wkt separator> <deriving conversion> <wkt separator> <coordinate system> <scope extent identifier remark> <right delimiter>  
<temporal crs keyword> ::= TIMECRS                         !! See 14.1
<derived crs name> ::= <quoted Latin text>                                       !! See 7.2
<base temporal crs> ::= <base temporal crs keyword> <left delimiter> <base crs name> <wkt separator> <temporal datum> <right delimiter>  
<base temporal crs keyword> ::= BASETIMECRS
<base crs name> ::= <quoted Latin text>                                       !! See 7.2

<coordinate system> is described in 7.5; the constraints for temporal CRSs apply to temporal derived CRSs.

<temporal datum> is described in 14.2, <deriving conversion> in 15.2 and <scope extent identifier remark> in 7.3.

16. WKT representation of compound coordinate reference systems

16.1 Overview

A compound CRS is a non-repeating sequence of two or more independent coordinate reference systems none of which can itself be compound. ISO 19111:2007 8.2.4 defines valid combinations of CRS that may form a compound CRS.

 

Requirement: The WKT representation of a compound coordinate reference system shall be:

<compound crs> ::= <compound crs keyword> <left delimiter> <compound crs name> <wkt separator> <horizontal crs> <wkt separator> <vertical crs> | <parametric crs> | <temporal crs> | { <vertical crs> <wkt separator> <temporal crs> } | { <parametric crs> <wkt separator> <temporal crs> } [ <scope extent identifier remark> ] <right delimiter>  
<compound crs keyword> ::= COMPOUNDCRS
<compound crs name> ::= <quoted Latin text>                                       !! See 7.2
<horizontal crs> ::= <geographic2D crs> | <projected crs> | <engineering crs>
<geographic2D crs> ::= <geodetic crs keyword> <left delimiter> <crs name> <wkt separator> <geodetic datum> <wkt separator> <ellipsoidal2D coordinate system> <scope extent identifier remark> <right delimiter>  

A <geographic2D crs> is a special case of a geodetic CRS (see 8.1) in which its coordinate system is ellipsoidal 2D. <ellipsoidal2D coordinate system> is a special case of <coordinate system> and is described in 7.5.1.

Constraints on axis order for compound CRSs are described in 7.5.5.

<scope extent identifier remark> is described in 7.3. The representation of other constituent CRSs is elaborated in Clauses 9 to 15.

16.2 Examples of WKT describing a compound CRS

EXAMPLE 1       Spatial CRS 

   COMPOUNDCRS[“NAD83 + NAVD88”,
     GEODCRS[“NAD83”,
       DATUM[“North American Datum 1983”,
           ELLIPSOID[“GRS 1980”,6378137,298.257222101,
             LENGTHUNIT[“metre”,1.0]]],
         PRIMEMERIDIAN[“Greenwich”,0],
       CS[ellipsoidal,2],
         AXIS[“latitude”,north,ORDER[1]],
         AXIS[“longitude”,east,ORDER[2]],
         ANGLEUNIT[“degree”,0.0174532925199433]],
     VERTCRS[“NAVD88”,
       VDATUM[“North American Vertical Datum 1983”],
       CS[vertical,1],
         AXIS["gravity-related height (H)",up],
         LENGTHUNIT[“metre”,1]]]

EXAMPLE 2      Spatio-parametric CRS 

   COMPOUNDCRS[“ICAO layer 0”,
     GEODETICCRS[“WGS 84”,
       DATUM[“World Geodetic System 1984”,
         ELLIPSOID[“WGS 84”,6378137,298.257223563,
           LENGTHUNIT[“metre”,1.0]]],
       CS[ellipsoidal,2],
         AXIS[“latitude”,north,ORDER[1]],
         AXIS[“longitude”,east,ORDER[2]],
         ANGLEUNIT[“degree”,0.0174532925199433]],
         PARAMETRICCRS[“WMO standard atmosphere”,
       PARAMETRICDATUM[“Mean Sea Level”,
         ANCHOR[“Mean Sea Level = 1013.25 hPa”]],
           CS[parametric,1],
             AXIS["pressure (P)",unspecified],
             PARAMETRICUNIT[“HectoPascal”,100]]]

EXAMPLE 3      Spatio-temporal CRS (ellipsoid axis unit is metres as <lengthunit> is omitted) 

   COMPOUNDCRS[“GPS position and time”,
     GEODCRS[“WGS 84”,
       DATUM[“World Geodetic System 1984”,
         ELLIPSOID[“WGS 84”,6378137,298.257223563]],
       CS[ellipsoidal,2],
         AXIS["(lat)",north,ORDER[1]],
         AXIS["(lon)",east,ORDER[2]],
         ANGLEUNIT[“degree”,0.0174532925199433]],
     TIMECRS[“GPS Time”,
       TIMEDATUM[“Time origin”,TIMEORIGIN[1980-01-01]],
       CS[temporal,1],
         AXIS["time (T)",future],
         TIMEUNIT[“day”,86400]]]

 

17. WKT representation of coordinate operations

17.1 Coordinate operations

The WKT representation of a coordinate operation may be used for any coordinate operation (coordinate transformation or coordinate conversion) other than a map projection. Map projections are part of a projected CRS definition and are described in 9.3.

Requirement: The WKT representation of a <coordinate operation> shall be:

<coordinate operation>   ::= <operation keyword> <left delimiter> <operation name> <wkt separator> <source crs> <wkt separator> <target crs> <wkt separator> <operation method> { <wkt separator> <operation parameter> | <operation parameter file> }… [ <wkt separator> <interpolation crs> ]  [ <wkt separator> <operation accuracy]  [ <scope extent identifier remark> ] <right delimiter>  
<operation keyword> ::= COORDINATEOPERATION
<operation name> ::= <quoted Latin text>                                       !! See 7.2

17.2 Coordinate operation components

Source and target CRS

Requirement: The WKT representation of a coordinate operation’s source and target CRSs shall be:

<source crs> ::= <source crs keyword><left delimiter> <coordinate reference system> <right delimiter>  
<source crs keyword> ::= SOURCECRS
<target crs> ::= <target crs keyword><left delimiter> <coordinate reference system> <right delimiter>  
<target crs keyword> ::= TARGETCRS
<coordinate reference system> ::= <geodetic crs> | <projected crs> | <vertical crs> | <engineering crs> | <image crs>  | <parametric crs> | <temporal crs> | <derived geodetic crs> | <derived vertical crs> | <derived engineering crs> | <derived parametric crs> | <derived temporal crs> | <compound crs>  

Coordinate reference systems are defined in Clauses 8 to 16.

Coordinate operation name and identifier

Coordinate operation encompasses the collection of method and parameter values. Its name is for human readability.

<identifier> is described in 7.3.4. It is an optional attribute. If an identifier is provided as an attribute within the <coordinate operation> object (17.1), because it is expected to describe a complete collection of zone name, method, parameters and parameter values, it shall override any identifiers given within the coordinate operation method and coordinate operation parameter objects.

Requirement:If an identifier is provided as an attribute of a coordinate operation object, it shall override any identifiers given within the component method and parameter objects.

Coordinate operation method

Requirement: The WKT representation of a coordinate operation method shall be:

<operation method> ::= <operation method keyword> <left delimiter> <operation method name> [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<operation method keyword> ::= METHOD
<operation method name> ::= <quoted Latin text>                                       !! See 7.2

Method name is for human readability. For interoperability it is the method formula that is critical in determining the equivalence of methods; this may be given through an operation method <identifier>.

<identifier> is described in 7.3.4. If an <identifier> is omitted for both coordinate operation (17.1) and operation method, the WKT description is potentially ambiguous, relying on interpretation of method name. It is recommended that either a coordinate operation identifier or a coordinate operation method identifier is included in WKT strings. Identifiers for commonly encountered coordinate transformation methods are given in E.4.

Coordinate operation parameter

Requirement: The WKT representation of a coordinate operation parameter shall be:

<operation parameter> ::= <parameter keyword>  <left delimiter> <parameter name> <wkt separator><parameter value> <wkt separator> <parameter unit>  [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<parameter keyword>  ::= PARAMETER
<parameter name> ::= <quoted Latin text>                                       !! See 7.2
<parameter value> ::= <signed numeric literal>
<parameter unit> ::= <length unit> | <angle unit> | <scale unit> | <parametric unit> | <time unit>

Units are described in 7.4.

Parameter name is for human readability. For interoperability it is the method formula and its parameters that are critical in determining the equivalence of methods. See Annex E. Identifiers for commonly encountered coordinate operation methods and their parameters are given in E.4; the parameters are listed in E.5. The coordinate operation parameters required are specific to the coordinate operation method and shall be listed sequentially. The order within the sequence is not significant but should be logical. Implementations should be prepared to read any order. For those methods included in Annex E the parameter order given in E.4 is recommended.

Requirements:

  1.    In coordinate operation WKT strings <parameter value>s shall be given in the sense <source crs> to <target crs>. If the transformation parameter unit is linear its conversion factor shall be to metres and is the number of metres per unit. If the unit is angular its conversion factor shall be to radians and is the number of radians per unit. If the parameter is a scaling unit the conversion factor shall be to unity, for example parts per million (ppm) shall be given as 10-6. For commonly-encountered transformation parameters the parameter type is included in E.5.
  2.    <identifier> is described in 7.3.4. It is an optional attribute. If an identifier is included as an attribute within the coordinate operation object (17.1) or coordinate operation method object (17.2.3), it shall take precedence over any identifier within the coordinate operation parameter object.

Coordinate operation parameter file

Requirement: The WKT representation of a coordinate operation parameter file shall be:

<operation parameter file> ::= <parameter file keyword> <left delimiter> <parameter name> <wkt separator> <parameter file name> [ { <wkt separator> <identifier> } ]…  <right delimiter>  
<parameter file keyword> ::= PARAMETERFILE
<parameter name> ::= <quoted Latin text>                                       !! See 7.2
<parameter file name> ::= <quoted Latin text>

For <parameter name> and <identifier> the requirements given in 17.2.4 shall apply.

Interpolation CRS

Some coordinate operation methods require coordinates referenced to a CRS which is neither the source CRS or target CRS. For example, in a coordinate operation applying a vertical offset between two vertical CRSs using either the vertical offset and slope method or a grid interpolation method such as VERTCON, horizontal coordinates are required. <interpolation crs> provides the mechanism for defining the CRS to which these coordinates are referenced.

Requirement: The WKT representation of an <interpolation crs> shall be:

<interpolation crs> ::= <interpolation crs keyword> <left delimiter> <coordinate reference system> <right delimiter>  
<interpolation crs keyword> ::= INTERPOLATIONCRS

<coordinate reference system> is defined in 17.2.1.

Coordinate operation accuracy

Operation accuracy is an optional attribute which indicates the typical error the application of a coordinate operation will introduce into transformed target CRS coordinates assuming input of errorless source CRS coordinates. It is an approximate figure for the area of applicability of the coordinate operation as a whole, given in metres.

Requirement: The WKT representation of an <operation accuracy> shall be:

<operation accuracy> ::= <operation accuracy keyword> <left delimiter> <accuracy> <right delimiter>  
<operation accuracy keyword> ::= OPERATIONACCURACY
<accuracy> ::= <number>                   !! <accuracy> is in metres

Other coordinate operation attributes

<identifier> is described in 7.3.4. It is an optional attribute.

<scope> is described in 7.3.2 and <extent> in 7.3.3. These are optional attributes describing the applicability of the coordinate operation.

<remark> is described in 7.3.5.

17.3 Examples of WKT describing a coordinate operation

Line feeds are included in these examples to aid clarity. In several of these examples the full source and target CRS definitions are omitted from the example so that the coordinate transformation elements are more clearly identified.

EXAMPLE 1     

   COORDINATEOPERATION[“Tokyo to JGD2000 (GSI)”,
     SOURCECRS[
       GEODCRS[“Tokyo”,
         DATUM[“Tokyo 1918”,
          ELLIPSOID[“Bessel 1841”,6377397.155,299.1528128,LENGTHUNIT[“metre”,1.0]]],
        CS[Cartesian,3],
        AXIS["(X)",geocentricX,ORDER[1]],
        AXIS["(Y)",geocentricY,ORDER[2]],
        AXIS["(Z)",geocentricZ,ORDER[3]],
        LENGTHUNIT[“metre”,1.0]]],
     TARGETCRS[
       GEODCRS[“JGD2000”,
         DATUM[“Japanese Geodetic Datum 2000”,
          ELLIPSOID[“GRS 1980”,6378137.0,298.257222101,LENGTHUNIT[“metre”,1.0]]],
        CS[Cartesian,3],
        AXIS["(X)",geocentricX],
        AXIS["(Y)",geocentricY],
        AXIS["(Z)",geocentricZ],
        LENGTHUNIT[“metre”,1.0]]],
     METHOD[“Geocentric translations”,ID[“EPSG”,1031]],
     PARAMETER[“X-axis translation”,-146.414,
       LENGTHUNIT[“metre”,1.0],ID[“EPSG”,8605]],
     PARAMETER[“Y-axis translation”,507.337,
       LENGTHUNIT[“metre”,1.0],ID[“EPSG”,8606]],
     PARAMETER[“Z-axis translation”,680.507,
       LENGTHUNIT[“metre”,1.0],ID[“EPSG”,8607]]]

EXAMPLE 2     

   COORDINATEOPERATION[“AGD84 to GDA94 Auslig 5m”,
     SOURCECRS[…full CRS definition required here but omitted for brevity…],
     TARGETCRS[…full CRS definition required here but omitted for brevity…],
     METHOD[“Geocentric translations”,ID[“EPSG”,1031]],
     PARAMETER[“X-axis translation”,-128.5,LENGTHUNIT[“metre”,1.0]],
     PARAMETER[“Y-axis translation”,-53.0,LENGTHUNIT[“metre”,1.0]],
     PARAMETER[“Z-axis translation”,153.4,LENGTHUNIT[“metre”,1.0]]
     OPERATIONACCURACY[5],
     AREA[“Australia onshore”],BBOX[-43.7,112.85,-9.87,153.68],
     REMARK[“Use NTv2 file for better accuracy”]]

EXAMPLE 3     

   COORDINATEOPERATION[“NZGD49 to NZGD2000”,
     SOURCECRS[…full WKT definition required here but omitted for brevity…],
     TARGETCRS[…full WKT definition required here but omitted for brevity…],
     METHOD[“NTv2”,ID[“EPSG”,9615]],
     PARAMETERFILE[“Latitude and longitude difference file”,“nzgd2kgrid0005.gsb”],
     ID[“EPSG”,1568,CITATION[“LINZS25000”],
       URI[http://www.linz.govt.nz/geodetic/software-downloads/]],
     REMARK["Coordinate transformation accuracy 0.1-1.0m"]]

EXAMPLE 4     

   COORDINATEOPERATION[“Amersfoort to ETRS89 (3)”,
     SOURCECRS[…full CRS definition required here but omitted for brevity…],
     TARGETCRS[…full CRS definition required here but omitted for brevity…],
     METHOD[“Coordinate Frame”],
     PARAMETER[“X-axis translation”,565.2369,LENGTHUNIT[“metre”,1.0]],
     PARAMETER[“Y-axis translation”,50.0087,LENGTHUNIT[“metre”,1.0]],
     PARAMETER[“Z-axis translation”,465.658,LENGTHUNIT[“metre”,1.0]],
     PARAMETER[“X-axis rotation”,1.9725,ANGLEUNIT[“microradian”,1E-06]],
     PARAMETER[“Y-axis rotation”,-1.7004,ANGLEUNIT[“microradian”,1E-06]],
     PARAMETER[“Z-axis rotation”,9.0677,ANGLEUNIT[“microradian”,1E-06]],
     PARAMETER[“Scale difference”,4.0812,SCALEUNIT[“parts per million”,1E-06]],
     ID[“EPSG”,15739]]

EXAMPLE 5     

   COORDINATEOPERATION[“DHHN92 height to EVRF2007 height”,
     SOURCECRS[…full WKT definition of DHHN92 required here but omitted for brevity…],
     TARGETCRS[…full WKT definition of EVRF2007 required here but omitted for brevity…],
     METHOD[“Vertical Offset and Slope”,ID[“EPSG”,1046]],
     PARAMETER[“Inclination in latitude”,-0.010,
       ANGLEUNIT[“arc-second”,4.84813681109535E-06]],
     PARAMETER[“Inclination in longitude”,0.002,
       ANGLEUNIT[“arc-second”,4.84813681109535E-06]],
     PARAMETER[“Vertical offset”,0.015,LENGTHUNIT[“metre”,1.0]],
     PARAMETER[“Ordinate 1 of evaluation point”,51.05,
       ANGLEUNIT[“degree”,0.0174532925199433]],
     PARAMETER[“Ordinate 2 of evaluation point”,10.2166666666667,
       ANGLEUNIT[“degree”,0.0174532925199433]],
     INTERPOLATIONCRS["ETRS89"…full WKT definition of ETRS89 required here but omitted for brevity…],
     OPERATIONACCURACY[0.1],
     REMARK[“Determined at 427 points. RMS residual 0.002m, maximum residual 0.007m”]]

18. WKT representation of CRS and coordinate operation couplets

18.1 Bound CRS

The definition of a CRS is not dependent upon any relationship to an independent CRS. However in an implementation that merges datasets referenced to differing CRSs, it is sometimes useful to associate the definition of the transformation that has been used with the CRS definition. This facilitates the interrelationship of CRS by concatenating transformations via a common or hub CRS. This is sometimes referred to as ‘early-binding’. This International Standard permits the association of an abridged coordinate transformation description with a coordinate reference system description in a single text string. In a Bound CRS the abridged coordinate transformation is applied to the source CRS with the target CRS being the common or hub system.

Requirement: The WKT representation of a bound CRS shall be:

<bound crs> ::= <bound crs keyword> <left delimiter> <source crs> <wkt separator> <target crs> <wkt separator> <abridged coordinate transformation> [ { <wkt separator> <identifier> } ]…  [ <wkt separator> <remark> ]  <right delimiter> }  
<bound crs keyword> ::= BOUNDCRS

Examples are given in 18.3.

The source and target CRSs shall be defined through a full CRS description as described in Clause 8. If the source CRS type is projected and the abridged coordinate transformation operates in the geodetic CRS domain, the transformation is deemed to operate on the projected CRS’s base CRS but the projected CRS shall be described.

18.2 Bound CRS components

Abridged coordinate transformation

In the WKT representation of projected coordinate reference systems the units of map projection parameters may be implied (see 9.3). In a similar way the abridged coordinate transformation also omits explicit identification of coordinate transformation parameter unit from the text string. It has several constraints.

Requirements:

  1.  The abridged form of coordinate transformation shall only be used as part of a Bound CRS.
  2.  The abridged transformation shall be described in the sense from <source CRS> to <target CRS>.
  3.  The WKT representation of an abridged coordinate transformation shall be:

 

<abridged coordinate transformation> ::= <abridged transformation keyword> <left delimiter> <operation name> <wkt separator> <operation method> <wkt separator> { <abridged transformation parameter>... | <operation parameter file>... } [ <scope extent identifier remark> ] <right delimiter>  
<abridged transformation keyword> ::= ABRIDGEDTRANSFORMATION

Coordinate operation method in abridged coordinate transformations

In an abridged coordinate transformation description the format for operation method is identical to that defined in Clause 9 but there are constraints:

Constraint: The only coordinate transformation methods that may be described in an abridged coordinate transformation shall be:

  1.    3-, 7- and 10-parameter geocentric transformations (7-parameter methods include both Position Vector and Coordinate Frame methods);
  2.    Methods using interpolation of gridded data sets (NTv2, NADCON, geoid and height correction models).

Abridged coordinate transformation parameter

Requirement: The WKT representation of an abridged transformation parameter shall be:

<abridged transformation parameter> ::= <parameter keyword>  <left delimiter> <parameter name> <wkt separator> <parameter value> [ { <wkt separator> <identifier> } ]…  <right delimiter>  

The format for abridged transformation parameter is similar to that for coordinate operation parameter defined in 17.2.4 but with the following constraints-on parameter values:

Requirements:

  1.  The value of parameters which are linear shall be given in metres.
  2.  The value of parameters which are angular shall be given in arc-seconds (4.848136811095E-06 radian).
  3. The value of parameters which are scale units shall be given as a number with respect to unity, for example 3.5 parts per million (ppm) shall be given as 1.0000035 and -3.5ppm shall be given as 0.9999965.
  4. <unit> shall not be given.
  5. Implementations are expected to identify the parameter value unit type from the parameter name.
  6. The parameter values shall be described in the sense from source CRS to target CRS.

The parameters required are specific to the coordinate operation method and are listed sequentially. The order within the sequence is not significant but should be logical.

EXAMPLE  

        ABRIDGEDTRANSFORMATION[“Tokyo to JGD2000 (GSI)”,
                METHOD[“Geocentric translations”,ID[“EPSG”,1031]],
                PARAMETER[“X-axis translation”,-146.414],
                PARAMETER[“Y-axis translation”,507.337],
                PARAMETER[“Z-axis translation”,680.507]]

 

Coordinate operation parameter file

Operation parameter file is defined in 17.2.5.

18.3 Examples of WKT describing a Bound CRS

EXAMPLE 1     

   BOUNDCRS[
     SOURCECRS[
       GEODCRS[“NAD27”,
         DATUM[“North American Datum 1927”,
           ELLIPSOID[“Clarke 1866”,6378206.4,294.978698213]],
         CS[ellipsoidal,2],
         AXIS[“latitude”,north],AXIS[“longitude”,east],
         ANGLEUNIT[“degree”,0.0174532925199433]]],
     TARGETCRS[
       GEODCRS[“NAD83”,
         DATUM[“North American Datum 1983”,
           ELLIPSOID[“GRS 1980”,6378137,298.2572221]],
         CS[ellipsoidal,2],
         AXIS[“latitude”,north],AXIS[“longitude”,east],
         ANGLEUNIT[“degree”,0.0174532925199433]]],
     ABRIDGEDTRANSFORMATION[“NAD27 to NAD83 Alaska”,
       METHOD[“NADCON”,ID[“EPSG”,9613]],
       PARAMETERFILE[“Latitude difference file”,“alaska.las”],
       PARAMETERFILE[“Longitude difference file”,“alaska.los”]]]

 

EXAMPLE 2     

   BOUNDCRS[
     SOURCECRS[…full WKT definition required here but omitted for brevity…],
     TARGETCRS[…full WKT definition required here but omitted for brevity…],
     ABRIDGEDTRANSFORMATION[“NAD27 to NAD83(86) National”,
       METHOD[“NTv2”,ID[“EPSG”,9615]],
       PARAMETERFILE[“Latitude and longitude difference file”,“NTv2_0.gsb”]]]

 

EXAMPLE 3     

   BOUNDCRS[
     SOURCECRS[…full WKT definition required here but omitted for brevity…],
     TARGETCRS[…full WKT definition required here but omitted for brevity…],
     ABRIDGEDTRANSFORMATION[“Amersfoort to ETRS89 (3)”,
       METHOD[“Coordinate Frame”,ID[“EPSG”,1032]],
       PARAMETER[“X-axis translation”,565.2369,ID[“EPSG”,8605]],
       PARAMETER[“Y-axis translation”,50.0087,ID[“EPSG”,8606]],
       PARAMETER[“Z-axis translation”,465.658,ID[“EPSG”,8607]],
       PARAMETER[“X-axis rotation”,0.407,ID[“EPSG”,8608]],
       PARAMETER[“Y-axis rotation”,-0.351,ID[“EPSG”,8609]],
       PARAMETER[“Z-axis rotation”,1.870,ID[“EPSG”,8610]],
       PARAMETER[“Scale difference”,1.000004812,ID[“EPSG”,8611]]]]

NOTE        Compare the rotation values (here in arc-seconds because in an abridged coordinate transformation) with those in the fourth example in 17.3.

 

 

Annex A
(normative)

Abstract test suite

A.1 Conformance of a WKT string describing a geodetic CRS
A.1.1 Structure of a WKT string describing a geodetic CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/structure_geodetic_CRS
Title Structure of a WKT string describing a geodetic CRS
Abbreviation conf/structure_geodetic_CRS
Type capability
Requirement Clauses 5 and 6.
Test Purpose to determine whether a text string representation of a geodetic coordinate reference system conforms to the characters and syntax required by this International Standard.
Test Method Test method: verify that the structure of the WKT string conforms to the requirements of Clause 5 and that text string syntax conforms to the requirements of Clause 6.

 

A.1.2 Content of a WKT string describing a geodetic CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/content_geodetic_CRS
Title Content of a WKT string describing a geodetic CRS
Abbreviation conf/content_geodetic_CRS
Type capability
Requirement Clauses 7 and 8.
Test Purpose to determine whether a text string representation of a geodetic coordinate reference system conforms to content required by this International Standard.
Test Method verify that the text string includes all of the elements specified for a geodetic CRS, and that these use the correct terminology and syntax.

 

A.2 Conformance of a WKT string describing a projected CRS
A.2.1 Structure of a WKT string describing a projected CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/structure_projected_CRS
Title Structure of a WKT string describing a projected CRS
Abbreviation conf/structure_projected_CRS
Type capability
Requirement Clauses 5 and 6.
Test Purpose to determine whether a text string representation of a projected coordinate reference system conforms to the characters and syntax required by this International Standard
Test Method Test method: verify that the structure of the WKT string conforms to the requirements of Clause 5 and that text string syntax conforms to the requirements of Clause 6.

 

A.2.2 Content of a WKT string describing a projected CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/content_projected_CRS
Title Content of a WKT string describing a projected CRS
Abbreviation conf/content_projected_CRS
Type capability
Requirement Clauses 7, 8 and 9.
Test Purpose to determine whether a text string representation of a projected coordinate reference system conforms to content required by this International Standard.
Test Method verify that the text string includes all of the elements specified for a projected CRS, and that these use the correct terminology and syntax.

 

A.3 Conformance of a WKT string describing a vertical CRS
A.3.1 Structure of a WKT string describing a vertical CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/structure_vertical_CRS
Title Structure of a WKT string describing a vertical CRS
Abbreviation conf/structure_vertical_CRS
Type capability
Requirement Clauses 5 and 6.
Test Purpose to determine whether a text string representation of a vertical coordinate reference system conforms to the characters and syntax required by this International Standard.
Test Method Test method: verify that the structure of the WKT string conforms to the requirements of Clause 5 and that text string syntax conforms to the requirements of Clause 6.

 

A.3.2 Content of a WKT string describing a vertical CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/content_vertical_CRS
Title Content of a WKT string describing a vertical CRS
Abbreviation conf/content_vertical_CRS
Type capability
Requirement Clauses 7 and 10.
Test Purpose to determine whether a text string representation of a vertical coordinate reference system conforms to content required by this International Standard.
Test Method verify that the text string includes all of the elements specified for a vertical CRS, and that these use the correct terminology and syntax.

 

A.4 Conformance of a WKT string describing an engineering CRS
A.4.1 Structure of a WKT string describing an engineering CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/structure_engineering_CRS
Title Structure of a WKT string describing an engineering CRS
Abbreviation conf/structure_engineering_CRS
Type capability
Requirement Clauses 5 and 6.
Test Purpose to determine whether a text string representation of an engineering coordinate reference system conforms to the characters and syntax required by this International Standard.
Test Method verify that the structure of the WKT string conforms to the requirements of Clause 5 and that text string syntax conforms to the requirements of Clause 6.

 

A.4.2 Content of a WKT string describing an engineering CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/content_engineering_CRS
Title Content of a WKT string describing an engineering CRS
Abbreviation conf/content_engineering_CRS
Type capability
Requirement Clauses 7 and 11.
Test Purpose to determine whether a text string representation of an engineering coordinate reference system conforms to content required by this International Standard.
Test Method verify that the text string includes all of the elements specified for an engineering CRS, and that these use the correct terminology and syntax.

 

A.5 Conformance of a WKT string describing an image CRS
A.5.1 Structure of a WKT string describing an image CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/structure_image_CRS
Title Structure of a WKT string describing an image CRS
Abbreviation conf/structure_image_CRS
Type capability
Requirement Clauses 5 and 6.
Test Purpose to determine whether a text string representation of an image coordinate reference system conforms to the characters and syntax required by this International Standard.
Test Method verify that the structure of the WKT string conforms to the requirements of Clause 5 and that text string syntax conforms to the requirements of Clause 6.

 

A.5.2 Content of a WKT string describing an image CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/content_image_CRS
Title Content of a WKT string describing an image CRS
Abbreviation conf/content_image_CRS
Type capability
Requirement Clauses 7 and 12.
Test Purpose to determine whether a text string representation of an image coordinate reference system conforms to content required by this International Standard.
Test Method verify that the text string includes all of the elements specified for an image CRS, and that these use the correct terminology and syntax.

 

A.6 Conformance of a WKT string describing a parametric CRS
A.6.1 Structure of a WKT string describing a parametric CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/structure_parametric_CRS
Title
Abbreviation conf/structure_parametric_CRS
Type capability
Requirement Clauses 5 and 6.
Test Purpose to determine whether a text string representation of a parametric coordinate reference system conforms to the characters and syntax required by this International Standard.
Test Method verify that the structure of the WKT string conforms to the requirements of Clause 5 and that text string syntax conforms to the requirements of Clause 6.

 

A.6.2 Content of a WKT string describing a parametric CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/content_parametric_CRS
Title Content of a WKT string describing a parametric CRS
Abbreviation conf/content_parametric_CRS
Type capability
Requirement Clauses 7 and 13.
Test Purpose to determine whether a text string representation of a parametric coordinate reference system conforms to content required by this International Standard.
Test Method verify that the text string includes all of the elements specified for a parametric CRS, and that these use the correct terminology and syntax.

 

A.7 Conformance of a WKT string describing a temporal CRS
A.7.1 Structure of a WKT string describing a temporal CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/structure_temporal_CRS
Title Structure of a WKT string describing a temporal CRS
Abbreviation conf/structure_temporal_CRS
Type capability
Requirement Clauses 5 and 6.
Test Purpose to determine whether a text string representation of a temporal coordinate reference system conforms to the characters and syntax required by this International Standard.
Test Method verify that the structure of the WKT string conforms to the requirements of Clause 5 and that text string syntax conforms to the requirements of Clause 6.

 

A.7.2 Content of a WKT string describing a temporal CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/content_temporal_CRS
Title Content of a WKT string describing a temporal CRS
Abbreviation conf/content_temporal_CRS
Type capability
Requirement Clauses 7 and 14.
Test Purpose to determine whether a text string representation of a temporal coordinate reference system conforms to content required by this International Standard.
Test Method verify that the text string includes all of the elements specified for a temporal CRS, and that these use the correct terminology and syntax.

 

 

A.8 Conformance of a WKT string describing a derived CRS
A.8.1 Structure of a WKT string describing a derived CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/structure_derived_CRS
Title Structure of a WKT string describing a derived CRS
Abbreviation conf/structure_derived_CRS
Type capability
Requirement Clauses 5 and 6.
Test Purpose to determine whether a text string representation of a derived coordinate reference system conforms to the characters and syntax required by this International Standard.
Test Method verify that the structure of the WKT string conforms to the requirements of Clause 5 and that text string syntax conforms to the requirements of Clause 6.

 

A.8.2 Content of a WKT string describing a derived CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/content_derived_CRS
Title Content of a WKT string describing a derived CRS
Abbreviation conf/content_derived_CRS
Type capability
Requirement
  1. Requirements for geodetic derived CRSs
    Clauses 7, 8.2, 15.2 and 15.3.
  2. Requirements for vertical derived CRSs
    Clauses 7, 10.2, 15.2 and 15.4.
  3. Requirements for engineering derived CRSs
    Clauses 7, 8.2, 9.3, 11.2, 15.2 and 15.5.
  4. Requirements for parametric derived CRSs
    Clauses 7, 13.2, 15.2 and 15.6.
  5. Requirements for temporal derived CRSs
    Clauses 7, 14.2, 15.2 and 15.7.
Test Purpose to determine whether a text string representation of a derived coordinate reference system conforms to content required by this International Standard.
Test Method verify that the text string describes one of the types of CRS supported, that it includes all of the elements specified for that type of CRS, and that these use the correct terminology and syntax.

 

A.9 Conformance of a WKT string describing a compound CRS
A.9.1 Structure of a WKT string describing a compound CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/structure_compound_CRS
Title Structure of a WKT string describing a compound CRS
Abbreviation conf/structure_compound_CRS
Type capability
Requirement Clauses 5 and 6.
Test Purpose to determine whether a text string representation of a compound coordinate reference system conforms to the characters and syntax required by this International Standard.
Test Method verify that the structure of the WKT string conforms to the requirements of Clause 5 and that text string syntax conforms to the requirements of Clause 6.

 

A.9.2 Content of a WKT string describing a compound CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/content_compound_CRS
Title Content of a WKT string describing a compound CRS
Abbreviation conf/content_compound_CRS
Type capability
Requirement Clauses 7 to 16 inclusive.
Test Purpose to determine whether a text string representation of a compound coordinate reference system conforms to content required by this International Standard.
Test Method verify that the text string includes all of the elements specified for a compound CRS, and that these use the correct terminology and syntax.

 

A.10 Conformance of a WKT string describing a coordinate operation
A.10.1 Structure of a WKT string describing a coordinate operation
http://www.opengis.net/spec/wkt-crs/1.0/conf/structure_coordinateOperation
Title Structure of a WKT string describing a coordinate operation
Abbreviation conf/structure_coordinateOperation
Type capability
Requirement Clauses 5 and 6.
Test Purpose to determine whether a text string representation of a coordinate operation conforms to the characters and syntax required by this International Standard.
Test Method verify that the structure of the WKT string conforms to the requirements of Clause 5 and that text string syntax conforms to the requirements of Clause 6.

 

A.10.2 Content of a WKT string describing a coordinate operation
http://www.opengis.net/spec/wkt-crs/1.0/conf/content_coordinateOperation
Title Content of a WKT string describing a coordinate operation
Abbreviation conf/content_coordinateOperation
Type capability
Requirement Clauses 7 to 17 inclusive
Test Purpose to determine whether a text string representation of a coordinate operation conforms to content required by this International Standard.
Test Method verify that the text string includes all of the elements specified for a coordinate operation, and that these use the correct terminology and syntax.

 

A.11 Conformance of a WKT string describing a Bound CRS
A.11.1 Structure of a WKT string describing a Bound CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/structure_bound_CRS
Title Structure of a WKT string describing a Bound CRS
Abbreviation conf/structure_bound_CRS
Type capability
Requirement Clauses 5 and 6.
Test Purpose to determine whether a text string representation of a Bound CRS conforms to the characters and syntax required by this International Standard.
Test Method verify that the structure of the WKT string conforms to the requirements of Clause 5 and that text string syntax conforms to the requirements of Clause 6.

 

A.11.2 Content of a WKT string describing a Bound CRS
http://www.opengis.net/spec/wkt-crs/1.0/conf/content_bound_CRS
Title Content of a WKT string describing a Bound CRS
Abbreviation conf/content_bound_CRS
Type capability
Requirement Clauses 7 to 18 inclusive.
Test Purpose to determine whether a text string representation of a Bound CRS conforms to content required by this International Standard.
Test Method verify that the text string includes all of the elements specified for a Bound CRS, and that these use the correct terminology and syntax.

 

Annex B
(informative)

Recommended practice for implementation

B.1 Introduction

This International Standard defines the structure and content of WKT strings. It does not specifically address the requirements for implementations that write or read these strings. Some recommendations for such implementations are given in B.2 to B.8.

B.2 Keywords

B.2.1    Keyword case sensitivity

WKT keywords by definition are case insensitive. KEYWORD is equivalent to keyword is equivalent to KeyWord and to kEYwORd. Where human readability is important (as in the examples in this International Standard) keywords should be written in only the <simple Latin upper case letter> set.

KEYWORD is not equivalent to KEY_WORD. The underscore character is significant.

B.2.2    Alternative keywords

Where two alternative keywords are defined, as a minimum, implementations should be able to write the first and to read both.

B.2.3    Handling of unrecognised keywords

It is recognised that prior to the publication of this International Standard some tokens that are not included in this document have been produced. Parsers reading CRS WKT strings and encountering unrecognised keywords should ignore the token and its content. They should be able to continue parsing the string without throwing an exception.

B.3 Characters

B.3.1    Handling of unrecognised characters

Implementations parsing WKT strings conformant with this International Standard are not required to be able to read non-LATIN1 character sets. But if they are unable to do so they should be able to continue reading the WKT string by ignoring the <remark> token (keyword and content) without throwing an exception.

B.3.2    String length

The length of a WKT string or of its components is not prescribed. However the following maximum lengths are recommended for implementations writing CRS WKT strings:

B.4 White space

B.4.1    Insertion of white space

Outside of <quoted Latin text> and <quoted Unicode text> a WKT string written to the requirements of this International Standard contains no white space. However to improve human readability implementations may insert spaces, tabs or line feeds before or after any element of the string. In the examples in this International Standard, line feeds and inset are included to aid clarity in reading this document.

Spaces should not be inserted within keywords or numbers.

B.4.2    Parsing of white space outside of quoted text

Parsers reading CRS WKT strings should ignore white space outside of <quoted Latin text> or <quoted Unicode text>.

B.4.3    Parsing of white space within quoted text

Parsers reading CRS WKT strings should ignore white space at the beginning or end of <quoted Latin text> or <quoted Unicode text>. Parsers may convert consecutive white space characters embedded within the quoted text string into a single <space>.

B.5 Identifiers

B.5.1    Use of identifier

When an identifier is given for a coordinate reference system, coordinate operation or bound CRS, it applies to the whole object including all of its components.

When an identifier is written into an object definition, all names, values and units for that object and its components which are given in the WKT should be consistent with those given by the authority.

In the event of conflict in values given in the CRS WKT string and given by an authority through an object’s name or an identifier, reading software should throw an exception or give users a warning message. The WKT values should be assumed to prevail.

B.5.2    Using names to interpret identity

If comparing the content of two <name> strings, implementations should ignore case, the characters <underscore> “_”, <minus sign> “-”, <solidus> “/”, <left paren> “(” and <right paren> “)”.

EXAMPLE         "Central_Meridian” should be considered equal to “central-meridian”, “Central meridian” and “centralMeridian”.

B.6 Numbers

B.6.1    Precision

Best practice is to preserve the original precision as specified by the information source. This may require maintaining 16 digits of precision.

B.6.2    Defining parameters for a sphere

The WKT representation of an ellipsoid requires the two defining parameters to be a and 1/f. For a sphere the value of 1/f is infinite. If the figure of the earth is a sphere it should have an artificial <inverse flattening> value of 0. Implementations should be prepared to read and handle this artificial value.

B.6.3    Implied units

Map projection <parameter unit> is an optional attribute for reasons of backward compatibility. It is recommended that it is included explicitly in WKT strings. If omitted then:

B.7 Attribute order

The order of elements in a WKT string is dictated by the BNF in this document. Certain attributes, notably map projection parameters and coordinate transformation parameters, may be included multiple times. The parameters required are specific to the method and will be listed sequentially. The order within the sequence is not significant but should be logical. Implementations should be prepared to read any order. For those methods included in Annex E the parameter order as listed in E.2 for map projections and E.4 for coordinate operations is recommended.

B.8 Version of CRS WKT

Implementations that wish to detect whether a CRS WKT string follows this International Standard or is from an earlier specification may do so by checking the first keyword in the string.

Strings conformant to this international standard must begin with or contain one of the following keywords:

Other than in coordinateOperation, the last characters in these keywords are ‘CRS‘.

If the WKT begins with or contains any of the following keywords, it is an older format:

The last characters in all these keywords are ‘CS’.

 

Annex C
(informative)

Mapping of concepts from previous versions of CRS WKT

C.1 BNF

Annex C describes differences between previous versions of CRS WKT defined in ISO 19125-1:2004 and OGC 01-009 and that defined in this International Standard. In Annex C the syntax of BNF used follows that defined in Clause 5. This differs from that used in both ISO 19125-1:2004 and OGC 01-009, given in Table C.1 for reference.

Table C.1: Mapping of concepts from previous versions of CRS WKT
ISO 19125-1:2004 and OGC CTS 01-009 This document Comment
= ::= Production
< > < > Basic type
| | Alternative
{ } [ ] Optionality
* ... Multiplicity
( ) { } Grouping

 

Of more relevance is the backward compatibility of the WKT strings themselves; this is described in C.2 to C.6.

C.2 Backward compatibility of CRS common attributes

C.2.1   Name

In both ISO 19125-1:2004 and OGC 01-009 the attribute <name> is, like in this International Standard, defined to be quoted text. However quoted text is not explicitly defined in these earlier specifications. As a consequence the name attribute in WKT strings written to the earlier specifications may contain characters and character sets not permitted by this International Standard. With this caveat, name attributes should be readable by implementations of this International Standard.

C.2.2   ID (Authority)

This attribute is not defined in ISO 19125-1:2004. In OGC 01-009 the object AUTHORITY was defined. In this International Standard the following definition from OGC 01-009 has been deprecated but is included here for the purposes of documenting backward compatibility:

<identifier> ::= AUTHORITY <left delimiter> <authority name> <wkt separator> <authority unique identifier> <right delimiter>  
<authority name> ::= <quoted Latin text>
<authority unique identifier> ::= <quoted Latin text>

The keyword AUTHORITY maps to the keyword ID in this International Standard. The attribute <authority unique identifier> in the BNF in this International Standard was called <code> in OGC 01-009 where it was defined to be quoted text, whereas <authority unique identifier> in this International Standard may be either a number (without quotes) or quoted text. For potential issues with quoted text in WKT strings written to earlier standards see C.2.1.

WKT descriptions of identifier (authority) written to the OGC 01-009 specification should be readable by implementations of this International Standard except when quoted text contains unsupported characters.

C.3 Backward compatibility of coordinate reference system components

C.3.1   Ellipsoid

The WKT for describing an ellipsoid is defined in 8.2.1.

In this International Standard the following definition from ISO 19125-1:2004 has been deprecated but is included here for the purposes of documenting backward compatibility:

<ellipsoid> ::= ELLIPSOID <left delimiter> <ellipsoid name> <wkt separator> <semi-major axis> <wkt separator> <inverse flattening> <right delimiter>  

In this International Standard the following definition from OGC 01-009 has been deprecated but is included here for the purposes of documenting backward compatibility:

<ellipsoid> ::= SPHEROID <left delimiter> <ellipsoid name> <wkt separator> <semi-major axis> <wkt separator> <inverse flattening> <right delimiter>  

Both ISO 19125-1:2004 and OGC 01-009 required that the semi-major axis be given in metres. Neither ISO 19125-1:2004 nor OGC 01-009 allowed for a sphere to be defined (as inverse flattening is infinite).

WKT descriptions of ellipsoids defined in metres and written to the ISO 19125-1:2004 and OGC 01-009 specifications should be readable by implementations of this International Standard.

C.3.2   Prime meridian

The WKT for prime meridian is defined in 8.2.2.

In this International Standard the following definition from both ISO 19125-1:2004 and OGC 01-009 has been deprecated but is included here for the purposes of documenting backward compatibility:

<prime meridian> ::= PRIMEM <left delimiter> <prime meridian name> <wkt separator> <irm longitude> <right delimiter>  

In both ISO 19125-1:2004 and OGC 01-009 <prime meridian> was a mandatory attribute of geographic CRS. (In certain frequently-occurring conditions it may be omitted in this International Standard). The longitude unit was unstated in ISO 19125-1:2004; in OGC 01-009 it was taken to be the angular unit of the geographic CRS in which it was contained or for a geocentric CRS was in degrees.

WKT descriptions of prime meridians written to the ISO 19125-1:2004 and OGC 01-009 specifications should be readable by implementations of this International Standard.

C.3.3   Datum

In this International Standard the following definition from ISO 19125-1:2004 has been deprecated but is included here for the purposes of documenting backward compatibility:

<geodetic datum> ::= <left delimiter> <datum name> <wkt separator> <ellipsoid> <right delimiter>

where ellipsoid is as described in C.3.1. ISO 19125-1:2004 did not cater for any other datum type.

WKT descriptions of geodetic datums written to the ISO 19125-1:2004 specification should be readable by implementations of this International Standard.

In this International Standard the following definition from OGC 01-009has been deprecated but is included here for the purposes of documenting backward compatibility:

<geodetic datum> ::= DATUM <left delimiter> <datum name> <wkt separator> <ellipsoid> [ <towgs84> ] <right delimiter>  

where ellipsoid is as described in C.3.1.

TOWGS84 is a form of abridged coordinate transformation (see 18.2) but inappropriately modelled as part of a geodetic datum definition (a geodetic datum definition should not include a relationship to WGS 84). This International Standard has no backward compatibility with the TOWGS84 object.WKT descriptions of geodetic datums written to the OGC 01-009specification will be readable by implementations of this International Standard only if the optional TOWGS84 object is not contained.

<vertical datum> ::= VERT_DATUM <left delimiter> <datum name> <wkt separator> <datum type> <right delimiter>  
<engineering datum> ::= LOCAL_DATUM <left delimiter> <datum name> <wkt separator> <datum type> <right delimiter>  

In OGC 01-009 datum type is a number but is otherwise not defined. This International Standard has no backward compatibility with the datum type object, and as a consequence has no backward compatibility with the keywords and objects VERT_DATUM and LOCAL_DATUM.

WKT descriptions of vertical and engineering datums written to the OGC 01-009specification are not readable by implementations of this International Standard.

C.3.4   Map projection

Map projection is defined in 9.3.

In this International Standard the following definition from ISO 19125-1:2004 and OGC 01-009 has been deprecated but is included here for the purposes of documenting backward compatibility:

<map projection> ::= PROJECTION <left delimiter> <name> <right delimiter> { <wkt separator> <projection parameter> }…  
<map projection parameter> ::= PARAMETER <left delimiter> < name> <wkt separator> <parameter value> <right delimiter>  
<parameter value> ::= <number>

EXAMPLE 1 

   PROJECTION["Transverse Mercator",
                   PARAMETER["Latitude of origin",0],
                   PARAMETER["Central meridian",-123],
                   PARAMETER["Scale factor",0.9996],
                   PARAMETER["False easting",500000],
                   PARAMETER["False northing",0]]

EXAMPLE 2 

       PROJECTION["UTM zone 10N",
                  PARAMETER["Latitude of natural origin",0],
                   PARAMETER["Longitude of natural origin",-123],
                   PARAMETER["Scale factor at natural origin",0.9996],
                   PARAMETER["FE",500000],
                   PARAMETER["FN",0]]

WKT strings that used this definition exhibit the following ambiguities:

  1. in the name attribute there is no clear distinction between the projection (the collection of method plus its parameters) and projection method. In this International Standard the two concepts have separate keywords CONVERSION and METHOD respectively. Implementations of earlier specifications have differed in their interpretation of name, some giving the projection name (such as “UTM zone 10N”) and others the method name (such as “Transverse Mercator”).
  2. the method formula, which is critical for interoperability, is implied through the method name, and relies on the method and parameter name strings being interpreted by the receiving application with the same meaning as used in the producing application.
  3. the units for the parameter values are ambiguous.

WKT descriptions of map projections written to the ISO 19125-1:2004 and OGC 01-009 specifications should be readable by implementations but the string may not be interpretable by machine.

C.3.5   Coordinate system

The WKT for describing a coordinate system is defined in 7.5.

NOTE        Both ISO 19125-1:2004 and OGC 01-009 use the term coordinate system, but with a different meaning to this International Standard. The term coordinate system as used in those earlier specifications equates to coordinate reference system in this International Standard. Coordinate system as defined in ISO 19111 and used in this International Standard is a different, more limited, concept.

In this International Standard the following definition from ISO 19125-1:2004 has been deprecated but is included here for the purposes of documenting backward compatibility:

<coordinate system> ::= <cs unit>

EXAMPLE 1      UNIT["German legal metre",1.0000135965]

WKT descriptions of coordinate systems written to the ISO 19125-1:2004 specification give a very incomplete description but should be readable by implementations of this International Standard. However the lack of definition of axis order may lead to ambiguity or serious error in interpretation of coordinates.

In this International Standard the following definition from OGC 01-009 has been deprecated but is included here for the purposes of documenting backward compatibility:

<coordinate system> ::= [ { <axis> <wkt separator> } ]…  <cs unit>
<axis> ::= AXIS <left delimiter> <name> <wkt separator> { north | east | south | west | up | down | other } <right delimiter>  

EXAMPLE 2      AXIS[“northing”,north]

EXAMPLE 3      AXIS[“easting”,east]

EXAMPLE 4      UNIT[“German legal metre”,1.0000135965]

<axis> was an optional attribute. If omitted it was implied that there were two axes whose directions were east and north respectively.

In OGC 01-009 the options for axis directions were significantly reduced compared to those in this International Standard. They were sufficient for most but not all geographic and projected CRSs. Provision was made for describing axes for a geocentric CRS but the prescribed directions were incorrectly defined. The provision for describing axes for an engineering (local) CRS were incomplete and usable in only a minority of cases.

WKT descriptions of coordinate systems written to the OGC 01-009 specification may give an incomplete description but should be readable by implementations of this International Standard.

C.4 Backward compatibility of coordinate reference systems

C.4.1   Geodetic CRS

Geodetic CRS is defined in Clause 8.In this International Standard the following definitions from ISO 19125‑1:2004 and OGC 01-009 have been deprecated but are included here for the purposes of documenting backward compatibility:

<geocentric crs> ::= GEOCCS <left delimiter> <crs name> <wkt separator> <datum> <wkt separator> <prime meridian> [ { <wkt separator> <axis> } ]…  <wkt separator> <axis unit> <right delimiter>  
<geographic crs> ::= GEOGCS <left delimiter> <crs name> <wkt separator> <datum> <wkt separator> <prime meridian> [ { <wkt separator> <axis> } ]…  <wkt separator> <axis unit> <right delimiter>  
<datum> ::= DATUM <left delimiter> < name> <wkt separator> <spheroid> <right delimiter>  
<spheroid> ::= { ELLIPSOID | SPHEROID } <left delimiter> <ellipsoid name> <wkt separator> <semi-major axis> <wkt separator> <inverse flattening> <right delimiter>  

In WKT strings that followed these definitions, the keyword omits the R in CRS. The inclusion of prime meridian is mandatory in the BNF (but not always included in WKT strings that have been produced!). The ellipsoid cannot be a sphere, and its semi-major axis must be given in metres. In ISO 19125-1:2004 the keyword is ELLIPSOID whilst in OGC 01-009 it is SPHEROID.

Axis name and direction are part of the OGC 01-009 definition but not included in ISO 19125-1:2004; coordinate system unit (called axis unit in the BNF in the older specifications) was required by both.

EXAMPLE 1   

   
   GEOGCS[“NAD83”,
     DATUM[“North American Datum 1983”,
       ELLIPSOID[“GRS 1980”,6378137.0,298.257222101],
     PRIMEM[“Greenwich”,0]],
     UNIT[“degree”,0.0174532925199433]]
    

EXAMPLE 2

      GEOGCS[“NAD83”,
     DATUM[“North American Datum 1983”,
       SPHEROID[“GRS 1980”,6378137.0,298.257222101],
     PRIMEM[“Greenwich”,0]],
     AXIS[“latitude”,NORTH],
     AXIS[“longitude”,EAST], 
     UNIT[“degree”,0.0174532925199433]]

If augmented to recognise the old keywords GEOCCS and GEOGCS, WKT descriptions of geocentric CRSs and geographic 2D CRSs written to the ISO 19125-1:2004 and OGC 01-009 specifications should be readable by implementations of this International Standard but may not be interpretable by machine.

The formal specifications of both ISO 19125-1:2004 and OGC 01-009 did not support WKT descriptions of geodetic CRSs having ellipsoidal 3D coordinate systems.

C.4.2   Projected CRS

Projected CRS is defined in Clause 9.In this International Standard the following definitions from ISO 19125‑1:2004 and OGC 01-009 have been deprecated but are included here for the purposes of documenting backward compatibility.

<projected crs> ::= PROJCS <left delimiter> <crs name> <wkt separator> <geogcs> <wkt separator> <projection> [ { <wkt separator> <axis> } ]…  <wkt separator> <axis unit> <right delimiter>  

<geogcs> and <projection> and their limitations are described in C.4.1 and C.3.4 respectively.

EXAMPLE 1

   PROJCS[NAD83 / UTM zone 10N,
   GEOGCS[“NAD83”,
       DATUM[North American Datum 1983",
         SPHEROID[“GRS 1980”,6378137.0,298.257222101],
       PRIMEM[“Greenwich”,0]],
     PROJECTION[“Transverse Mercator”],
     PARAMETER[“Latitude of origin”,0.0],
      (four additional parameters omitted for brevity)
    UNIT[“metre”,1.0]]

 

EXAMPLE 2

    PROJCS[NAD83 / UTM zone 10N,
    GEOGCS[“NAD83”,
       DATUM[“North American Datum 1983”,
        ELLIPSOID[“GRS 1980”,6378137.0,298.257222101],
       PRIMEM[“Greenwich”,0]],
       AXIS[“latitude”,NORTH],
       AXIS[“longitude”,EAST],
     PROJECTION[“UTM zone 10N”],
     PARAMETER[“Latitude of origin”,0.0],
      (four additional parameters omitted for brevity)
     AXIS[“easting”,EAST],
     AXIS[“northing”,NORTH],
     UNIT[“metre”,1.0]]

 

If augmented to recognise the old keyword PROJCS as an alias of PROJCRS, WKT descriptions of projected CRSs written to the ISO 19125-1:2004 and OGC 01-009 specifications should be readable by implementations that read strings conformant to this International Standard but the string  may not be interpretable by machine.

C.4.3   Vertical CRS and engineering (local) CRS

ISO 19125-1:2004 did not support these CRS types. The OGC 01-009 specification did do so. In this International Standard the following definitions from OGC 01-009 have been deprecated but are included here for the purposes of documenting backward compatibility:

<vertical CRS> ::= VERT_CS <left delimiter> <vertical CRS name> <wkt separator> <vertical datum> <wkt separator> <length unit> [ <wkt separator> <axis> ] <right delimiter>  
<engineering CRS> ::= LOCAL_CS <left delimiter> <engineering CRS name> <wkt separator> <engineering datum> <wkt separator> <length unit> [ <wkt separator> <axis> ] <right delimiter>  

As a consequence of the lack of backward compatibility with the component keywords and objects VERT_DATUM and LOCAL_DATUM objects as discussed in C.3.3, implementations reading strings conformant to this International Standard have no backward compatibility with the VERT_CS or LOCAL_CS objects.

C.4.4   Compound CRS

ISO 19125-1:2004 did not support this CRS type. The OGC 01-009 specification did do so. In this International Standard the following definition from OGC 01-009 has been deprecated but is included here for the purposes of documenting backward compatibility:

<compound CRS> ::= COMPD_CS <left delimiter> <compound CRS name> <wkt separator> <coordinate reference system> <wkt separator> <coordinate reference system> <right delimiter>  

This definition allows any combination of CRS types, for example two horizontal CRSs. This International Standard constrains permissible combinations. In practice WKT strings written to the OGC 01-009 specification are likely to be a combination permitted by this International Standard, one of which will be vertical and one of which will probably be geographic 2D or projected but could be engineering (local). However as a consequence of the lack of backward compatibility with the keywords and objects VERT_DATUM and LOCAL_DATUM objects as discussed in C.3.3 and C.4.3, this International Standard has no backward compatibility with the COMPD_CS object.

C.4.5   Fitted CS

OGC 01-009 describes a FITTED_CS object. This is functionally equivalent to ISO 19111 SC_DerivedCRS with the deriving conversion expressed as a CT_MathTransform and applied in the reverse direction (to the base CRS instead than from it). CT_MathTransform is basically equivalent to ISO 19111 CC_CoordinateOperation, except that CT_MathTransform is not restricted to operations on coordinates; for this reason CT_MathTransform does not have sourceCRS and targetCRS properties. This International Standard does not attempt to maintain backward compatibility with this FITTED_CS object because of the differences in the modelling.

C.5Backward compatibility of coordinate operations

OGC 01-009 defines a math transform object.

<math transform> ::= <param mt> | <concat mt> |  <inv mt> | <passthrough mt>  
<param mt> ::= PARAM_MT <left delimiter> <classification name> { <wkt separator> <operation parameter }… <right delimiter>  

The PARAM_MT object requires a subset of the attributes for <coordinate operation> defined in 17.1. However as it is missing several other attributes mandatory in <coordinate operation> (source and target CRSs, clear distinction between operation and operation method), implementations written to this International Standard have no backward compatibility with the math transform object.

C.6Mapping of tokens and keywords from previous versions of CRS WKT to this International Standard

Table C.2: Mapping of BNF tokens and keywords between previous versions of CRS WKT and this International Standard
19125-1:2004 OGC CTS 01-009 This document Comment
Coordinate Reference Systems
<coordinate system> <coordinate system> <coordinate reference system> ISO 19125-1:2004 uses the term SRS (Spatial Reference System). SRS is a superset which includes CRS and spatial referencing by geographic identifier. But in ISO 19125-1 only CRS concepts are described. Previous specifications of CRS WKT have used the term coordinate system for the ISO 19111 concept of coordinate reference system. In ISO 19111 and this International Standard, 'coordinate system' is used for a different concept, limited to describing the axes of a CRS.
<name> <cs name> <crs name>  
Geodetic CRS with geocentric Cartesian coordinate system
<geocentric cs> <geocentric cs> <geodetic crs>  
GEOCCS GEOCCS GEODCRS | GEODETICCRS  
Geodetic CRS with ellipsoidal 3D coordinate system
    <geodetic crs>  
(see comment) GEODCRS | GEODETICCRS In OGC 06-103r4 this concept appears as an extension to GEOGCS where a third axis is optional
Geodetic CRS with ellipsoidal 2D coordinate system
<geographic cs> <geographic cs> <geodetic crs>  
GEOGCS GEOGCS GEODCRS | GEODETICCRS  
Projected CRS
<projected cs> <projected cs> <projected crs>  
PROJCS PROJCS PROJCRS | PROJECTEDCRS  
<geogcs> <geogcs> <base geodetic crs> There is a change in the attributes of base crs compared to geogcs to clarify the attributes to be provided. In ISO 19125-1 and OGC 01-009 the axes are omitted in the examples (and in many implementations) but the BNF specification does not permit this.
GEOGCS GEOGCS BASEGEODCRS  
<name> <cs name> <base crs name>  
Vertical CRS
  <vert cs> <vertical crs>  
VERT_CS VERTCRS | VERTICALCRS  
Engineering CRS
  <local cs> <engineering crs>  
LOCAL_CS ENGCRS | ENGINEERINGCRS Conceptually equivalent to ISO 19111's engineering CRS.
Image CRS
    <image crs> Not previously specified.
IMAGECRS  
Parametric CRS
    <parametric crs> Not previously specified.
PARAMETRICCRS  
Temporal CRS
    <temporal crs> Not previously specified.
    TIMECRS  
Compound CRS
  <compd cs> <compound crs>  
COMPD_CS COMPOUNDCRS  
  <horz cs> <horizontal crs>  
  <head cs>   This has no equivalent in ISO 19111 which constrains the types of CRS allowed to form compound CRSs. If <head cs> meets the ISO 19111 constraint of being either a geographic 2D or a projected CRS, it can be mapped through <horizontal crs> to <geogCRS> or <projCRS> respectively.
  <tail cs>   This has no equivalent in ISO 19111 which constrains the types of CRS allowed to form compound CRSs. If <tail cs> meets the ISO 19111 constraint of being a vertical CRS it can be mapped to <vertical crs>.
Fitted CRS
  <fitted cs>   <fitted cs> has no equivalent in this International Standard as it combines the separate concepts of CRS and coordinate operation. Its function is partially covered through derived CRSs – see C.4.5.
FITTED_CS
<to base>
<base cs>
Datum
<datum> <datum> <geodetic datum>  
DATUM DATUM DATUM | GEODETICDATUM  
  <vert datum> <vertical datum>  
  VERT_DATUM VDATUM | VERTICALDATUM  
  <local datum> <engineering datum>  
  LOCAL_DATUM EDATUM | ENGINEERINGDATUM  
  <datum type>   Not clear from OGC 01-009 what this concept is. No equivalent in ISO 19111 or this International Standard.
<name> <name> <datum name>  
Ellipsoid
<ellipsoid> <spheroid> <ellipsoid>  
ELLIPSOID SPHEROID ELLIPSOID | SPHEROID  
<name> <name> <ellipsoid name>  
<semi-major axis> <semi-major axis> <semi-major axis>  
<inverse flattening> <inverse flattening> <inverse flattening>  
Prime meridian
<prime meridian> <prime meridian> <prime meridian>  
PRIMEM PRIMEM PRIMEM | PRIMEMERIDIAN  
<name> <name> <prime meridian name>  
<longitude> <longitude> <irm longitude>  
Map projection
<projection> <projection> <coordinate operation>  
PROJECTION PROJECTION CONVERSION 19125-1 and CTS 01-009 are not clear whether PROJECTION is the coordinate operation or the coordinate operation method. Implementations have differed in their interpretation.
PROJECTION PROJECTION METHOD | PROJECTION
<name> <name> <map projection name>  
<projection> <projection> <map projection method>  
<name> <name> <map projection method name>  
<parameter> <parameter> <map projection parameter>  
PARAMETER PARAMETER PARAMETER  
<name> <name> <parameter name>  
<value> <value> <parameter value>  
<unit> <unit> <map projection parameter unit>  
Coordinate System
  <twin axes> <coordinate system>  
AXIS AXIS  
  <axis order>  
Coordinate System
  <name> <axis name> In this document axis name is constrained by CRS type and in turn axis name constrains axis direction. These constraints were not previously specified.
  <axis abbreviation>  
(axis direction)   Enumerated list in WKT1.
Unit
<linear unit> <linear unit> <length unit>  
UNIT UNIT LENGTHUNIT | UNIT  
<angular unit> <angular unit> <angle unit>  
UNIT UNIT ANGLEUNIT | UNIT  
    <scale unit>  
UNIT UNIT SCALEUNIT | UNIT  
<unit name> <unit name> <unit name>  
<conversion factor> <conversion factor> <conversion factor>  
Identifier
  <authority> <identifier>  
AUTHORITY ID  
<name> <authority name>  
<code> <authority unique identifier> The types permitted are expanded in this International Standard.
  <version>  
Remark
    <remark> New to this International Standard.
Bound CRS
    <bound CRS>  
  BOUNDCRS  
<to WGS84> <abridged coordinate transformation>  
TOWGS84 ABRIDGEDTRANSFORMATION Similar concept but modelled completely differently.
<seven param>    
<dx> <parameter name>  
<dy> <parameter name>  
<dz> <parameter name>  
<ex> <parameter name>  
<ey> <parameter name>  
<ez> <parameter name>  
<ppm> <parameter name>  

 

Annex D
(informative)

Triaxial ellipsoid

The reference ellipsoid for the Earth for which the WKT string is defined in 8.2.1 is an oblate ellipsoid of revolution. A triaxial ellipsoid (figure D.1) may be required for planetary mapping and other applications. Their full CRS description is outside the scope of this International Standard.

Oblate and triaxial ellipsoids

Figure D.1 — Oblate and triaxial ellipsoids

A WKT string definition for a triaxial ellipsoid is:

<triaxial ellipsoid> ::= TRIAXIAL <left delimiter> <ellipsoid name> <wkt separator> <semi-major axis> <wkt separator> <semi-median axis> <wkt separator><semi-minor axis> <wkt separator> <triaxial ellipsoid unit> [ <wkt separator> <identifier> ]…  <right delimiter>  
<semi-major axis>    ::= <unsigned numeric literal>
<semi-median axis>    ::= <unsigned numeric literal>
<semi-minor axis>    ::= <unsigned numeric literal>
<triaxial ellipsoid unit>  ::= LENGTHUNIT <left delimiter> <unit name> <wkt separator> <conversion factor> [ <wkt separator> <identifier> ]…  <right delimiter>  
<unit name> ::= <quoted Latin text>
<conversion factor>    ::= <signed numeric literal>

The conversion factor shall be to metres and is the number of metres per unit.

EXAMPLE         TRIAXIAL[“Io 2009 IAU IAG”,1829400,1819400,1815700,
                           LENGTHUNIT[“metre”,1]]

NOTE        ‘Triaxial’ is an example of a user-defined keyword not described in the normative requirements of this document. Applications reading WKT conformant to this International Standard may ignore unrecognised keywords and their attributes.

 

Annex E
(informative)

Identifiers for coordinate operation methods and parameters

E.1 Introduction

To facilitate interoperability, the sending and receiving applications need to have a common understanding of the semantics of coordinate operation methods and parameters. Previous CRS WKT specifications used name strings as identifiers as the basis for this understanding. Names are often not good enough. The same name, for example “Stereographic” [map projection], may be associated with different formulas, the formula differences being significant. Conversely one shared concept may have very different names which are not readily seen to be synonyms, for example the map projection parameter “longitude of origin” and “central meridian”. A further difficulty has been the inconsistency in rendering of names.

Coordinate operation methods and their parameters that are frequently encountered in geographic information systems are documented in E.2 to E.5. These methods and their parameters have been codified in the EPSG Geodetic Parameter Dataset. Each method formula is included within the EPSG Dataset. Applications may use different formulas, but if these give equivalent results as those of EPSG then they are functionally the same.

NOTE        Unless otherwise noted, all methods use ellipsoidal formulas

Methods differ in their treatment of reversibility. Some methods use one formula for both forward and reverse computations, with the signs of some or all of the parameter values needing to be changed for the reverse case. Other methods include different forward and reverse formulas both of which utilise the same parameters and parameter values; most map projections are in this category. Yet other methods are not reversible. Some are theoretically not exactly reversible but for earth sciences can be considered to be reversible in practice. Detailed documentation of method formula and parameter reversibility is beyond the scope of Annex E. The EPSG Dataset documents the reversibility of the methods it describes.

Method definition including formula, parameters used in that formula and an example as given in the EPSG Dataset may be obtained by substitution of the relevant method code in the hyperlink:

http://www.epsg-registry.org/indicio/query?request=GetRepositoryItem&id=urn:ogc:def:method:EPSG::9802

The EPSG Dataset defines the order in which parameters should be listed. It is recommended that this order be followed in WKT strings.

Table E.1 summarises the methods and parameters given in the remainder of Annex E.

Table E.1: Coordinate operation methods and parameters
Table Clause Content
E.2 E.2 Map projection methods
E.3 E.3 Map projection parameters
E.4 E.4 Coordinate operation (excluding map projection) methods
E.5 E.5 Coordinate operation (excluding map projection) parameters

 

E.2 Map projection methods

Commonly encountered map projection methods are given in Table E.2. The parameters required by these methods are given in E.3.

Table E.2: Map projection methods
Coordinate operation method name Method name alias(es) EPSG Method code Codes of parameters used by this method
(refer to E.3)
Albers Equal Area Albers 9822 8821, 8822, 8823. 8824, 8826, 8827
American Polyconic Polyconic 9818 8801, 8802, 8806, 8807
Cassini-Soldner Cassini 9806 8801, 8802, 8806, 8807
Hotine Oblique Mercator (variant A) Rectified skew orthomorphic 9812 8811, 8812, 8813, 8814, 8815, 8806, 8807
Hotine Oblique Mercator (variant B) Rectified skew orthomorphic 9815 8811, 8812, 8813, 8814, 8815, 8816, 8817
Lambert Azimuthal Equal Area Lambert Equal Area
LAEA 		9820 8801, 8802, 8806, 8807
Lambert Conic Conformal (1SP) Lambert Conic Conformal
LCC 		9801 8801, 8802, 8805, 8806, 8807
Lambert Conic Conformal (2SP) Lambert Conic Conformal
LCC 		9802 8821, 8822, 8823. 8824, 8826, 8827
Mercator (variant A) Mercator 9804 8801, 8802, 8805, 8806, 8807
Mercator (variant B) Mercator 9805 8823, 8802, 8806, 8807
Oblique stereographic Double stereographic 9809 8801, 8802, 8805, 8806, 8807
Transverse Mercator Gauss-Boaga
Gauss-Krüger
TM 		9807 8801, 8802, 8805, 8806, 8807
Transverse Mercator (South Orientated) Gauss-Conform 9808 8801, 8802, 8805, 8806, 8807

 

E.3 Map projection parameters

The parameters required by the map projection methods given in E.2 are described in Table E.3.

Table E.3: Map projection parameters
Parameter code Coordinate operation parameter name
(alias(es)) 		Parameter description Unit type
8801 latitude of natural origin
(latitude of origin) 		geodetic latitude of the point from which the values of both the geographical coordinates on the ellipsoid and the grid coordinates on the projection are deemed to increment or decrement for computational purposes Alternatively: geodetic latitude of the point which in the absence of application of false coordinates has grid coordinates of (0,0). angle
8802 longitude of natural origin
(longitude of origin)
(central meridian) 		geodetic longitude of the point from which the values of both the geographical coordinates on the ellipsoid and the grid coordinates on the projection are deemed to increment or decrement for computational purposes Alternatively: geodetic longitude of the point which in the absence of application of false coordinates has grid coordinates of (0,0). angle
8805 scale factor at natural origin
(scale factor) 		factor by which the map grid is reduced or enlarged during the projection process, defined by its value at the natural origin scale
8806 false easting value assigned to the abscissa (east or west) axis of the projection grid at the natural origin length
8807 false northing value assigned to the ordinate (north or south) axis of the projection grid at the natural origin length
8811 latitude of projection centre latitude of the point at which the azimuth of the central line for an oblique projection is defined angle
8812 longitude of projection centre longitude of the point at which the azimuth of the central line for an oblique projection is defined angle
8813 azimuth of initial line direction (north zero, east of north being positive) of the great circle which is the centre line of an oblique projection The azimuth is given at the projection centre. angle
8814 angle from rectified to skew grid angle at the natural origin of an oblique projection through which the natural coordinate reference system is rotated to make the projection north axis parallel with true north angle
8815 scale factor on initial line factor by which the map grid is reduced or enlarged during the projection process, defined by its value at the projection centre scale
8816 easting at projection centre
(false easting) 		easting value assigned to the projection centre length
8817 northing at projection centre
(false northing) 		northing value assigned to the projection centre length
8821 latitude of false origin
(latitude of origin) 		geodetic latitude of the point which is not the natural origin and at which grid coordinate values false easting and false northing are defined angle
8822 longitude of false origin
(longitude of origin) 		geodetic longitude of the point which is not the natural origin and at which grid coordinate values false easting and false northing are defined angle
8823 latitude of 1st standard parallel geodetic latitude of one of the parallels of intersection of the cone with the ellipsoid. It is normally but not necessarily that nearest to the pole Scale is true along this parallel. angle
8824 latitude of 2nd standard parallel geodetic latitude of one of the parallels at which the cone intersects with the ellipsoid. It is normally but not necessarily that nearest to the equator Scale is true along this parallel. angle
8826 easting at false origin
(false easting) 		easting value assigned to the false origin length
8827 northing at false origin
(false northing) 		northing value assigned to the false origin length

 

E.4 Coordinate transformation methods

Commonly encountered coordinate transformation methods are given in Table E.4. The parameters required by these methods are given in E.5.

Table E.4: Coordinate transformation methods
Coordinate operation method name Method name alias(es) EPSG Method code Codes of parameters used by this method
(refer to E.5)
Geocentric translations (geocentric domain) Geocentric translations 1031 8605, 8606, 8607
Position Vector transformation (geocentric domain) Position Vector 7-param. transformation
Bursa-Wolf
Helmert 		1033 8605, 8606, 8607, 8608, 8609, 8610, 8611
Coordinate Frame Rotation (geocentric domain) Coordinate Frame Rotation
Bursa-Wolf
Helmert 		1032 8605, 8606, 8607, 8608, 8609, 8610, 8611
Molodensky-Badekas (geocentric domain) Molodensky-Badekas 1034 8605, 8606, 8607, 8608, 8609, 8610, 8611, 8617, 8618, 8667
NTv2   9615 8656
NADCON   9613 8657, 8658
Vertical Offset   9616 8603
Longitude rotation   9601 8602

 

E.5 Coordinate transformation parameters

The parameters required by the map projection methods given in E.4 are described in Table E.5.

Table E.5: Coordinate transformation parameters
Parameter code Coordinate operation parameter name
(alias(es)) 		Parameter description
8603 Vertical Offset
(dH) 		difference between the height or depth values of a point in the target and source coordinate reference systems
8605 X-axis translation
(dX)
(tX) 		difference between the X values of a point in the target and source coordinate reference systems
8606 Y-axis translation
(dY)
(tY) 		difference between the Y values of a point in the target and source coordinate reference systems
8607 Z-axis translation
(dZ)
(tZ) 		difference between the Z values of a point in the target and source coordinate reference systems
8608 X-axis rotation
(rX) 		angular difference between the Y and Z axes directions of target and source coordinate reference systems This is a rotation about the X axis as viewed from the origin looking along that axis. The particular method defines which direction is positive, and what is being rotated (point or axis).
8609 Y-axis rotation
(rY) 		angular difference between the X and Z axes directions of target and source coordinate reference systems This is a rotation about the Y axis as viewed from the origin looking along that axis. The particular method defines which direction is positive, and what is being rotated (point or axis).
8610 Z-axis rotation
(rZ) 		angular difference between the X and Y axes directions of target and source coordinate reference systems This is a rotation about the Z axis as viewed from the origin looking along that axis. The particular method defines which direction is positive, and what is being rotated (point or axis).
8611 Scale difference
(dS) 		the ratio of a length between two points in target and source coordinate reference systems. If a distance of 100 km in the source coordinate reference system translates into a distance of 100.001 km in the target coordinate reference system, the scale difference is 1 ppm (the ratio being 1.000001).
8617 Ordinate 1 of evaluation point value of the first ordinate of the evaluation point
8618 Ordinate 2 of evaluation point value of the second ordinate of the evaluation point
8656 Latitude and longitude difference file name of the [path and] file containing latitude and longitude differences
8657 Latitude difference file name of the [path and] file containing latitude differences
8658 Longitude difference file name of the [path and] file containing longitude differences
8667 Ordinate 3 of evaluation point value of the third ordinate of the evaluation point

 

Revision History

 

Date Release Author Paragraph modified Description
2012-05-22   Victor Minor   Draft submitted by IOGP.
2012-08-06 12-063 Roger Lott Annex B added following CRS DWG discussion. As submitted to ISO TC211 as NWIP document N3383.
2012-12-23 12-063r1 Roger Lott   Updated to reflect comment from ISO meeting 2012-12-09.
2013-07-25 12-063r2 Roger Lott Document re-written. As submitted to ISO TC211 as CD for DIS ballot document N3596 following OGC SWG deliberations.
2014-03-01 12-063r3 Roger Lott Document re-written to accord with decisions made at 2013-11-13 editing committee. As submitted to ISO TC211 as final CD for DIS ballot document N3728 with additional minor editorial corrections shown in red in clauses 6.7, 12.2, B.1 and B.8 following subsequent OGC SWG discussions.
2014-04-14 12-063r4 Roger Lott Changes discussed at SWG implemented. DateTime changed to be consistent with ISO 8601, pixelinCell added to image datum, distinction between old and new WKT keywords added to annex B clause 8.
2014-11-21 12-063r5 Roger Lott Document Minor editorial corrections identified during ISO DIS ballot and parallel OGC comment review.

 

Bibliography

[1]   ISO 19125-1:2004, Geographic information — Simple feature access — Part 1: Common architecture
[2]   OGC Project Document 99-036, OpenGIS Simple Features Specification for SQL, revision 1.1
[3]   OGC Project Document 06-103r4, Simple feature access — Part 1: Common architecture
[4]   OGC Project Document 01-009, Implementation Specification: Coordinate Transformation Services, revision 1.00
[5]   OGC Project Document 09-083r3, GeoAPI 3.0 Implementation Standard