-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type mapping for Collections bbox #319
Comments
This sounds like a good approach to me. Here are a couple thoughts:
|
Thanks @jamesfisher-geo for your reply. Let me try to reply to your points: Experimenting More:I'm currently testing my extension with:
And this is the resulting query:
It is unfortunately not working probably because of the type of the extent (not geo_shape):
|
I'm proceeding into the development of the collections search and I encountered the following schema definition:
stac-fastapi-elasticsearch-opensearch/stac_fastapi/opensearch/stac_fastapi/opensearch/database_logic.py
Line 141 in 106fabb
This is preventing me to apply any spatial filter on this field, so I was wondering if we can consider to change this schema.
The standard says:
https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md#spatial-extent-object
So it should be a [[number]] which may be mapped to a long or double rater than a long, don't you think so?
https://www.elastic.co/guide/en/elasticsearch/reference/current/number.html
Moreover the standard talks about interval as [[string|null]] ( https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md#temporal-extent-object )
and this has been mapped as 'date' instead.
This is great so we can search and filter by date not using generic strings.
But so, why don't we map the spatial extent with a geo_shape?
"extent.spatial.bbox": {"type": "geo_shape"},
so we can start properly search collections with s_intersection filters?
Thanks
The text was updated successfully, but these errors were encountered: