defaultSortOrder + sortby in POST requests (from STAC)

[m-mohr]

At some point in the past we decided to align STAC and OGC API sort functionality.

This was discussed for GET at that point. POST is not a thing in OGC APIs (yet) so it was not discussed, I think.
I'd hope that if POST becomes a thing in OGC APIs, this would be aligned with STAC again.

It seems later a defaultSortOrder was added to OGC APIs, which is not really aligned anymore. At least it would be pretty consistent to use the POST sort schema from STAC for the default sort order instead of creating a new way to express that.

It would make sense to change to https://github.com/stac-api-extensions/sort?tab=readme-ov-file#http-post-json-entity

The difference right now is:

STAC:

{
    "sortby": [
        {
            "field": "properties.created",
            "direction": "asc"
        },
        {
            "field": "properties.eo:cloud_cover",
            "direction": "desc"
        },
        {
            "field": "id",
            "direction": "desc"
        },
        {
            "field": "collection",
            "direction": "desc"
        }
    ]
}

OGC API - Records:

{
    "sortby": ["properties.created", "-properties.eo:cloud_cover", "-id", "-collection"]
}

Surely, one of them is shorter, but the other doesn't need string parsing to extract the - and +.
Making that consistent would be great, I think.
(I might be too late but just stumbled across it now after seeing opengeospatial/ogcapi-processes#429 )

[pvretano]

@m-mohr so if I understand you want us to change the schema of "defaultSortOrder" to match the JSON encoding that STAC has developed for "sortBy". Is that correct? If yes, I don't have a problem with that ...

[m-mohr]

Yes, I think that would make the sort interface more consistent, assuming you'd adopt the POST JSON format from STAC whenever you have a need for it.

By the way: sortby is correct (in STAC), not sortBy.