Repository navigation
Story: Complete EWKT geometry coverage and compatibility validation #35
Description
Complete EWKT geometry coverage and compatibility validation
As a user of the spatial decoder,
I want supported spatial geometries and EWKT edge cases to be handled
consistently,
so that valid EWKT input produces the expected spatial objects while
unsupported or invalid input is reported accurately.
Context
The EWKT strategy supports PostGIS spatial reference information and
dimensional representations.
The strategy must provide consistent decoding across all geometry types that
can currently be represented by spatial-types, including empty geometries
and nested geometry structures.
PostGIS also recognizes spatial types that may not yet be represented by
spatial-types. When such a type is recognized as valid EWKT but cannot be
instantiated, the decoder must distinguish this implementation limitation from
invalid input by using NotYetImplementedException.
The decoder should remain permissive toward unambiguous EWKT representations,
while preserving the geometry structure, dimensionality, coordinates, and
SRID represented by the input.
Acceptance Criteria
- Every EWKT geometry type that can currently be represented by
spatial-typescan be decoded by the EWKT strategy. - Supported
EMPTYgeometries are decoded while preserving their geometry
type, dimensionality, and SRID. - Supported multi-geometries and geometry collections are decoded with
their complete nested structure preserved. -
TriangleandPolyhedralSurfaceEWKT representations are decoded when
they can be represented by the correspondingspatial-typesobjects. - Geometry components are validated for structural and dimensional
consistency before the resulting spatial object is returned. - The SRID defined by the root EWKT geometry is consistently applied to
the resulting spatial structure. - Nested geometries cannot introduce an independent SRID.
- A spatial type recognized as valid by the supported EWKT grammar but not
yet representable byspatial-typescauses a
NotYetImplementedException. - The
NotYetImplementedExceptionidentifies the recognized spatial type
that cannot yet be instantiated. - Unknown spatial types, malformed EWKT, invalid geometry structures, and
recognized but not yet implemented spatial types remain distinguishable
through the decoder exception model. - Existing WKT decoding behavior remains unchanged.
- Automated tests cover supported geometry families,
EMPTYgeometries,
nested structures, invalid structures, and recognized spatial types that
are not yet implemented.
References
- PostGIS
ST_GeomFromEWKTdocumentation. - PostGIS
liblwgeomEWKT lexer and parser. - OGC Simple Feature Access for the underlying geometry model and standard WKT
representations. - ISO/IEC 13249-3 for spatial geometry types, dimensional semantics, and WKT
representations where applicable.
Activity
Alexandre-T commentedon Sep 30, 2026
Definition of Ready — geometry type coverage
This Story should not be considered Ready until the boundary between supported
and recognized-but-not-yet-implemented spatial types is explicitly defined.
Before implementation, establish an inventory of the spatial types recognized
by the supported EWKT grammar and classify each type as:
spatial-typesand therefore required to decodesuccessfully;
spatial-types, andtherefore required to raise
NotYetImplementedException;This inventory will remove implementation ambiguity and provide the baseline
for future Epics introducing the missing spatial types across the LongitudeOne
libraries.
Alexandre-T commentedon Oct 1, 2026
As a user of the spatial decoder,
I want the EWKT strategy to decode supported geometry types,
so that EWKT values can be converted into the corresponding
SpatialInterfaceobjects while unsupported or non-instantiable types are handled explicitly.Context
The EWKT lexer and parser recognize the geometry types defined by
GeometryTypeEnum.However, not every geometry type represented by
GeometryTypeEnumcurrently has a concrete implementation inspatial-types.The decoder must therefore distinguish between:
spatial-types;spatial-types;This distinction must be explicit and deterministic.
Supported geometry types
The EWKT strategy decodes the following geometry types into their corresponding
SpatialInterfaceimplementations:POINTLINESTRINGPOLYGONTRIANGLEPOLYHEDRALSURFACEMULTIPOINTMULTILINESTRINGMULTIPOLYGONGEOMETRYCOLLECTIONThe resulting object must preserve the spatial family, coordinate dimension and SRID determined from the EWKT input.
POLYHEDRALSURFACEis implemented byspatial-typesonly for coordinate layouts containing Z. Unsupported coordinate layouts for an otherwise implemented geometry type are validation errors and must not be reported as an unimplemented geometry type.Recognized but not yet implemented geometry types
The following geometry types are instantiable according to
GeometryTypeEnum, but do not currently have a concrete implementation inspatial-types:CIRCULARSTRINGCOMPOUNDCURVECURVEPOLYGONMULTICURVEMULTISURFACETINWhen one of these geometry types is encountered, the EWKT strategy must throw
NotYetImplementedException.The exception must identify the geometry type that cannot currently be decoded.
Non-instantiable geometry types
The following
GeometryTypeEnumvalues are explicitly non-instantiable:GEOMETRYCURVESURFACESOLIDThese types must not be treated as geometry types awaiting implementation.
When one of these types is encountered where a concrete geometry is required, decoding must fail with the decoder error appropriate for a non-instantiable geometry type and must not throw
NotYetImplementedException.Acceptance Criteria
POINTEWKT values are decoded into the corresponding point implementation.LINESTRINGEWKT values are decoded into the corresponding line string implementation.POLYGONEWKT values are decoded into the corresponding polygon implementation.TRIANGLEEWKT values are decoded into the corresponding triangle implementation.POLYHEDRALSURFACEEWKT values are decoded when their coordinate layout is supported byspatial-types.MULTIPOINTEWKT values are decoded into the corresponding multi-point implementation.MULTILINESTRINGEWKT values are decoded into the corresponding multi-line string implementation.MULTIPOLYGONEWKT values are decoded into the corresponding multi-polygon implementation.GEOMETRYCOLLECTIONEWKT values are decoded into the corresponding collection implementation.CIRCULARSTRING,COMPOUNDCURVE,CURVEPOLYGON,MULTICURVE,MULTISURFACEandTINare recognized and throwNotYetImplementedException.NotYetImplementedExceptionidentifies the recognized geometry type that is not currently implemented.GEOMETRY,CURVE,SURFACEandSOLIDare rejected as non-instantiable geometry types and do not throwNotYetImplementedException.spatial-typesimplementation.GEOMETRYCOLLECTIONmembers are decoded recursively according to the same supported, unimplemented and non-instantiable type rules.Alexandre-T commentedon Oct 1, 2026
Definition of Ready — validated
This Story is Ready for implementation.
The geometry coverage is now explicitly defined and removes the remaining implementation ambiguity:
spatial-typesare identified and must be decoded;spatial-typesare explicitly listed and must raiseNotYetImplementedException;GeometryTypeEnumvalues are explicitly identified and handled separately;POLYHEDRALSURFACEdimensional limitations are distinguished from missing type implementations;The implementation scope and expected outcomes are therefore sufficiently precise and testable.
Status: READY.
[-]Complete EWKT geometry coverage and compatibility validation[/-][+]Story: Complete EWKT geometry coverage and compatibility validation[/+]