Spatial formats
Meaning and scope
A spatial format represents a geometry for storage or exchange. Encoding turns a spatial value into that representation; decoding reads the representation back into a spatial value. A format is distinct from the geometry model and from the coordinate operation needed to change a reference system.
This page provides an informative explanation independent of library APIs. Normative foundations, vendor extensions and implementation capabilities have separate authority; accepting a format does not establish complete conformance.
Informative explanation
Formats and purposes
| Representation | Kind and authority | Typical purpose | Reference handling |
|---|---|---|---|
| Geometry WKT | Standard text; OGC / SQL/MM | Readable geometry exchange and inspection. | No embedded SRID in the cited grammars. |
| Geometry WKB | Standard binary; OGC / SQL/MM | Geometry exchange as bytes. | No embedded SRID in the cited layouts. |
| EWKT | PostGIS textual extension | Geometry text carrying additional reference information. | Can include an SRID=...; prefix. |
| EWKB | PostGIS binary extension | Binary exchange retaining extended geometry metadata. | Can embed SRID metadata. |
| GeoJSON | JSON interchange; RFC 7946 | Geographic geometries and application features. | Fixed geographic reference; no alternate-CRS declaration. |
| DBMS internal representation | Vendor-defined | Database or driver storage/transport. | Header or metadata depends on the vendor. |
The WKT/WKB rows refer to the editions listed under Normative foundations. EWKT/EWKB refer to the PostGIS documentation, not additional OGC requirements. A hexadecimal string is a textual encoding of binary bytes; hexadecimal WKB and hexadecimal EWKB retain their different binary layouts.
WKT and WKB
Geometry WKT names the geometry and writes its coordinates using nested text structures. WKB encodes the geometry type, coordinates and component structure as bytes, with a byte-order marker. In OGC 06-103r4, 0 means big-endian and 1 little-endian; integers use 32 bits and ordinates use 64-bit IEEE 754 doubles (8.2.1–8.2.2, 8.2.8).
The cited OGC edition covers XY, XYZ, XYM and XYZM: WKT distinguishes Z, M
and ZM; WKB distinguishes dimensional type codes (7.2.2–7.2.5, 8.2.8).
Z support is therefore not inherently an extension. The
coordinate dimensions reference explains why XYZ and
XYM are distinct despite both having three components.
Informative WKT examples: these illustrate the OGC Point grammars, not a particular parser's support or a declaration of coordinate units.
POINT (10 20)
POINT Z (10 20 30)
POINT M (10 20 5)
POINT ZM (10 20 30 5)
POINT EMPTY
Geometry WKT and CRS WKT describe different objects. The former describes a geometry; the latter describes a reference system. Neither a geometry's numeric tuple nor its layout supplies a complete CRS definition. See the CRS reference.
Extended representations
PostGIS EWKT and EWKB add embedded reference information and use their own dimensional conventions. EWKT is not simply standard WKT with mandatory SRID; PostGIS also documents different Z/M spellings. EWKB must not be parsed by assuming the standard WKB dimensional type-code layout.
Informative PostGIS EWKT example: the prefix identifies a reference; it does not calculate new coordinates.
SRID=4326;POINT(2.35 48.86)
Choose the agreed representation explicitly at an exchange boundary. A decoder accepting standard WKB does not automatically accept EWKB, and acceptance by one database does not establish acceptance by every implementation.
GeoJSON
RFC 7946 represents geometry as JSON and additionally defines Feature objects
with properties and FeatureCollections. GeometryCollection uses geometries
instead of coordinates (3.1, 3.1.8, 3.2–3.3).
Positions use longitude then latitude in WGS 84 degrees, with optional third ordinate for height in metres relative to the WGS 84 ellipsoid (3.1.1, 4). Extra ordinates SHOULD NOT be used; the RFC defines no M semantics. An XYM tuple's third value must not be silently treated as height. Adding an SRID member does not change the RFC's coordinate-reference rules.
Informative geometry example: this is a geometry object, without Feature properties or a reference-system transformation.
{"type":"Point","coordinates":[2.35,48.86,30]}
Exchange boundaries and information preservation
Before exchanging a value, establish the recipient's accepted format edition, geometry types, dimensions, reference convention and empty-value behavior. A shared format name alone does not establish an identical supported subset.
An empty geometry is not a location at zero. WKT includes EMPTY; GeoJSON has
its own empty-array and null rules (RFC 7946, 3.1–3.2). Binary empty encodings
must be checked against the precise source and geometry type rather than
copied between WKB, EWKB and vendor representations.
Changing format does not itself transform coordinates. Converting a measured geometry to GeoJSON, or exporting a geometry through an interface that omits its SRID, requires an explicit decision about preserving missing information. Successful parsing or an internal round trip alone does not prove that the exchange preserved Z, M, reference metadata or the geometry's meaning.
Normative foundations
- OGC 06-103r4, Simple Feature Access 1.2.1: geometry WKT is defined by 7.2.2–7.2.5; WKB by 8.2.1–8.2.8; reference-system WKT is separate in clause 9. See the representation requirement record and official specification.
- ISO/IEC CD 13249-3:201x(E), 2009-01-16 Committee Draft: 5.1.57 and 5.1.58 define SQL/MM geometry WKT and WKB. See the SQL/MM representation reference. These citations identify the project-held draft, not a final ISO edition; SQL/MM and OGC grammars are assessed separately.
- RFC 7946, August 2016: 3.1–3.3 define geometries and features; 3.1.1 defines positions; 4 defines the reference system; 6–7 cover extensions and type semantics. See the GeoJSON requirement record and published RFC.
Related implementations
Database and extension references
These are vendor behavior, not general spatial requirements. Sources were checked on 2026-10-11; they identify their own product or driver scope and do not establish a LongitudeOne compatibility matrix.
| Source and scope | Representation distinction |
|---|---|
| PostGIS manual, 4.2.1 (current 3.6.5dev documentation) | EWKT/EWKB are PostGIS extensions, including reference metadata and dimensional conventions. |
| MySQL 8.4 manual, 13.4.3 | Internal geometry storage has four SRID bytes before WKB; that complete value is not bare WKB. |
| MariaDB Server, ST_GeomFromWKB (unversioned reference) | The documented constructor accepts WKB and a separate optional SRID; no MySQL internal-layout equivalence is inferred. |
| Microsoft JDBC spatial APIs (support introduced in driver 6.5) | serialize() uses internal SQL Server spatial bytes; distinguish this driver representation from standard interchange. |
The Microsoft driver page also records API-specific format caveats. Do not infer a byte layout from a method name or transfer a driver contract to a SQL function. See the DBMS overview and the scoped PostGIS, MySQL, MariaDB and SQL Server references for platform behavior and evidenced integration limits.
LongitudeOne capabilities
The OGC support record, SQL/MM support record and GeoJSON support record identify assessed implementations and their limitations. Their scoped evidence does not imply every format, type or dimension is supported by every library. The Spatial Decoder 1.x guide owns release-specific documentation; this page defines no new encoder or decoder support promise or LongitudeOne extension.
Return to the Spatial concepts overview.