I. Keywords
The following are keywords to be used by search engines and document catalogues.
wkb, ewkb, ogcdoc, OGC document, Extended WKB, Well Known Binary, Binary Geography
II. Preface
This OGC Community Standard was an outcome of the development of GeoSPARQL 1.3, to satisfy the requirement for a Normative Reference for a binary encoding that supports more than two dimensions and includes a spatial reference system.
III. Security considerations
No security considerations have been made for this document.
IV. Submitters
All questions regarding this submission should be directed to the editor or submitters:
Joseph Abhayaratna (editor) Geoscape Australia
Nicholas Car (contributor) Kurrawong AI
Arkadiusz Chadzynski (contributor) Ontotext
Paul Cripps (contributor) DSTL
Timo Homburg (contributor) Mainz University of Applied Sciences
Matthew Perry (contributor) Oracle
V. Source of the content for this OGC document
The majority of the content in this OGC document is a direct copy of the content originally contained in the following documents: https://github.com/postgis/postgis/blob/master/doc/ZMSgeoms.txt and https://libgeos.org/specifications/wkb/#extended-wkb. No normative changes have been made to the content. This OGC document does contain content not in the original sources. Specifically, the Abstract, Keywords, Preface, Terms and Definitions and Reference sections in this document are not found in the original sources.
VI. Validity of content
The Submission Team has reviewed and certified that the snapshot content in this Community Standard is true and accurate. The snapshot for OGC Extended WKB Version 1.0 was taken on 9 July 2025 from the libGEOS website.
VII. Future work
The GeoSPARQL SWG will attempt to keep this OGC Community Standard in sync with developments within the Open Source community that maintains the PostGIS and libGEOS documents. Changes to this Community Standard apart from the sections maintained by the GeoSPARQL SWG will not occur.
VIII. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
Defence Science & Technology Labs (DSTL)
Geoscape Australia
Kurrawong AI
Mainz University of Applied Sciences
Ontotext
Oracle
1. Scope
The Well Known Binary (WKB) representation of geometry was defined by the Open Geospatial Consortium (OGC) in 2004 as part of the Simple Features Access Part 1 Common Architecture standard. It is used to encode two dimensional geometries, and does not cater for storage of a spatial reference identifier (SRID).
As GeoSPARQL 1.3 is an update of the standard to support 3D use cases, and an SRS is a required component of the encoding, WKB does not explicitly meet the needs of a binary encoding for GeoSPARQL. Extended WKB, defined by the libGEOS project, recognises these shortcomings of the standard and extends it through backwards compatible addition of extra dimensions (e.g., Z and M that are commonly used by GIS applications) and an SRID. All content used for this document was sourced from the following webpages: https://github.com/postgis/postgis/blob/master/doc/ZMSgeoms.txt and https://libgeos.org/specifications/wkb/#extended-wkb. As such, the OGC does not assert any Intellectual Property over this standard.
Therefore, this OGC Community Standard was an outcome of the development of GeoSPARQL 1.3, to satisfy the requirement of a Normative Reference for a binary encoding.
2. Conformance
The following binary strings will be deemed to conform with the standard:
All binary strings that conform with WKB.
All WKB binary strings containing extensions that conform with the Extended Well Known Binary section of this standard.
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.
Simple Features Access — Part 1: Common Architecture. International Organization for Standardization (2004)
GeoSPARQL. Open Geospatial Consortium (2024)
Geographic Information — Reference model — Part 1. International Organization for Standardization (2014)
The following non-normative documents are used as the main source of this document. The bulk of this standard is directly copied from these two reference documents. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.
Z values in Simple Features co-ordinates. Gawne-Cain, Adam (1999)
ZM values and SRID for Simple Features. Santilli, Sandro (2005)
Extended Well Known Binary. libGEOS.
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.
Geospatial Information Systems
[SOURCE: Geographic Information — Reference model — Part 1]
Spatial Reference Identifier
[SOURCE: Geographic Information — Reference model — Part 1]
The Well-known Binary Representation for Geometry
[SOURCE: Simple Features Access — Part 1: Common Architecture]
a) A geometry can have either 2, 3 or 4 dimensions. b) 3rd dimension of a 3d geometry can either represent Z or M (3DZ or 3DM). c) 4d geometries contain both Z and M (in this order). d) M and Z values are associated with every vertex. e) M and Z values are undefined within surface interiors.
Any ZM-Geometry can be converted into a 2D geometry by discarding all its Z and M values. The resulting 2D geometry is the “shadow” of the ZM-Geometry. 2D geometries cannot be safely converted into ZM-Geometries, since their Z and M values are undefined, and not necessarily zero.
[SOURCE: ZM values and SRID for Simple Features]
5. Conventions
5.1. Identifiers
The normative provisions in this standard are denoted by the URI
http://www.opengis.net/spec/ewkb/1.0
All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.
6. Extended Well Known Binary (EWKB)
6.1. Introduction
The original WKB specification made no allowances for adding extra dimensions, like Z and M, that are common in GIS applications. It also had no space for embedding a spatial reference identifier (SRID), which made it unusable as a database import/export format.
The “Extended WKB” variant is a superset of the standard WKB, which allows applications to optionally add extra dimensions, and optionally embed an SRID.
The presence of extra dimensions shall be indicated by adding flag bits to the existing wkbType that appears in all WKB geometries.
6.2. Extensions to Well Known Binary format
The 2d OpenGIS Simple Features specification has the following geometry types:
enum wkbGeometryType {
wkbPoint = 1,
wkbLineString = 2,
wkbPolygon = 3,
wkbMultiPoint = 4,
wkbMultiLineString = 5,
wkbMultiPolygon = 6,
wkbGeometryCollection = 7
}
Listing 1 — OpenGIS Geometry Types
Z values in Simple Features co-ordinates (99-402r2) introduces a Z-presence flag (wkbZ) which shall be logically ORed with the type to specify the presence of a Z coordinate:
wkbZ = 0x80000000
Listing 2 — Z Flag
Extended Well Known Binary shall use an M-presence flag (wkbM) to allow for XY, XYM, XYZ and XYZM geometries, and a SRID-presence flag to allow for embedded SRID:
wkbM = 0x40000000
wkbSRID = 0x20000000
Listing 3 — M Flag
Possible resulting geometry types are:
enum wkbGeometryTypeZ {
wkbPoint = 1,
wkbLineString = 2,
wkbPolygon = 3,
wkbMultiPoint = 4,
wkbMultiLineString = 5,
wkbMultiPolygon = 6,
wkbGeometryCollection = 7,
// | 0x80000000
wkbPointZ = 0x80000001,
wkbLineStringZ = 0x80000002,
wkbPolygonZ = 0x80000003,
wkbMultiPointZ = 0x80000004,
wkbMultiLineStringZ = 0x80000005,
wkbMultiPolygonZ = 0x80000006,
wkbGeometryCollectionZ = 0x80000007,
// | 0x40000000
wkbPointM = 0x40000001,
wkbLineStringM = 0x40000002,
wkbPolygonM = 0x40000003,
wkbMultiPointM = 0x40000004,
wkbMultiLineStringM = 0x40000005,
wkbMultiPolygonM = 0x40000006,
wkbGeometryCollectionM = 0x40000007,
// | 0x40000000 | 0x80000000
wkbPointZM = 0xC0000001,
wkbLineStringZM = 0xC0000002,
wkbPolygonZM = 0xC0000003,
wkbMultiPointZM = 0xC0000004,
wkbMultiLineStringZM = 0xC0000005,
wkbMultiPolygonZM = 0xC0000006,
wkbGeometryCollectionZM = 0xC0000007,
// | 0x20000000
wkbPointS = 0x20000001,
wkbLineStringS = 0x20000002,
wkbPolygonS = 0x20000003,
wkbMultiPointS = 0x20000004,
wkbMultiLineStringS = 0x20000005,
wkbMultiPolygonS = 0x20000006,
wkbGeometryCollectionS = 0x20000007,
// | 0x20000000 | 0x80000000
wkbPointZS = 0xA0000001,
wkbLineStringZS = 0xA0000002,
wkbPolygonZS = 0xA0000003,
wkbMultiPointZS = 0xA0000004,
wkbMultiLineStringZS = 0xA0000005,
wkbMultiPolygonZS = 0xA0000006,
wkbGeometryCollectionZS = 0xA0000007,
// | 0x20000000 | 0x40000000
wkbPointMS = 0x60000001,
wkbLineStringMS = 0x60000002,
wkbPolygonMS = 0x60000003,
wkbMultiPointMS = 0x60000004,
wkbMultiLineStringMS = 0x60000005,
wkbMultiPolygonMS = 0x60000006,
wkbGeometryCollectionMS = 0x60000007,
// | 0x20000000 | 0x40000000 | 0x80000000
wkbPointZMS = 0xE0000001,
wkbLineStringZMS = 0xE0000002,
wkbPolygonZMS = 0xE0000003,
wkbMultiPointZMS = 0xE0000004,
wkbMultiLineStringZMS = 0xE0000005,
wkbMultiPolygonZMS = 0xE0000006,
wkbGeometryCollectionZMS = 0xE0000007,
}
Listing 4 — ZM Geometries
If the SRID flag is set, its value shall be encoded as a 4-byte integer right after the type integer.
If only wkbZ or wkbM flags are set, Point coordinates shall be XYZ or XYM respectively.
If both wkbZ and wkbM flags are set, Point coordinates shall be XYZM (Z first).
6.3. Empty Geometry Handling
For geometries with a counter (nPoints for LineString, nRings for Polygon, nPoints for MultiPoint, nLines for MultiLineString, nPolygons for MultiPolygon, nGeometries for GeometryCollection), an Empty geometry can be represented by setting the counter to zero.
For an empty Point, which does not have a counter, an empty geometry is signalled by setting all coordinates to an IEEE-754 quiet NaN value (big endian 0×7ff8000000000000 or little endian 0x000000000000f87f depending on the endian value of the WKB).
6.4. Illustrative Examples
Here is the structure and flagging for a 3D point — the dimensionaly flag indicates a Z dimension, and the point member therefore has three coordinates.
wkbZ = 0x80000000
wkbM = 0x40000000
wkbSRID = 0x20000000
enum wkbGeometryTypeZ {
wkbPoint = 1,
wkbLineString = 2,
wkbPolygon = 3,
wkbMultiPoint = 4,
wkbMultiLineString = 5,
wkbMultiPolygon = 6,
wkbGeometryCollection = 7,
// | 0x80000000
wkbPointZ = 0x80000001,
wkbLineStringZ = 0x80000002,
wkbPolygonZ = 0x80000003,
wkbMultiPointZ = 0x80000004,
wkbMultiLineStringZ = 0x80000005,
wkbMultiPolygonZ = 0x80000006,
wkbGeometryCollectionZ = 0x80000007,
}
WKBPointZ {
byte byteOrder; // wkbXDR or wkbNDR
uint32 wkbType; // wkbPointZ = (wkbPoint | wkbZ) = 0x80000001
Point {
Double x;
Double y;
Double z;
}
}
Listing 5 — 3D Point
When the optional wkbSRID is added to the wkbType, an SRID number is inserted after the wkbType number.
WKBPointS {
byte byteOrder; // wkbXDR or wkbNDR
uint32 wkbType; // wkbPointS = (wkbPoint | wkbSRID) = 0x20000001
uint32 SRID;
Point {
Double x;
Double y;
}
}
Listing 6 — Point With SRID
The dimensionality and SRID flags may also be combined. Here is a 3D point with an embedded SRID.
WKBPointS {
byte byteOrder; // wkbXDR or wkbNDR
uint32 wkbType; // wkbPointS = (wkbPoint | wbkZ | wkbSRID) = 0xA0000001
uint32 SRID;
Point {
Double x;
Double y;
Double z;
}
}
Listing 7 — 3D Point With SRID
The following example demonstrates a ZM-Point geometry at the location (10,20) with:
a Z-value of 30,
an M-value of 40, and
a SRID of 4326.
WKBPoint {
byte byteOrder; // wkbXDR or wkbNDR
uint32 wkbType; // (wkbPoint+wkbZ+wkbM+wkbSRID) =
// 0xE0000001
uint32 SRID; // 4326
Point {
Double x; // 10.0
Double y; // 20.0
Double z; // 30.0
Double m; // 40.0
}
}
Listing 8 — ZM Point With SRID
6.5. Writing Extended WKB
/* Read a linestring */
const char* linestring = "LINESTRING(0 0 1, 1 1 1, 2 1 2)";
GEOSWKBReader* reader = GEOSWKBReader_create();
GEOSGeom* geom = GEOSWKTReader_read(reader, linestring);
GEOSSetSRID(geom, 4326);
/* Write it out as Extended WKB */
GEOSWKBWriter* writer = GEOSWKBWriter_create();
/* Next line only needed before GEOS 3.12 */
GEOSWKBWriter_setOutputDimension(writer, 3);
GEOSWKBWriter_setFlavor(writer, GEOS_WKB_EXTENDED);
GEOSWKBWriter_setIncludeSRID(writer, 1);
/* Generate the WKB , and store the output length */
size_t wkb_size;
unsigned char* wkb = GEOSWKBWriter_write(writer, geom, &wkb_size);
/* do something ... */
/* Free the WKB */
GEOSFree(wkb);
GEOSGeom_destroy(geom);
Listing 9 — Writing EWKB
Annex A
(informative)
Revision History
Table — Revision History
| Date | Release | Author | Primary clauses modified | Description |
|---|---|---|---|---|
| 2025-07-10 | 0.1 | GeoSPARQL SWG | all | initial version blending quoted content from original sources |
Bibliography
[1] GEOS contributors: Extended Well Known Binary, https://libgeos.org/specifications/wkb/#extended-wkb
[2] Sandro Santilli: ZM values and SRID for Simple Features, https://github.com/postgis/postgis/blob/master/doc/ZMSgeoms.txt