Positions in reference systems beside the native CRS

[cportele]

Part of addressing ldproxy/ldproxy#1692

Adds support for feature types that store geometries in one of several CRSs.

• FeatureSchema: a variants declaration on the primary geometry property groups the sibling properties that store a position as recorded; new roles ORIGINAL_GEOMETRY, ORIGINAL_HEIGHT and ORIGINAL_CRS_IDENTIFIER identify the group members and make them internal (readable, but not part of any public schema or regular encoding). Variant properties declare the identifiers of their reference systems (originalCrsIdentifiers), the CRS they are stored in (nativeCrs), the CRS of the recorded positions (originalCrs) and, where needed, a falseEastingDifference.
• GML decoder: positions are routed by their verbatim srsName to the matching variant property (1D positions as scalars, the identifier stored verbatim); the read pipeline restores originalCrs so encodings receive the recorded positions.
• Write path: geometries are transformed to the per-property storage CRS.
• EpsgCrs: new auxiliary alternativeUri for community URIs of a CRS.
• Collection extents are computed from the primary geometry only.

Also extends the GML decoder for ISO 19139 metadata structures on the wire (value-wrapper chains with attributes and empty elements, xsi:type on wrapper elements), so documents shaped like the encoder's output can be ingested losslessly.

[azahnen]

@cportele
In general I would prefer to put this into an extension, but our current design doesn't really allow that. A more modular approach to the ever-growing FeatureSchema is something I will look into before v5. Two points regarding the PR:

1. Since variants are a concept specific to geometries, I think the naming of getVariants, SchemaVariants and VariantResolver should reflect that.

2. getNativeCrs(): Only relevant for properties with type: GEOMETRY in SQL feature providers, when a feature type stores positions in more than one CRS in separate geometry columns.

   Couldn't this also be used for simpler cases with a single geometry column per type but mixed storage CRSs?

[cportele]

@azahnen

Agreed on a modularization of the feature schema (extensions).

1. I will update the naming.
2. That is currently not supported by the specs, which expect that responses have the primary geometry in a single, homogeneous CRS (as an override the PRs define a new profile crs-original). So, also for the "simpler case" we need a primary geometry column with the geometry in the provider-wide native CRS (derived from the geometry in the type-specific native CRS).

[cportele]

@azahnen - the renaming is done (in ldproxy, too).

[azahnen]

@cportele Thanks!

Regarding 2, but the spec is not the concern of the provider. If I sent a simple query to the provider requesting raw tokens (to circumvent potential encoder limitations), would it work for a type with a deviating nativeCrs?

[cportele]

@azahnen - Regarding your question:

Partially. The token stream itself would work: a geometry property with its own nativeCrs is deliberately excluded from target-CRS reprojection and passed through verbatim, and the write path already transforms to the column CRS per property. But the rest of the provider assumes the provider-wide nativeCrs for the primary geometry: spatial filter literals are encoded in the provider CRS (mixed-SRID against such a column), extents/stats treat primary-geometry coordinates as provider-native, and a crs in the query would silently not apply. So the "simpler case" would need making those parts per-property aware. That's why the docs currently scope it to the CRS variants use case.