OGC Simple Feature Access 1.2.1 — Common architecture
Simple Feature Access (SFA) Part 1 defines a platform-neutral geometry model, spatial relationships and WKT/WKB representations. Use this reference to distinguish those requirements from the PHP capabilities implemented by LongitudeOne. Implementing selected geometry classes does not establish conformance to the complete specification.
Normative source
| Field | Verified source |
|---|---|
| Organization | Open Geospatial Consortium (OGC) |
| Identifier and title | OGC 06-103r4, Geographic information — Simple feature access — Part 1: Common architecture |
| Version and date | 1.2.1, 2011-05-28 |
| Status | Corrigendum; this reference uses the consolidated 06-103r4 document |
| Authoritative source | OGC specification PDF and OGC SFA catalogue |
| Amendments | No additional amendment or later revision is assessed here |
All OGC clause citations below refer to this document. Annexes A and B are informative. The SQL/MM Spatial reference identifies the separate ISO draft used by LongitudeOne; it must not be substituted for this OGC source.
Purpose and scope
Part 1 standardizes geometry names, definitions and common architecture rather than database storage or mechanisms for declaring types (clause 1). The portions relevant here are the geometry model (6.1), geometry WKT (7), geometry WKB (8) and spatial-reference-system WKT (9).
Annotation text (6.2) and the SQL implementation specified in other SFA parts are outside this assessment. Clause 2 requires the applicable test suites in other parts of ISO 19125 for conformance; this page records feature support, not a certification or whole-standard conformance claim.
Relevant requirements
The summaries in this section are normative requirements attributed to OGC. Examples and implementation records below have separate authority.
Geometry model, reference systems and empty values
- Hierarchy: Geometry is abstract; Point, Curve, Surface and GeometryCollection organize the model. Specialized collections distinguish point, curve and surface members (6.1.1, Figure 1; 6.1.2.1).
- Reference systems: each geometry is associated with an SRS. Coordinates must be unambiguously associated with a reference system; collection members must share their collection's SRS (6.1.1, 6.1.2.1, 6.1.3.1).
- Empty values:
IsEmptytests whether a geometry denotes the empty point set. Emptiness is different from simplicity, whose conditions depend on the concrete geometry type (6.1.2.2). - Polygon and Triangle: a Polygon is a planar surface with one exterior boundary and optional holes. Its rings must obey the crossing, tangency and connected-interior assertions. A Triangle has three distinct, non-collinear vertices and no interior boundary (6.1.11.1).
- PolyhedralSurface and TIN: a PolyhedralSurface contains contiguous polygon patches with consistent orientation along shared boundaries; a TIN restricts those patches to triangles. A surface enclosing a solid remains a surface representation (6.1.12.1).
Dimensions and spatial operations
Topological dimension and coordinate dimension are separate properties (6.1.2.1–6.1.2.2). In particular, three ordinates do not necessarily imply Z.
| Layout | Ordinates | Geometry WKT qualifier | Relevant clauses |
|---|---|---|---|
| XY | x, y | None | 6.1.2.1; 7.2.2 |
| XYZ | x, y, z | Z | 6.1.2.1; 7.2.3 |
| XYM | x, y, m | M | 6.1.2.1; 7.2.4 |
| XYZM | x, y, z, m | ZM | 6.1.2.1; 7.2.5 |
Z describes a spatial ordinate; M describes a measure. OGC's map-geometry operations use the horizontal projection and ignore Z/M in their calculations; storing Z does not establish true 3D operation support (6.1.2.5).
DE-9IM records the dimensions of intersections between each geometry's interior, boundary and exterior. The named topological predicates are defined through those relationships, rather than coordinate-array equality (6.1.15.2–6.1.15.3). Spatial analysis operations, including distance, buffer and intersection, have their own contracts (6.1.2.4).
Geometry representations
Geometry WKT uses separate dimensional grammars, including EMPTY productions
(7.2.2–7.2.5). Geometry WKT (7) and SRS WKT (9) represent different objects:
a geometry's coordinate text is not a complete reference-system definition.
WKB serializes geometry using 32-bit unsigned integers and 64-bit IEEE 754 doubles. Each geometry carries a byte-order tag: 0 denotes big-endian XDR; 1 denotes little-endian NDR (8.2.1–8.2.2; 8.2.4–8.2.6; 8.2.8). The concrete type enumeration in 8.2.8 distinguishes XY, XYZ, XYM and XYZM with offsets 0, 1000, 2000 and 3000.
Table 7 in 8.2.3 also reserves types for future use. A listed code alone does not establish a concrete representation in this edition. For example, 8.2.8 explicitly gives Triangle codes 17/1017/2017/3017; representation assessments must check the concrete structures as well as the code registry. WKB values must satisfy the represented geometry's assertions (8.2.9).
Informative examples: these illustrate the Point grammar only; they are neither decoder compatibility tests nor declarations of an SRS.
POINT (10 20)
POINT Z (10 20 30)
POINT M (10 20 5)
POINT ZM (10 20 30 5)
POINT EMPTY
LongitudeOne support
The records below describe evidenced implementation behavior in these scopes:
- Core: Spatial Core 1.3.0, revision
1289582288e8954243de5ccb1f28ab7e78f4e9a4; see the 1.x primitives guide. - Types: Spatial Types pre-1.0 development snapshot, after
0.0.1-alpha.4, revisionceaee5d142c77fc3922ab50c762fa6648fea0e30. Snapshot support does not promise availability in a released version. - Decoder: Spatial Decoder 1.x release preparation, revision
6c2a03bd39c7adecdabec6d7fbee2fef94495927; see the release preparation guide.
No DBMS integration or Geography computation semantics are assessed.
| Feature | Implementation scope | Status | Limitations | Implementation decision | Extensions | Evidence |
|---|---|---|---|---|---|---|
| Coordinate layouts | Core | Supported | Enum metadata only | Separate Z/M flags | None documented | Enum and tests |
| Geometry families | Types | Partially supported | Subset below; full validity unassessed | PHP value classes | Separate Geography family | Catalogue |
| Collection SRS | Types | Supported | Reference identity, not CRS definitions | Full authority/identifier match | None documented | SRS guide |
| Empty values | Types | Partially supported | Construction documented; full OGC audit pending | Explicit empty values | None documented | Catalogue |
| DE-9IM and analysis | Types | Not assessed | No complete OGC operation audit | Point equality differs; see below | None documented | Observable API |
| WKT/WKB | Decoder | Not assessed | No complete 1.2.1 grammar/layout audit | Parsing delegated to strategies | Not assessed | Decoder guide |
| SRS WKT | Types | Unsupported | Reference is identifier metadata only | No full CRS definition model | None documented | SRS guide |
Geometry subset and limitations. The Types catalogue supplies Point, LineString, Polygon, Triangle, GeometryCollection, MultiPoint, MultiLineString and MultiPolygon in XY/XYZ/XYM/XYZM. PolyhedralSurface is available only in XYZ/XYZM. TIN, MultiCurve and MultiSurface have no instantiable classes in this snapshot. Class availability does not demonstrate every simplicity or validity assertion from 6.1, nor complete spatial-operation support.
Implementation decisions. Core's CoordinateDimensionEnum and its tests
verify ordinate count, Z/M presence and WKT qualifiers. Types compares the full
authority and identifier for aggregate references; identifier 0 is not a
wildcard. Its withSpatialReference() relabels a value without transforming
coordinates. These PHP choices are not additional OGC requirements.
Types' equalsTo() compares a point's concrete class, family, reference, layout
and all ordinates. It is a value-equality operation, not evidence that OGC's
map-based Equals predicate is implemented. This distinction avoids inferring
topological equivalence from matching method names.
Extensions beyond the assessed OGC model. Types exposes a separate Geography family and CircularString/CompoundCurve classes. Figure 1 in 6.1.1 does not define those as separate concrete branches; the reserved codes in Table 7 do not change that. These are LongitudeOne capabilities beyond the assessed Part 1 model, not newly defined OGC semantics or a claim that curved geometries are proprietary. Their other normative foundations require their own assessment. EWKT/EWKB and vendor binary wrappers likewise require separate format evidence; this page makes no support claim for them.