-
Notifications
You must be signed in to change notification settings - Fork 25
Update datetime filter #396
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
Conversation
filter=[ | ||
Q("exists", field="properties.start_datetime"), | ||
Q("exists", field="properties.end_datetime"), | ||
Q( | ||
"range", | ||
properties__start_datetime={"lte": datetime_search["lte"]}, | ||
), | ||
Q( | ||
"range", | ||
properties__end_datetime={"gte": datetime_search["gte"]}, | ||
), | ||
], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this enough to give all possible combinations of datetime overlap? This looks like it will only return items whose date range entirely encapsulates the searched for date range.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test case shows overlap.
# Test 5: Range matching null-datetime-item but not range-item's datetime
feature_ids = await _search_and_get_ids(
app_client,
params={
"datetime": "2020-01-01T12:00:00Z/2020-01-02T12:00:00Z",
"collections": [collection_id],
},
)
assert feature_ids == {
"null-datetime-item", # Overlaps: search range [12:00-01-01 to 12:00-02-01] overlaps item range [00:00-01-01 to 00:00-02-01]
}, "Range search excluding range-item datetime failed"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm reading the test correctly the null-datetime-item
items has a date range of 2020-01-01T00:00:00Z
to 2020-01-02T00:00:00Z
and the search is 2020-01-01T12:00:00Z/2020-01-02T12:00:00Z
so the searched date range it entirely within the item's date range. If the searched for range's end date was extended by a day so was 2020-01-01T12:00:00Z/2020-01-03T12:00:00Z
I suspect the item wouldn't be returned. Is that the desired behaviour? I thought that if there was any overlap then the item should be returned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be mixed up, but the item has a 24hr. date range and so does the query so they do overlap?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The end date of the search is outside the items end date
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry yes you're 100% right! I didn't realise datetime_search["lte"]
was the end date of the search and datetime_search["gte"]
was the start. This is a really neat way of doing this search!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is pretty neat
), | ||
Q( | ||
"bool", | ||
must_not=[Q("exists", field="properties.datetime")], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as below.
), | ||
Q( | ||
"bool", | ||
must_not=[Q("exists", field="properties.datetime")], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current best practices recommends that you populate datetime
even if you have a date range.
"The specification does allow one to set the datetime field to null, but it is strongly recommended to populate the single datetime field, as that is what many clients will search on. If it is at all possible to pick a nominal or representative datetime then that should be used."
So we should probably loosen the search (remove this line?) or update the recommended practice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know. I think the best practices are recommended but may not always be relevant for all types of data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rhysrevans3 Can you look at this issue #396? I am not 100% sure on what the right approach should be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that for some items, defined by start and end datetimes, it may not make sense to set a datetime value just for the sake of doing so. The stac spec itself allows null datetime values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're right both the case for a null
or set datetime when start and end dates are used needs to be handled. What's the expected behaviour when the datetime is set? I would expect it to search on all date fields. If that's the case then I think the must_not=[Q("exists", field="properties.datetime")]
can be removed. I think the current query will ignore start and end dates if the datetime is set. Is that expected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you thinking of documenting this in the readme or maybe something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could have a few options; default - this one maybe, start and end datetimes included, only datetime
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was more thinking of a way to tell the user doing the search which behaviour to expect. But I can't think of a good place to put it, other than the queryables endpoint maybe? But including it in the readme is probably enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll open an issue for this so we can work on it later. We can definitely use logging too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related Issue(s):
Description:
PR Checklist:
pre-commit run --all-files
)make test
)