---
title: OGC Simple Feature Access 1.2.1 — Common architecture
description: Summarizes OGC 06-103r4 geometry, dimensions and representations with scoped LongitudeOne support and limitations.
canonical_html: ./ogc-06-103r4.html
canonical_markdown: ./ogc-06-103r4.md
---

[View HTML version](./ogc-06-103r4.html)

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][ogc] and [OGC SFA catalogue][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](../iso/iso-iec-13249-3.md) 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:** `IsEmpty` tests 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.

```text
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](../../spatial-core/v1/geometry/index.md).
- **Types:** Spatial Types **pre-1.0 development snapshot**, after
  `0.0.1-alpha.4`, revision `ceaee5d142c77fc3922ab50c762fa6648fea0e30`.
  Snapshot support does not promise availability in a released version.
- **Decoder:** Spatial Decoder **1.x release preparation**, revision
  `6c2a03bd39c7adecdabec6d7fbee2fef94495927`; see the
  [release preparation guide](../../spatial-decoder/v1/index.md).

No DBMS integration or Geography computation semantics are assessed.

| Feature                                                                 | Implementation scope | Status              | Limitations                                     | Implementation decision           | Extensions                | Evidence                     |
| ----------------------------------------------------------------------- | -------------------- | ------------------- | ----------------------------------------------- | --------------------------------- | ------------------------- | ---------------------------- |
| [Coordinate layouts](#dimensions-and-spatial-operations)                | Core                 | Supported           | Enum metadata only                              | Separate Z/M flags                | None documented           | [Enum and tests][core-tests] |
| [Geometry families](#geometry-model-reference-systems-and-empty-values) | Types                | Partially supported | Subset below; full validity unassessed          | PHP value classes                 | Separate Geography family | [Catalogue][types]           |
| [Collection SRS](#geometry-model-reference-systems-and-empty-values)    | Types                | Supported           | Reference identity, not CRS definitions         | Full authority/identifier match   | None documented           | [SRS guide][srs]             |
| [Empty values](#geometry-model-reference-systems-and-empty-values)      | Types                | Partially supported | Construction documented; full OGC audit pending | Explicit empty values             | None documented           | [Catalogue][types]           |
| [DE-9IM and analysis](#dimensions-and-spatial-operations)               | Types                | Not assessed        | No complete OGC operation audit                 | Point equality differs; see below | None documented           | [Observable API][types]      |
| [WKT/WKB](#geometry-representations)                                    | Decoder              | Not assessed        | No complete 1.2.1 grammar/layout audit          | Parsing delegated to strategies   | Not assessed              | [Decoder guide][decoder]     |
| [SRS WKT](#geometry-representations)                                    | Types                | Unsupported         | Reference is identifier metadata only           | No full CRS definition model      | None documented           | [SRS guide][srs]             |

**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.

## Related references

- [OGC specifications overview](index.md)
- [SQL/MM Spatial source and implementation assessment](../iso/iso-iec-13249-3.md)
- [Spatial Core 1.x](../../spatial-core/v1/index.md)
- [Spatial Decoder 1.x](../../spatial-decoder/v1/index.md)
- [Reference authoring and support records](../../shared/spatial-reference-documentation-architecture.md)

[ogc]: https://portal.ogc.org/files/?artifact_id=25355

[catalogue]: https://www.ogc.org/standards/sfa/

[core-tests]: https://github.com/longitude-one/spatial-core/blob/1289582288e8954243de5ccb1f28ab7e78f4e9a4/tests/Unit/Enum/CoordinateDimensionEnumTest.php

[types]: https://github.com/longitude-one/spatial-types/blob/ceaee5d142c77fc3922ab50c762fa6648fea0e30/docs/instantiable-spatial-types.md

[srs]: https://github.com/longitude-one/spatial-types/blob/ceaee5d142c77fc3922ab50c762fa6648fea0e30/docs/spatial-reference-systems.md

[decoder]: https://github.com/longitude-one/spatial-decoder/blob/6c2a03bd39c7adecdabec6d7fbee2fef94495927/lib/Strategy/WktDecoderStrategy.php
