PB-1677: sort extension - Add properties prefix #minor - #665
Open
asteiner-swisstopo wants to merge 12 commits into
Open
PB-1677: sort extension - Add properties prefix #minor#665asteiner-swisstopo wants to merge 12 commits into
asteiner-swisstopo wants to merge 12 commits into
Conversation
That makes sure that the fields available in the sortby query param and the ones reported in /sortable are in sync.
This is the same as /sortables except that it checks whether the collection exists.
The link relation type is as given in [the specs of the sort extension](https://github.com/stac-api-extensions/sort#sortables).
These are listed in the [specs of the sort extension](https://github.com/stac-api-extensions/sort): - For the sortby query param: - https://api.stacspec.org/v1.1.0/item-search#sort - https://api.stacspec.org/v1.1.0/ogcapi-features#sort - For the sortables endpoint: - https://api.stacspec.org/v1.1.0/item-search#sortables - http://www.opengis.net/spec/ogcapi-features-5/1.0/conf/sortables
Mosts of it is adapted from the [sort extension's openapi.yaml](https://github.com/stac-api-extensions/sort/blob/main/openapi.yaml).
As we advertise the /sortables endpoints with `"type":
"application/schema+json"`, the stac-browser also tries to fetch the
JSON schema with schema+json. However, the STAC API cannot cope with
this Accept header (`Accept: application/schema+json`) and returns an
error:
```log
Request GET /api/stac/v1/collections/test-collection/sortables
Response 406: {'detail': ErrorDetail(string='Could not satisfy the
request Accept header.', code='not_acceptable')}
```
Therefore, we now also accept and render media type
"application/schema+json".
The SORTABLE_FIELDS is no longer just a dict of strings but contains structured objects.
Follow-up of #664: Prepend `properties.` to certain parameters used in the `sortby` query parameter and in the `/sortables` endpoint: - `datetime` -> `properties.datetime` - `title` -> `properties.title` - `created` -> `properties.created` - `updated` -> `properties.updated` - `id` and `collection` stay unchanged (top-level fields) In #663, we chose to omit the `properties.` prefix for the `sortby` query parameter. So we refer to `datetime`, not `properties.datetime`. This was because the "query" parameter of the [POST /search endpoint](https://data.geo.admin.ch/api/stac/static/spec/v1/apitransactional.html#tag/STAC/operation/postSearchSTAC) also omits the `properties.` prefix. Looking into the STAC Browser code, however, I see that the `properties.` prefix is the assumed default. I think then it would be better to follow the STAC Browser. The Query extension will anyway be replaced by the Filter extension (see PB-2392), so the inconsistency is ok.
asteiner-swisstopo
added
the
WIP 🚧
asteiner-swisstopo
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up of #664: Prepend
properties.to certain parameters used in thesortbyquery parameter and in the/sortablesendpoint:datetime->properties.datetimetitle->properties.titlecreated->properties.createdupdated->properties.updatedidandcollectionstay unchanged (top-level fields)In #663, we chose to omit the
properties.prefix for thesortbyquery parameter. So we refer todatetime, notproperties.datetime. This was because the "query" parameter of the POST /search endpoint also omits theproperties.prefix.Looking into the STAC Browser code, however, I see that the
properties.prefix is the assumed default. I think then it would be better to follow the STAC Browser. The Query extension will anyway be replaced by the Filter extension (see PB-2392), so the inconsistency is ok.