I. Abstract
This part of the OGC Simple Features (SF) Standard describes an encoding of Simple Features (per Part 1) in a Well-Known Text (WKT) Representation. Each Geometry Type has a Well-known Text Representation that can be used both to construct new instances of the type and to convert existing instances to textual form for alphanumeric display.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, features, vectors, simple features, geometry
III. Preface
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium 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.
IV. Security considerations
No security considerations have been made for this Standard.
V. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- Oracle
- Esri
VI. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
| Name | Affiliation |
| Keith Ryden | Esri |
| Scott Simmons | Open Geospatial Consortium |
VII. Contributors
This Standard was initially edited by Dr. John Herring. Parts 1, 2, and 3 are substantively the work of Dr. Herring and the original submission team.
1. Scope
The Well-Known Text Representation for Geometry (WKTGeometry) provides provides a portable representation of a geometric object that can be used both to construct new instances of the type and to convert existing instances to textual form for alphanumeric display.
2. Conformance
*NOTE TO EDITORS* Conformance for Parts 1-3 was defined in the original Simple Features Access Part 1 document as follows.
“In order to conform to this standard, an implementation shall satisfy the requirements of one or more test suites specified in the other parts of ISO 19125.”
Meaning that the SQL Part (or legacy CORBA and others) had Abstract Test Suites. We must consider whether to genericize those Test Suites to something for these parts.
*END NOTE*
3. Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC: ISO/IEC 13249-3:2016, Information technology — Database languages — SQL multimedia and application packages — Part 3: Spatial. International Organization for Standardization, International Electrotechnical Commission, Geneva (2016). https://www.iso.org/standard/60343.html.
ISO: ISO 19107:2019, Geographic information — Spatial schema. International Organization for Standardization, Geneva (2019). https://www.iso.org/standard/66175.html.
ISO: ISO 19111:2019, Geographic information — Referencing by coordinates. International Organization for Standardization, Geneva (2019). https://www.iso.org/standard/74039.html.
ISO: ISO 19133:2005, Geographic information — Location-based services — Tracking and navigation. International Organization for Standardization, Geneva (2005). https://www.iso.org/standard/32551.html.
OGC Simple Features — Part 1: Architecture
4. Terms and definitions
This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.
This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.
For the purposes of this document, the following additional terms and definitions apply.
This document uses the terms defined in Sub-clause 5.3 of OGC 06-121r9, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.
For the purposes of this document, the following additional terms and definitions apply.
set that represents the limit of an entity
Note 1 to entry: Boundary is most commonly used in the context of geometry, where the set is a collection of points or a collection of objects that represent those points. In other arenas, the term is used metaphorically to describe the transition between an entity and the rest of its domain of discourse.
[SOURCE: ISO 19107:2019]
Clause 4.15 that contains all direct positions whose distance from a specified geometric object is less than or equal to a given distance
[SOURCE: ISO 19107:2019]
union of the interior and boundary of a topological or geometric object
[SOURCE: ISO 19107:2019]
one of a sequence of n-numbers designating the position of a Clause 4.19 in n-dimensional space
Note 1 to entry: In a coordinate reference system, the numbers shall be qualified by units.
[SOURCE: ]
number of measurements or axes needed to describe a position in a Clause 4.7
[SOURCE: ISO 19107:2019]
Clause 4.7 that is related to the real world by a datum
set of mathematical rules for specifying how coordinates are to be assigned to each Clause 4.19
[SOURCE: ISO 19111:2019]
topological 1-dimensional Clause 4.16, representing the continuous image of a line
The term “1-dimensional” refers to the topological dimension of the primitive. In this case, it means that each point not on the boundary is an element in a topological open set within the curve which is isomorphic to an open interval (0, 1). For this standard, the coordinate dimension can be 2 (for x and y), 3 (with z or m added), or 4 (with both z and m added). The ordinates x, y and z are spatial, and the ordinate m is a measure.
Note 1 to entry: The boundary of a curve is the set of points at either end of the curve. If the curve is a cycle, the two ends are identical, and the curve (if topologically closed) is considered to not have a boundary. The first point is called the start point, and the last is the end point. Connectivity of the curve is guaranteed by the “continuous image of a line” clause. A topological theorem states that a continuous image of a connected set is connected.
[SOURCE: ISO 19107:2019]
position described by a single set of coordinate within a Clause 4.6
[SOURCE: ISO 19107:2019]
last Clause 4.19 of a Clause 4.8
Note 1 to entry: End and start point are related to the orientation of the curve. Any curve representation can be “flipped” reversing the end and start, without changing the image of the curve as a set of points (direct positions).
[SOURCE: ISO 19107:2019]
difference between the universe and the Clause 4.3
Note 1 to entry: The concept of exterior is applicable to both topological and geometric complexes.
[SOURCE: ISO 19107:2019]
abstraction of real world phenomena
Note 1 to entry: A feature may occur as a type or an instance. Feature type or feature instance is used when only one is meant.
characteristic of a Clause 4.12
Note 1 to entry: A feature attribute has a name, a data type, and a value domain associated to it. A feature attribute for a feature instance also has an attribute value taken from the value domain. No restrictions are implied here as to the type of attributes a feature may have. The “geometries” associated to features are just one type of feature attribute.
set of disjoint geometric primitives where the Clause 4.1 of each geometric primitive can be represented as the union of other geometric primitives of smaller dimension within the same set
Geometric complexes are often referred to as clean geometry or implicit topology, meaning that the various topological inconsistencies have usually been removed to obtain the “completeness” of the boundary representation.
Note 1 to entry: The geometric primitives in the set are disjoint in the sense that no direct position is interior to more than one geometric primitive. The set is closed under boundary operations, meaning that for each element in the geometric complex, there is a collection (also a geometric complex) of geometric primitives that represents the boundary of that element. Recall that the boundary of a point (the only 0D primitive object type in geometry) is empty. Thus, if the largest dimension geometric primitive is a solid (3D), the composition of the boundary operator in this definition terminates after at most 3 steps. It is also the case that the boundary of any object is a cycle.
[SOURCE: ISO 19107:2019]
spatial object representing a geometric set
Regardless of the representation, the feature is usually assumed to be topologically closed, in that points on the boundary of the feature are assumed to belong to the feature, even though those points may not explicitly be represented in the geometric object. When representing a topological entity, geometric objects are assumed to not contain their boundaries.
Note 1 to entry: A geometric object consists of a geometric primitive, a collection of geometric primitives, or a geometric complex treated as a single entity. A geometric object may be the spatial representation of an object such as a feature or a significant part of a feature.
[SOURCE: ISO 19107:2019]
Clause 4.15 representing a single, connected, homogeneous element of space
Note 1 to entry: Geometric primitives are non-decomposed objects that represent information about geometric configuration. They include points, curves, surfaces, and solids. Contrary to common usage, a geometric primitive is open, decomposable (can be broken into smaller objects) because of the inherent continuity of space. Primitive are those things that have not been chosen for such decomposition.
[SOURCE: ISO 19107:2019]
set of all direct positions that are on a Clause 4.15 but which are not on its Clause 4.1
Note 1 to entry: The interior of a topological object is the continuous image of the interior of any of its geometric realizations. This is not included as a definition because it follows from a theorem of topology. Another way of saying this is that any point on a geometric object is in its interior if it can be placed inside a homeomorphic image of an open set in the Euclidean space of the object’s topological dimension.
[SOURCE: ISO 19107:2019]
also linear positioning system
positioning system that measures distance from a reference point along a route (feature)
Note 1 to entry: The system includes the complete set of procedures for determining and retaining a record of specific points along a linear feature such as the location reference method(s) together with the procedures for storing, maintaining, and retrieving location information about points and segments on the highways. [NCHRP Synthesis 21, 1974]
[SOURCE: ISO 19133:2005]
topological 0-dimensional Clause 4.16 representing a position
Note 1 to entry: The boundary of a point is the empty set.
[SOURCE: ISO 19107:2019]
Clause 4.12 with all geometric attributes described piecewise by straight line or planar interpolation between sets of points
For curves, each part (called a “segment” in ISO 19107) has two control points (the “start point”) and (the “end point”). Any other on the segment can be described using a real number parameter between 0.0 and 1.0 in the “vector” equation: .\
For surfaces, each part (called a “patch” in ISO 19107) can be viewed as a polygon which can be broken into triangles each with three control points , and . Any other in the triangle can be described using 3 non-negative real numbers whose sum is 1.0 (called “barycentric coordinates”) ; ; in the vector equation: .
[[start=point]] === start point
first Clause 4.19 of a Clause 4.8
Note 1 to entry: Interpolation is used on curves and surfaces, which by their nature are an infinite set of points and thus not suitable to finite exhaustive representations. Each such geometric entity is decomposed into parts which can be expressed locally as parametric, linear combinations of “control points.” This is described at length in ISO 19107.
[SOURCE: ISO 19107:2019]
topological 2-dimensional Clause 4.16 (4.15), locally representing a continuous image of a region of a plane
Note 1 to entry: The boundary of a surface is the set of oriented, closed curves that delineate the limits of the surface.
[SOURCE: ISO 19107:2019]
6. Conventions
6.1. Identifiers
The normative provisions in this standard are denoted by the URI
http://www.opengis.net/spec/{standard}/{m.n}
All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.
6.2. Abbreviated terms
API Application Program Interface
COM Component Object Model
CORBA Common Object Request Broker Architecture
DCE Distributed Computing Environment
DCOM Distributed Component Objected Model
DE-9IM Dimensionally Extended Nine-Intersection Model
FID Feature ID column in the implementation of feature tables based on predefined data types
GID Geometry ID column in the implementation of feature tables based on predefined data types
IEEE Institute of Electrical and Electronics Engineers, Inc.
MM Multimedia
NDR Little Endian byte order encoding
OLE Object Linking and Embedding
RPC Remote Procedure Call
SQL Structured query language, not an acronym, pronounced as “sequel”
SQL/MM SQL Multimedia and Application Packages
SRID Spatial Reference System Identifier
SRTEXT Spatial Reference System Well Known Text
UDT User Defined Type
UML Unified Modeling Language
WKB Well-Known Binary (representation for example, geometry)
WKT Well-Known Text
WKTR Well-Known Text Representation
XDR Big Endian byte order encoding
6.3. Symbols
n-Dimensional, where n may be any integer
n-Dimensional coordinate space, where n may be any integer
empty set, the set having no members
intersection, operation on two or more sets
union, operation on two or more sets
difference, operation on two sets
is a member of, relation between an element and a set
is not a member of
is a proper subset of, i.e., a smaller set not containing all of the larger
is a subset of
if and only if, logical equivalence between statements
implies, logical implication where the second follows from the first statement
there exists
for all
∋ such that
Function “f” from domain “D” to range “R”
set of “X” such that the statement “s” is TRUE
and, logical intersection
or, logical union
not, logical negation
equal
not equal
less than or equal to
less than
greater than or equal to
greater than
topological boundary operator, mapping a geometric object to its boundary
7. Well-known Text Representation for Geometry
7.1. Component overview
Each Geometry Type has a Well-known Text Representation that can be used both to construct new instances of the type and to convert existing instances to textual form for alphanumeric display.
7.2. Component description
7.2.1. BNF Introduction
The WKTGeometry is defined below using BNF.
The notation “{}” denotes an optional token within the braces; the braces do not appear in the output token list.
The notation “( )” groups a sequence of tokens into a single token; the parentheses do not appear in the output token list.
The notation “*” after a token denotes the optional use of multiple instances of that token.
A character string without any modifying symbols denotes an instance of that character string as a single token.
The notation “|” denotes a choice of two tokens, and do not appear in the output token list,
The notation “< >” denotes a production defined elsewhere in the list or a basic type.
The notation “:=” is a production and the grammar on the left may be replaced with the grammar on the right of this symbol. Production is terminated when no undefined production equations are left unresolved.
The text representation of the instantiable Geometry Types implemented shall conform to this grammar. Well known text is case insensitive. Where human readability is important (as in the examples in this standard), an “upper camel-case” where each embedded word is capitalized, should be used.
NOTE
All productions are segregated by coordinate type. This means that any two subelements of any element will always have the same coordinate type, which will be the coordinate type of the larger containing element.
The grammar in this and the following 4 clauses has been designed to support a compact and readable textual representation of geometric objects. The representation of a geometric object that consists of a set of homogeneous components does not include the tags for each embedded component. This first set of productions is to define a double precision literal.
Table 1
| <x> ::= | <signed numeric literal> |
| <y> ::= | <signed numeric literal> |
| <z> ::= | <signed numeric literal> |
| <m> ::= | <signed numeric literal> |
| <quoted name> ::= | <double quote> <name> <double quote> |
| <name> ::= | <letters> |
| <letters> ::= | (<letter>)* |
| <letter> ::= | <simple Latin letter>|<digit>|<special> |
| <simple Latin letter> ::= | <simple Latin upper case letter> |<simple Latin lower case letter> |
| <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> |
| <exact numeric literal> ::= | <unsigned integer> {<decimal point>{<unsigned integer>}} |<decimal point><unsigned integer> |
| <signed integer> ::= | {<sign>}<unsigned integer> |
| <unsigned integer> ::= | (<digit>)* |
| <left delimiter> ::= | <left paren>|<left bracket> must match balancing right delimiter |
| <right delimiter> ::= | <right paren>|<right bracket> must match balancing left delimiter |
| <special> ::= | <right paren>|<left paren>|<minus sign> |<underscore>|<period>|<quote>|<space> |
| <sign> ::= | <plus sign> | <minus sign> |
| <decimal point> ::= | <period> | <comma> |
| <empty set> ::= | EMPTY |
| <minus sign> ::= | - |
| <left paren> ::= | ( |
| <right paren> ::= | ) |
| <left bracket> ::= | [ |
| <right bracket> ::= | ] |
| <period> ::= | . |
| <plus sign> ::= | + |
| <double quote> ::= | “ |
| <quote> ::= | ‘ |
| <comma> | , |
| <underscore> ::= | _ |
| <digit> ::= | 0|1|2|3|4|5|6|7|8|9 |
| <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 |
| <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 |
| <space>= | ” “ unicode “U+0020” (space) |
7.2.2. BNF Productions for Two-Dimension Geometry WKT
The following BNF defines two-dimensional geometries in (x, y) coordinate spaces. With the exception of the addition of polyhedral surfaces, these structures are unchanged from earlier editions of this standard.
Table 2
| <point> ::= | <x> <y> |
| <geometry tagged text> ::= | <point tagged text> | <linestring tagged text> | <polygon tagged text> | <triangle tagged text> | <polyhedralsurface tagged text> | <tin tagged text> | <multipoint tagged text> | <multilinestring tagged text> | <multipolygon tagged text> | <geometrycollection tagged text> |
| <point tagged text> ::= | point <point text> |
| <linestring tagged text> ::= | linestring <linestring text> |
| <polygon tagged text> ::= | polygon <polygon text> |
| <polyhedralsurface tagged text> ::= | polyhedralsurface <polyhedralsurface text> |
| <triangle tagged text> ::= | triangle <polygon text> |
| <tin tagged text> | tin <polyhedralsurface text> |
| <multipoint tagged text> ::= | multipoint <multipoint text> |
| <multilinestring tagged text> ::= | multilinestring <multilinestring text> |
| <multipolygon tagged text> ::= | multipolygon <multipolygon text> |
| <geometrycollection tagged text> ::= | geometrycollection <geometrycollection text> |
| <point text> ::= | <empty set> | <left paren> <point> <right paren> |
| <linestring text> ::= | <empty set> | <left paren> <point> {<comma> <point>}* <right paren> |
| <polygon text> ::= | <empty set> | <left paren> <linestring text> {<comma> <linestring text>}* <right paren> |
| <polyhedralsurface text> ::= | <empty set> | <left paren> <polygon text> {<comma> <polygon text>}* <right paren> |
| <multipoint text> ::= | <empty set> | <left paren> <point text> {<comma> <point text>}* <right paren> |
| <multilinestring text> ::= | <empty set> | <left paren> <linestring text> {<comma> <linestring text>}* <right paren> |
| <multipolygon text> ::= | <empty set> | <left paren> <polygon text> {<comma> <polygon text>}* <right paren> |
| <geometrycollection text> ::= | <empty set> | <left paren> <geometry tagged text> {<comma> <geometry tagged text>}* <right paren> |
7.2.3. BNF Productions for Three-Dimension Geometry WKT
The following BNF defines geometries in 3 dimensional (x, y, z) coordinates.
Table 3
| <point z> ::= | <x> <y> <z> |
| <geometry z tagged text> ::= | <point z tagged text> |<linestring z tagged text> |<polygon z tagged text> |<polyhedronsurface z tagged text> |<triangle tagged text> |<tin tagged text> |<multipoint z tagged text> |<multilinestring z tagged text> |<multipolygon z tagged text> |<geometrycollection z tagged text> |
| <point z tagged text> ::= | point z <point z text> |
| <linestring z tagged text> ::= | linestring z <linestring z text> |
| <polygon z tagged text> ::= | polygon z <polygon z text> |
| <polyhedralsurface z tagged text> ::= | polyhedralsurface z <polyhedralsurface z text> |
| <triangle z tagged text> ::= | triangle z <polygon z text> |
| <tin z tagged text> | tin z <polyhedralsurface z text> |
| <multipoint z tagged text> ::= | multipoint z <multipoint z text> |
| <multilinestring z tagged text> ::= | multilinestring z <multilinestring z text> |
| <multipolygon z tagged text> ::= | multipolygon z <multipolygon z text> |
| <geometrycollection z tagged text> ::= | geometrycollection z <geometrycollection z text> |
| <point z text> ::= | <empty set> | <left paren> <point z> <right paren> |
| <linestring z text> ::= | <empty set> | <left paren> <point z> {<comma> <point z>}* <right paren> |
| <polygon z text> ::= | <empty set> | <left paren> <linestring z text> {<comma> <linestring z text>}* <right paren> |
| <polyhedralsurface z text> ::= | <empty set> | <left paren> <polygon z text> {<comma> <polygon z text>}* <right paren> |
| <multipoint z text> ::= | <empty set> | <left paren> <point z text> {<comma> <point z text>}* <right paren> |
| <multilinestring z text> ::= | <empty set> | <left paren> <linestring z text> {<comma> <linestring z text>}* <right paren> |
| <multipolygon z text> ::= | <empty set> | <left paren> <polygon z text> {<comma> <polygon z text>}* <right paren> |
| <geometrycollection z text> ::= | <empty set> | <left paren> <geometry tagged z text> {<comma> <geometry tagged z text>}* <right paren> |
7.2.4. BNF Productions for Two-Dimension Measured Geometry WKT
The following BNF defines two-dimensional geometries in (x, y) coordinate spaces. In addition, each coordinate carries an “m” ordinate value that is part of some linear reference system.
Table 4
| <point m> ::= | <x> <y> <m> |
| <geometry m tagged text> ::= | <point m tagged text> |<linestring m tagged text> |<polygon m tagged text> |<polyhedralsurface m tagged text> |<triangle tagged m text> |<tin tagged m text> |<multipoint m tagged text> |<multilinestring m tagged text> |<multipolygon m tagged text> |<geometrycollection m tagged text> |
| <point m tagged text> ::= | point m <point m text> |
| <linestring m tagged text> ::= | linestring m <linestring m text> |
| <polygon m tagged text> ::= | polygon m <polygon m text> |
| <polyhedralsurface m tagged text> ::= | polyhedralsurface m <polyhedralsurface m text> |
| <triangle m tagged text> ::= | triangle m <polygon m text> |
| <tin m tagged text> | tin m <polyhedralsurface m text> |
| <multipoint m tagged text> ::= | multipoint m <multipoint m text> |
| <multilinestring m tagged text> ::= | multilinestring m <multilinestring m text> |
| <multipolygon m tagged text> ::= | multipolygon m <multipolygon m text> |
| <geometrycollection m tagged text> ::= | geometrycollection m <geometrycollection m text> |
| <point m text> ::= | <empty set> | <left paren> <point m> <right paren> |
| <linestring m text> ::= | <empty set> | <left paren> <point m> {{<comma> <point m>}+ <right paren> |
| <polygon m text> ::= | <empty set> | <left paren> <linestring m text> {<comma> <linestring m text>}* <right paren> |
| <polyhedralsurface m text> ::= | <empty set> | <left paren> <polygon m text> {<comma> <polygon m text>}* <right paren> |
| <multipoint m text> ::= | <empty set> | <left paren> <point m text> {<comma> <point m text>}* <right paren> |
| <multilinestring m text> ::= | <empty set> | <left paren> <linestring m text> {<comma> <linestring m text>}* <right paren> |
| <multipolygon m text> ::= | <empty set> | <left paren> <polygon m text> {<comma> <polygon m text>}* <right paren> |
| <geometrycollection m text> ::= | <empty set> | <left paren> <geometry tagged m text> {<comma> <geometry tagged m text>}* <right paren> |
7.2.5. BNF Productions for Three-Dimension Measured Geometry WKT
The following BNF defines three-dimensional geometries in (x, y, z) coordinate spaces. In addition, each coordinate carries an “m” ordinate value that is part of some linear reference system.
Table 5
| <point zm> ::= | <x> <y> <z> <m> |
| <geometry zm tagged text> ::= | <point zm tagged text> |<linestring zm tagged text> |<polygon zm tagged text> |<polyhedralsurface zm tagged text> |<triangle zm tagged text> |<tin zm tagged text> |<multipoint zm tagged text> |<multilinestring zm tagged text> |<multipolygon zm tagged text> |<geometrycollection zm tagged text> |
| <point zm tagged text> ::= | point zm <point zm text> |
| <linestring zm tagged text> ::= | linestring zm <linestring zm text> |
| <polygon zm tagged text> ::= | polygon zm <polygon zm text> |
| <polyhedralsurface zm tagged text> ::= | polyhedralsurface zm <polyhedralsurface zm text> |
| <triangle zm tagged text> ::= | triangle zm <polygon zm text> |
| <tin zm tagged text> | tin zm <polyhedralsurface zm text> |
| <multipoint zm tagged text> ::= | multipoint zm <multipoint zm text> |
| <multipoint zm tagged text> ::= | multipoint zm <multipoint zm text> |
| <multilinestring zm tagged text> ::= | multilinestring zm <multilinestring zm text> |
| <multipolygon zm tagged text> ::= | multipolygon zm <MultiPolygon zm text> |
| <geometrycollection zm tagged text> ::= | geometrycollection zm <geometrycollection zm text> |
| <point zm text> ::= | <empty set> | <left paren> <point zm> <right paren> |
| <linestring zm text> ::= | <empty set> | <left paren> <point z> {<comma> <point z>}* <right paren> |
| <polygon zm text> ::= | <empty set> | <left paren> <linestring zm text> {<comma> <linestring zm text>}* <right paren> |
| <polyhedralsurface zm text> ::= | <empty set> | <left paren> { <polygon zm text {<comma> <polygon zm text>}*) <right paren> |
| <multipoint zm text> ::= | <empty set> | <left paren> <point zm text> {<comma> <point zm text>}* <right paren> |
| <multilinestring zm text> ::= | <empty set> | <left paren> <linestring zm text> {<comma> <linestring zm text>}* <right paren> |
| <multipolygon zm text> ::= | <empty set> | <left paren> <polygon zm text> {<comma> <polygon zm text>}* <right paren> |
| <geometrycollection zm text> ::= | <empty set> | <left paren> <geometry tagged zm text> {<comma> <geometry tagged zm text>}* <right paren> |
7.2.6. Examples
Examples of textual representations of Geometry are shown in Table 2. The coordinates are shown as integer values; in general they may be any double precision value.
NOTE: The examples of POINTZ, POINTM, and POINTZM at the bottom of Table 6. This same style for distinguishing 2D points from 3D points and from 2D or 3D points with M value can be applied to LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, and GEOMETRYCOLLECTION types.
Table 6 — Example WKTGeometry
| Geometry Type | Text Literal Representation | Comment |
| Point | Point (10 10) | a Point |
| LineString | LineString (10 10, 20 20, 30 40) | a LineString with 3 points |
| Polygon | Polygon 10 10, 10 20, 20 20, 20 15, 10 10 | a Polygon with 1 exteriorRing and 0 interiorRings |
| Multipoint | MultiPoint 10 10), (20 20 | a MultiPoint with 2 points |
| MultiLineString | MultiLineString ( (10 10, 20 20), (15 15, 30 15) ) | a MultiLineString with 2 linestrings |
| MultiPolygon | MultiPolygon ( 10 10, 10 20, 20 20, 20 15, 10 10, 60 60, 70 70, 80 60, 60 60 ) | a MultiPolygon with 2 polygons |
| GeomCollection | GeometryCollection ( POINT (10 10), POINT (30 30), LINESTRING (15 15, 20 20) ) | a GeometryCollection consisting of 2 Point values and a LineString value |
| Polyhedron | Polyhedron Z ( 0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0, 0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0, 0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0, 1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0, 0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0, 0 0 1, 1 0 1, 1 1 1, 0 1 1. 0 0 1 ) | A polyhedron cube, corner at the origin and opposite corner at (1, 1, 1) |
| Tin | Tin Z ( 0 0 0, 0 0 1, 0 1 0, 0 0 0, 0 0 0, 0 1 0, 1 0 0, 0 0 0, 0 0 0, 1 0 0, 0 0 1, 0 0 0, 1 0 0, 0 1 0, 0 0 1, 1 0 0, ) | A tetrahedron (4 triangular faces), corner at the origin and each unit coordinate digit |
| Point | Point Z (10 10 5) | a 3D Point |
| Point | Point ZM (10 10 5 40) | the same 3D Point with M value of 40 |
| Point | Point M (10 10 40) | a 2D Point with M value of 40 |
8. Media Types for any data encoding(s)
A section describing the MIME-types to be used is mandatory for any standard involving data encodings. If no suitable MIME type exists in http://www.iana.org/assignments/media-types/index.html then this section may be used to define a new MIME type for registration with IANA.
Annex A
(informative)
Revision History
Table A.1
| Date | Release | Editor | Primary clauses modified | Description |
|---|---|---|---|---|
| 2023-10-27 | 1.3 | S. Simmons | all | split v. 1.2.1 into parts |