-
Notifications
You must be signed in to change notification settings - Fork 28
Description
I'm proceeding into the development of the collections search and I encountered the following schema definition:
"extent.spatial.bbox": {"type": "long"},
"extent.temporal.interval": {"type": "date"},
Line 141 in 106fabb
"extent.spatial.bbox": {"type": "long"}, |
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
Activity
jamesfisher-geo commentedon Dec 5, 2024
This sounds like a good approach to me. Here are a couple thoughts:
ccancellieri commentedon Dec 6, 2024
Thanks @jamesfisher-geo for your reply.
Let me try to reply to your points:
Point 1: I think we could reuse what has been done for the items, it may not be a challenge.
Point 2: same as above.
Point 3: well this is actually an interesting point, I think we should also look on how the time is defined but definitely this could add a level of complexity to properly manage it:
We will first need to create an index that includes nested fields for our catalog structure and geo_shape fields for geospatial data. This will allow us to perform properly searches on each bbox of the list but it's a quite complex approach.
Another option, probably easier, is to encode the multiple extents as a single multi-polygon (multiple bboxes) so the search will be accurate and performed on all of the extents in one shot.
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):