I. Abstract
This part of the OGC Simple Features (SF) Standard describes an encoding of Simple Features (per Part 1) as a Well-Known Binary (WKB) Representation. The WKB for Geometry (WKBGeometry) provides a portable representation of a geometric object as a contiguous stream of bytes. WKB permits geometric object to be exchanged between a client and a service implementation in binary form.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, features, vectors, simple features
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 Binary Representation (WKB) for Geometry provides a portable representation of a geometric object as a contiguous stream of bytes. WKB permits geometric objects to be exchanged between an SQL/CLI client and an SQL-implementation in binary form.
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 Binary Representation of Geometry
7.1. Component overview
WKBGeometry permits geometric objects to be exchanged between an SQL/CLI client and an SQL-implementation in binary form.
7.2. Component description
7.2.1. Introduction
WKBGeometry is obtained by serializing a geometric object as a sequence of numeric types drawn from the set {Unsigned Integer, Double} and then serializing each numeric type as a sequence of bytes using one of two well defined, standard, binary representations for numeric types (NDR, XDR). The specific binary encoding (NDR or XDR) used for a geometry representation is described by a one-byte tag that precedes the serialized bytes. The only difference between the two encodings of geometry is one of byte order: the XDR encoding is Big Endian, and the NDR encoding is Little Endian.
7.2.2. Numeric type definitions
An Unsigned Integer is a 32-bit (4-byte) data type that encodes a nonnegative integer in the range [0,4,294,967,295].
A Double is a 64-bit (8-byte) double precision datatype that encodes a double precision number using the IEEE 754 Bibliography double precision format.
The above definitions are common to both XDR and NDR.
7.2.3. A common list of codes for geometric types
In this clause and in other places in this multipart standard, geometric types are identified by integer codes. To keep these codes in synchrony and to reserve sections for future use, we define a list here for all geometric object types in this standard or planned for future releases. The shaded codes in the table below are for future use and do not reflect types used here.
Table 1 — Integer codes for geometric types
| Type | Code | Type | Code | |
| Geometry | 0 | Geometry Z | 1000 | |
| Point | 1 | Point Z | 1001 | |
| LineString | 2 | LineString Z | 1002 | |
| Polygon | 3 | Polygon Z | 1003 | |
| MultiPoint | 4 | MultiPoint Z | 1004 | |
| MultiLineString | 5 | MultiLineString Z | 1005 | |
| MultiPolygon | 6 | MultiPolygon Z | 1006 | |
| GeometryCollection | 7 | GeometryCollection Z | 1007 | |
| CircularString | 8 | CircularString Z | 1008 | |
| CompoundCurve | 9 | CompoundCurve Z | 1009 | |
| CurvePolygon | 10 | CurvePolygon Z | 1010 | |
| MultiCurve | 11 | MultiCurve Z | 1011 | |
| MultiSurface | 12 | MultiSurface Z | 1012 | |
| Curve | 13 | Curve Z | 1013 | |
| Surface | 14 | Surface Z | 1014 | |
| PolyhedralSurface | 15 | PolyhedralSurface Z | 1015 | |
| TIN | 16 | TIN Z | 1016 | |
| Geometry M | 2000 | Geometry ZM | 3000 | |
| Point M | 2001 | Point ZM | 3001 | |
| LineString M | 2002 | LineString ZM | 3002 | |
| Polygon M | 2003 | Polygon ZM | 3003 | |
| MultiPoint M | 2004 | MultiPoint ZM | 3004 | |
| MultiLineString M | 2005 | MultiLineString ZM | 3005 | |
| MultiPolygon M | 2006 | MultiPolygon ZM | 3006 | |
| GeometryCollection M | 2007 | GeometryCollection ZM | 3007 | |
| CircularString M | 2008 | CircularString ZM | 3008 | |
| CompoundCurve M | 2009 | CompoundCurve ZM | 3009 | |
| CurvePolygon M | 2010 | CurvePolygon ZM | 3010 | |
| MultiCurve M | 2011 | MultiCurve ZM | 3011 | |
| MultiSurface M | 2012 | MultiSurface ZM | 3012 | |
| Curve M | 2013 | Curve ZM | 3013 | |
| Surface M | 2014 | Surface ZM | 3014 | |
| PolyhedralSurface M | 2015 | PolyhedralSurface ZM | 3015 | |
| TIN M | 2016 | TIN ZM | 3016 |
7.2.4. XDR (Big Endian) encoding of numeric types
The XDR representation of an Unsigned Integer is Big Endian (most significant byte first). The XDR representation of a Double is Big Endian (sign bit is first byte).
7.2.5. NDR (Little Endian) encoding of numeric types
The NDR representation of an Unsigned Integer is Little Endian (least significant byte first). The NDR representation of a Double is Little Endian (sign bit is last byte).
7.2.6. Conversions between the NDR and XDR representations of WKBGeometry
Conversion between the NDR and XDR data types for Unsigned Integer and Double numbers is a simple operation involving reversing the order of bytes within each Unsigned Integer or Double number in the representation.
7.2.7. Relationship to other COM and CORBA data transfer protocols
The XDR representation for Unsigned Integer and Double numbers described above is also the standard representation for Unsigned Integer and for Double number in the CORBA Standard Stream Format for Externalized Object Data that is described as part of the CORBA Externalization Service Specification Bibliography.
The NDR representation for Unsigned Integer and Double number described above is also the standard representation for Unsigned Integer and for Double number in the DCOM protocols that is based on DCE RPC and NDR Bibliography.
7.2.8. Description of WKBGeometry representations
WKBGeometry is described below. The basic building block is the representation for a Point, which consists of a number Doubles, depending on the coordinate reference system in use for the geometry. The representations for other geometric objects are built using the representations for geometric objects that have already been defined.
// Basic Type definitions
// byte : 1 byte
// uint32 : 32 bit unsigned integer (4 bytes)
// double : double precision number (8 bytes)
// Building Blocks : Coordinate, LinearRing
Point {
double x;
double y}
PointZ {
double x;
double y;
double z}
PointM {
double x;
double y;
double m}
PointZM {
double x;
double y;
double z;
double m}
LinearRing {
uint32 numPoints;
Point points[numPoints]}
LinearRingZ {
uint32 numPoints;
PointZ points[numPoints]}
LinearRingM {
uint32 numPoints;
PointM points[numPoints]}
LinearRingZM {
uint32 numPoints;
PointZM points[numPoints]}
enum WKBByteOrder {
wkbXDR = 0, // Big Endian
wkbNDR = 1 // Little Endian
}
enum WKBGeometryType {
wkbPoint = 1,
wkbLineString = 2,
wkbPolygon = 3,
wkbTriangle = 17
wkbMultiPoint = 4,
wkbMultiLineString = 5,
wkbMultiPolygon = 6,
wkbGeometryCollection = 7,
wkbPolyhedralSurface = 15,
wkbTIN = 16
wkbPointZ = 1001,
wkbLineStringZ = 1002,
wkbPolygonZ = 1003,
wkbTrianglez = 1017
wkbMultiPointZ = 1004,
wkbMultiLineStringZ = 1005,
wkbMultiPolygonZ = 1006,
wkbGeometryCollectionZ = 1007,
wkbPolyhedralSurfaceZ = 1015,
wkbTINZ = 1016
wkbPointM = 2001,
wkbLineStringM = 2002,
wkbPolygonM = 2003,
wkbTriangleM = 2017
wkbMultiPointM = 2004,
wkbMultiLineStringM = 2005,
wkbMultiPolygonM = 2006,
wkbGeometryCollectionM = 2007,
wkbPolyhedralSurfaceM = 2015,
wkbTINM = 2016
wkbPointZM = 3001,
wkbLineStringZM = 3002,
wkbPolygonZM = 3003,
wkbTriangleZM = 3017
wkbMultiPointZM = 3004,
wkbMultiLineStringZM = 3005,
wkbMultiPolygonZM = 3006,
wkbGeometryCollectionZM = 3007,
wkbPolyhedralSurfaceZM = 3015,
wkbTinZM = 3016,
}
WKBPoint {
byte byteOrder;
static uint32 wkbType = 1;
Point point}
WKBPointZ {
byte byteOrder;
static uint32 wkbType = 1001;
PointZ point}
WKBPointM {
byte byteOrder;
static uint32 wkbType = 2001;
PointM point}
WKBPointZM {
byte byteOrder;
static uint32 wkbType = 3001;
PointZM point}
WKBLineString {
byte byteOrder;
static uint32 wkbType = 2;
uint32 numPoints;
Point points[numPoints]}
WKBLineStringZ {
byte byteOrder;
static uint32 wkbType = 1002;
uint32 numPoints;
PointZ points[numPoints]}
WKBLineStringM {
byte byteOrder;
static uint32 wkbType = 2002;
uint32 numPoints;
PointM points[numPoints]}
WKBLineStringZM {
byte byteOrder;
static uint32 wkbType = 3002;
uint32 numPoints;
PointZM points[numPoints]}
WKBPolygon {
byte byteOrder;
static uint32 wkbType = 3;
uint32 numRings;
LinearRing rings[numRings]}
WKBPolygonZ {
byte byteOrder;
static uint32 wkbType = 1003;
uint32 numRings;
LinearRingZ rings[numRings]}
WKBPolygonM {
byte byteOrder;
static uint32 wkbType = 2003;
uint32 numRings;
LinearRingM rings[numRings]}
WKBPolygonZM {
byte byteOrder;
static uint32 wkbType = 3003;
uint32 numRings;
LinearRingZM rings[numRings]}
WKBTriangle {
byte byteOrder;
static uint32 wkbType = 17;
uint32 numRings;
LinearRing rings[numRings]}
WKBTriangleZ {
byte byteOrder;
static uint32 wkbType = 10 17;
uint32 numRings;
LinearRingZ rings[numRings]}
WKBTriangleM {
byte byteOrder;
static uint32 wkbType = 20 17;
uint32 numRings;
LinearRingM rings[numRings]}
WKBTriangleZM {
byte byteOrder;
static uint32 wkbType = 30 17;
uint32 numRings;
LinearRingZM rings[numRings]}
WKBPolyhedralSurface {
byte byteOrder;
static uint32 wkbType = 15;
uint32 numPolygons;
WKBPolygon polygons[numPolygons]}
WKBPolyhedralSurfaceZ {
byte byteOrder;
static uint32 wkbType=1015;
uint32 numPolygons;
WKBPolygonZ polygons[numPolygons]}
WKBPolyhedralSurfaceM {
byte byteOrder;
static uint32 wkbType=2015;
uint32 numPolygons;
WKBPolygonM polygons[numPolygons]}
WKBPolyhedralSurfaceZM {
byte byteOrder;
static uint32 wkbType=3015;
uint32 numPolygons;
WKBPolygonZM polygons[numPolygons]}
WKBTIN {
byte byteOrder;
static uint32 wkbType=16;
uint32 numPolygons;
WKBPolygon polygons[numPolygons]}
WKBTINZ {
byte byteOrder;
static uint32 wkbType=1016;
uint32 numPolygons;
WKBPolygonZ polygons[numPolygons]}
WKBTINM {
byte byteOrder;
static uint32 wkbType=2016;
uint32 numPolygons;
WKBPolygonM polygons[numPolygons]}
WKBTINZM {
byte byteOrder;
static uint32 wkbType=3016;
uint32 numPolygons;
WKBPolygonZM polygons[numPolygons]}
WKBMultiPoint {
byte byteOrder;
static uint32 wkbType=4;
uint32 numPoints;
WKBPoint points[numPoints]}
WKBMultiPointZ {
byte byteOrder;
static uint32 wkbType=1004;
uint32 numPoints;
WKBPointZ points[numPoints]}
WKBMultiPointM {
byte byteOrder;
static uint32 wkbType=2004;
uint32 numPoints;
WKBPointM points[numPoints]}
WKBMultiPointZM {
byte byteOrder;
static uint32 wkbType=3004;
uint32 numPoints;
WKBPointZM points[numPoints]}
WKBMultiLineString {
byte byteOrder;
static uint32 wkbType = 5;
uint32 numLineStrings;
WKBLineString lineStrings[numLineStrings]}
WKBMultiLineStringZ {
byte byteOrder;
static uint32 wkbType = 1005;
uint32 numLineStrings;
WKBLineStringZ lineStrings[numLineStrings]}
WKBMultiLineStringM {
byte byteOrder;
static uint32 wkbType = 2005;
uint32 numLineStrings;
WKBLineStringM lineStrings[numLineStrings]}
WKBMultiLineStringZM {
byte byteOrder;
static uint32 wkbType = 3005;
uint32 numLineStrings;
WKBLineStringZM lineStrings[numLineStrings]}
WKBMultiPolygon {
byte byteOrder;
static uint32 wkbType = 6;
uint32 numPolygons;
WKBPolygon polygons[numPolygons]}
WKBMultiPolygonZ {
byte byteOrder;
static uint32 wkbType = 1006;
uint32 numPolygons;
WKBPolygonZ polygons[numPolygons]}
WKBMultiPolygonM {
byte byteOrder;
static uint32 wkbType = 2006;
uint32 numPolygons;
WKBPolygonM polygons[numPolygons]}
WKBMultiPolygonZM {
byte byteOrder;
static uint32 wkbType = 3006;
uint32 numPolygons;
WKBPolygonZM polygons[numPolygons]}
WKBGeometryCollection {
byte byte_order;
static uint32 wkbType = 7;
uint32 numGeometries;
WKBGeometry geometries[numGeometries]}
WKBGeometryCollectionZ {
byte byte_order;
static uint32 wkbType = 1007;
uint32 numGeometries;
WKBGeometryZ geometries[numGeometries]}
WKBGeometryCollectionM {
byte byte_order;
static uint32 wkbType = 2007;
uint32 numGeometries;
WKBGeometryM geometries[numGeometries]}
WKBGeometryCollectionZM {
byte byte_order;
static uint32 wkbType = 3007;
uint32 numGeometries;
WKBGeometryZM geometries[numGeometries]}
WKBGeometry {Union {
WKBPoint point;
WKBLineString linestring;
WKBPolygon polygon;
WKBTriangle triangle
WKBPolyhedralSurface polyhedralsurface
WKBTIN tin
WKBMultiPoint mpoint;
WKBMultiLineString mlinestring;
WKBMultiPolygon mpolygon;
WKBGeometryCollection collection;
}};
WKBGeometryZ {Union {
WKBPointZ pointz;
WKBLineStringZ linestringz;
WKBPolygonZ polygonz;
WKBTriangleZ trianglez
WKBPolyhedralSurfaceZ Polyhedralsurfacez;
WKBTinZ tinz
WKBMultiPointZ mpointz;
WKBMultiLineStringZ mlinestringz;
WKBMultiPolygonZ mpolygonz;
WKBGeometryCollectionZ collectionz;
}};
WKBGeometryM {Union {
WKBPointM pointm;
WKBLineStringM linestringm;
WKBPolygonM polygonm;
WKBTriangleM trianglem
WKBPolyhedralSurfaceM Polyhedralsurfacem;
WKBTinM tinm
WKBMultiPointM mpointm;
WKBMultiLineStringM mlinestringm;
WKBMultiPolygonM mpolygonm;
WKBGeometryCollectionM collectionm;
}};
WKBGeometryZM {Union {
WKBPointZM pointzm;
WKBLineStringZM linestringzm;
WKBPolygonZM polygonzm;
WKBTriangleZM trianglezm
WKBPolyhedralSurfaceM Polyhedralsurfacezm;
WKBTinZM tinzm
WKBMultiPointZM mpointzm;
WKBMultiLineStringZM mlinestringzm;
WKBMultiPolygonZ mpolygonzm;
WKBGeometryCollectionZM collectionzm;
}};
Listing 1
Figure 1 shows a pictorial representation of the Well-known Representation for a Polygon with one outer ring and one inner ring.
Figure 1 — Well-known Binary Representation for a geometric object in NDR format (B = 1) of type Polygon (T = 3) with 2 LinearRings (NR = 2) each LinearRing having 3 points (NP = 3)
7.2.9. Assertions for Well-known Binary Representation for Geometry
WKBGeometry is designed to represent instances of Geometry Types. Any WKBGeometry instance shall satisfy the assertions for the type of Geometry that it describes (OGC YY-SEQ, see 6.1).
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 |
Bibliography
[] CORBA: CORBA services: Common Object Services Specification, Ch 8. Externalization Service Specification, OMG. Available at http://www.omg.org/technology/documents/corba_spec_catalog.htm
[] Microsoft: Distributed Component Object Model — DCOM 1.0, Microsoft Corporation. Available at http://www.microsoft.com/com/tech/DCOM.asp
[] IEEE: IEEE 754, IEEE Standard for binary Floating-Point Arithmetic (1985)