ISO/IEC 13249-3 — SQL/MM Spatial
SQL/MM Spatial defines a SQL model for points, curves, surfaces and collections, their spatial relationships and operations, coordinate dimensions, reference systems, WKT/WKB/GML conversion, topology and spatial metadata. Its scope includes SQL user-defined types, routines and conformance requirements, not just geometry representations (draft clauses 1, 4–5 and 20).
LongitudeOne uses selected parts of this model in PHP. This page explains the implemented classifications and checks, the draft criteria against which they can be verified, and the remaining support gaps.
Normative source
| Published standard | Official source |
|---|---|
| ISO/IEC 13249-3:2011 | ISO catalogue |
| ISO/IEC 13249-3:2016 | ISO catalogue |
LongitudeOne does not have the budget to acquire these published standards and
bases this reference on ISO/IEC CD 13249-3:201x(E), the 2009-01-16 Committee
Draft (ISO/IEC JTC 1/SC 32 N 1820). Its 201x identifier is provisional.
All clause citations refer to the project-held draft PDF, which is not distributed here and has no verified authoritative public URL. Final-edition clauses, amendments and corrigenda have not been assessed; this page does not establish their requirements or LongitudeOne conformance to them.
How LongitudeOne uses SQL/MM Spatial
The comparisons below connect normative criteria from the draft with evidenced LongitudeOne implementation behavior. Code and tests show the current mapping; they do not establish when or why a historical decision was made.
Geometry model and dimensions
Instantiability. LongitudeOne separates a type's classification from the
availability of a PHP class. For the draft's geometry family,
GeometryTypeEnum::isInstantiable() classifies Geometry, Curve
and Surface as abstract, matching the absence of constructors in clause 4.2.
GeometryTypeEnumTest::testInstantiabilityClassification() checks each enum case explicitly.
Other model families in the enum require their own normative assessment;
this draft does not justify the whole enum.
SpatialTypeImplementationStatus then checks whether a concrete family is
implemented. For example, TIN is instantiable in the model but has no PHP class
in the assessed Types snapshot. The Types catalogue, docs/instantiable-spatial-types.md, records that distinction.
The PHP name PolyhedralSurface corresponds to the draft's ST_PolyhdrlSurface;
matching names alone does not prove all SQL semantics are implemented.
Coordinate layouts. LongitudeOne represents XY, XYZ, XYM and XYZM with
CoordinateDimensionEnum. Comparing their ordinate lists with clause
4.2.1 verifies that three ordinates can mean either XYZ or XYM: M is a measure,
not a substitute for Z. CoordinateDimensionEnumTest scenarios check all four layouts,
their ordinate counts and indices, Z/M presence and WKT modifiers.
LongitudeOne keeps coordinateDimension() separate from the geometry enum's
topologicalDimension(). This follows the distinction between ST_CoordDim
and ST_Dimension (5.1.3 and 5.1.2). Its is3d() tests Z presence, while
hasM() tests M presence, corresponding to 5.1.11 and 5.1.12. Thus XYM has
three ordinates without being classified as a Z-bearing layout.
Spatial references and empty values
LongitudeOne checks that every aggregate member has the same full spatial
reference as its parent. The Types guide, docs/spatial-reference-systems.md,
explains this invariant and its implementation: an optional authority participates in identity, and identifier
0 is not a wildcard. The normative comparison is the single-SRS requirement
for locations within a geometry (4.2.1); the PHP identity rules are project choices.
LongitudeOne also separates declaring a reference from transforming coordinates.
withSpatialReference() creates an immutable copy with a new reference and
unchanged coordinates; transformation requires an external component. This
preserves the distinction between SRID reassignment and ST_Transform
(5.1.5 and 5.1.6), without claiming to implement the SQL methods.
For empty values, the Types catalogue documents construction and
isEmpty() behavior. The comparison criterion is whether a value denotes the
empty set (5.1.7), followed by the concrete type's rules. Class availability
alone does not verify every empty state or its serialization.
Representations
LongitudeOne's coordinate enum supplies WKT modifiers for Z, M and ZM; its tests
verify that mapping. The draft comparison is the qualifier grammar in 5.1.57.
That check does not establish support for every geometry production or EMPTY
form in a decoder. WktDecoderStrategy::decode() delegates parsing;
its complete compatibility with this exact draft remains unassessed.
A binary compatibility assessment must separately check geometry identifiers and layouts against Table 15 of 5.1.58, and byte order and numeric storage against description items cj–co. No such complete audit is recorded here. LongitudeOne support for EWKT/EWKB or database wrappers must be assessed against their own sources; it cannot establish SQL/MM WKT/WKB conformity.
Conformance
LongitudeOne records support per feature and implementation version below. It makes no blanket ISO conformance claim: PHP classifications and format checks do not demonstrate the SQL type/routine groups, Spatial Information Schema views and declared options required by 20.1–20.3.
LongitudeOne support
Records below describe evidenced implementation behavior, not SQL conformance.
Core means Spatial Core 1.3.0, revision 1289582288e8954243de5ccb1f28ab7e78f4e9a4.
Types means the Spatial Types pre-1.0 development snapshot, after 0.0.1-alpha.4,
revision ceaee5d142c77fc3922ab50c762fa6648fea0e30.
Snapshot findings do not promise availability in a released version.
Decoder means the Spatial Decoder 1.x release preparation,
revision 6c2a03bd39c7adecdabec6d7fbee2fef94495927.
No DBMS integration is assessed.
| Feature | Implementation scope | Status | Limitations | Implementation decision | Extensions | Evidence |
|---|---|---|---|---|---|---|
| Layouts | Core | Supported | PHP primitive only | Separate Z/M flags | None documented | Enum; tests |
| Families | Types | Partially supported | Subset below | PHP classes | None documented | Types catalogue |
| Transformation | Types | Unsupported | External transform | Relabeling only | None documented | Types SRS guide |
| WKT/WKB | Decoder | Not assessed | Draft audit pending | Not assessed | Not assessed | WKT strategy |
Supported geometry subset: docs/instantiable-spatial-types.md in the assessed
Types revision provides Point, LineString,
Polygon, CircularString, CompoundCurve, Triangle, GeometryCollection, MultiPoint,
MultiLineString and MultiPolygon in XY/XYZ/XYM/XYZM; PolyhedralSurface is limited
to XYZ/XYZM. CurvePolygon, MultiCurve, MultiSurface and TIN have no instantiable
classes in this snapshot. This is class availability, not complete support for
the corresponding SQL routines or every normative validity condition.
Extensions: none are documented for the assessed features in this record. This is not an ecosystem-wide absence claim. Serializer extensions and other model families remain unassessed against this draft.