Part 5: Feature references with more complex values

[cportele]

Part 5 (Schemas) currently specifies that feature references are a string or integer which is the local feature id of the referenced feature. See https://docs.ogc.org/DRAFTS/23-058r1.html#rc_feature-references.

This approach does not fully support cases where the feature id is not the only variable part of the URI of the target resource, for example, the collection id of the feature collection.

In those cases, the feature reference might have to be an object with one member for every parameter in the target URI template. For example, if there are multiple types (collections) of road segments, it could be necessary to use something like { "roadSegment": { "featureId": 123, "collectionId": "slip-road" } } instead of { "roadSegment": 123 } to be able to mint the URI of the target resource.

This would also impact queryables for such properties and how to write filter expressions.

It could also be an option to consider such feature references as too complex and out-of-scope for Part 5. In that case implementations / communities that need such a capability would have to specify their own extension.

[cportele]

Meeting 2024-08-26: Cubewerx includes the collection information in the featureId/key, e.g., https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/zaatari/collections/SettlementSrf/items/CWFID.SETTLEMENTSRF.0.6. In ldproxy two properties (one for the featureId and one for the collection). We need to analyze/discuss, if we need to specify something in Part 5.