--- title: ISO/IEC 13249-3 — SQL/MM Spatial description: Explains how LongitudeOne uses the verified SQL/MM Spatial draft to classify geometry types, dimensions and implementation support. canonical_html: ./iso-iec-13249-3.html canonical_markdown: ./iso-iec-13249-3.md --- [View HTML version](./iso-iec-13249-3.html) 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][iso2011] | | ISO/IEC 13249-3:2016 | [ISO catalogue][iso2016] | 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][layout-use] | Core | Supported | PHP primitive only | Separate Z/M flags | None documented | [Enum][coordinate-enum]; [tests][coordinate-tests] | | [Families][layout-use] | Types | Partially supported | Subset below | PHP classes | None documented | [Types catalogue][types-catalogue] | | [Transformation][srs-use] | Types | Unsupported | External transform | Relabeling only | None documented | [Types SRS guide][types-srs] | | [WKT/WKB][format-use] | Decoder | Not assessed | Draft audit pending | Not assessed | Not assessed | [WKT strategy][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. ## Related references - [ISO reference overview](index.md) - [Spatial Core 1.x primitives](../../spatial-core/v1/geometry/index.md) - [Spatial Decoder 1.x release preparation](../../spatial-decoder/v1/index.md) - [Reference authoring and support records](../../shared/spatial-reference-documentation-architecture.md) [iso2011]: https://www.iso.org/standard/53698.html [iso2016]: https://www.iso.org/standard/60343.html [layout-use]: #geometry-model-and-dimensions [srs-use]: #spatial-references-and-empty-values [format-use]: #representations [coordinate-enum]: https://github.com/longitude-one/spatial-core/blob/1289582288e8954243de5ccb1f28ab7e78f4e9a4/lib/Enum/CoordinateDimensionEnum.php [coordinate-tests]: https://github.com/longitude-one/spatial-core/blob/1289582288e8954243de5ccb1f28ab7e78f4e9a4/tests/Unit/Enum/CoordinateDimensionEnumTest.php [types-catalogue]: https://github.com/longitude-one/spatial-types/blob/ceaee5d142c77fc3922ab50c762fa6648fea0e30/docs/instantiable-spatial-types.md [types-srs]: https://github.com/longitude-one/spatial-types/blob/ceaee5d142c77fc3922ab50c762fa6648fea0e30/docs/spatial-reference-systems.md [wkt-strategy]: https://github.com/longitude-one/spatial-decoder/blob/6c2a03bd39c7adecdabec6d7fbee2fef94495927/lib/Strategy/WktDecoderStrategy.php