Part 5: x-ogc-propertySeq seems useless?

[m-mohr]

What's the purpose of x-ogc-propertySeq? Can it actually be enfored? I see it provided for object properties, but objects in JSON have no order as per the JSON specification. I don't see how this could be implemented and would argue that it should actually be removed.

[cportele]

For data encoded in JSON this is irrelevant (and cannot be enforced), but for other representations (e.g., CSV or FlatGeobuf) the order is essential.

[cportele]

Meeting 2024-08-26: Currently, the document states "For cases, where the properties of the data have to be ordered in some representations of the data, the sequence of the properties can be expressed using a keyword x-ogc-propertySeq." We will add a note that provides examples and more context. That should address the issue.

[m-mohr]

In my opinion, it's a - sorry - bad imitation of an array. If something has an order, it should be an array.
In an object, it needs to be ensured that all subschemas have a number and that they are unique. What happens if only a subset of property schemas have x-ogc-propertySeq?
The spec also doesn't say (afaik) how the relation to patternProperties and additionalProperties are. Are these not allowed if x-ogc-propertySeq is used? What happens if I combine different schemas (oneOf, anyOf, etc.)?
This becomes especially important when specs then define wildcard properties such as Coverages with e.g. properties=B03,*
For this I need to resolve all this in utterly complex code that tries to handle all cases.
(Generally, it feels like the use of JSON Schema here is not appropriate, which is underlined by all the x-ogc- properties that are needed to solve all the usecases => #945 )

For data encoded in JSON this is irrelevant (and cannot be enforced), but for other representations (e.g., CSV or FlatGeobuf) the order is essential.

I don't quite get the order in CSV/FlatGeoBuf. Aren't these formats usually supporting field names? It seems much better to identify columns by name rather than by order.

[jerstlouis]

@m-mohr In GeoTIFF for example there is no way to describe or name the bands.
Whereas GeoTIFF 2.0 might fix that, this provides a solution that works right now.

[m-mohr]

I'm not sure I understand how this is relevant to my comment. Was this meant to be a comment towards my last sentence?

It seems much better to identify columns by name rather than by order.

(Note: GeoTiff is a raster format, but Features is not a raster API...)

[jerstlouis]

@m-mohr Yes, the concept of logical schemas are relevant to both feature collections and raster / gridded coverage data, and this is parat of the "common" aspects of this Schemas Part 5.

The use case is also relevant to formats like CSV / FlatGeoBuf which might not have field names.
(I guess for CSV it depends whether you use a header row or not?)