Skip to content
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

Handling start_datetime and end_datetime? #5

Closed
lossyrob opened this issue Jun 22, 2021 · 2 comments · Fixed by #38
Closed

Handling start_datetime and end_datetime? #5

lossyrob opened this issue Jun 22, 2021 · 2 comments · Fixed by #38

Comments

@lossyrob
Copy link
Member

There's some datasets that do not have a datetime, but instead have a start_datetime and end_datetime. For example, a landcover dataset that represents a year of data - there's no single datetime to represent the data. STAC specifies that in this case datetime is null and the start_datetime and end_datetime is set.

How can pgstac handle these types of items?

@bitner
Copy link
Collaborator

bitner commented Jul 12, 2021

We can create a composite that stores/indexes the datetime as a tstzrange datatype that is set to an instant (range start = range end) and use postgresql inbuilt range operators (similar to postgis bbox operators) to query between the stac record time range and the passed in start/end times.

We could also keep the start/end of the stac record as separate start/end where we merge in the datetime such that start_datetime = coalesce(datetime, start_datetime) and end_datetime = coalesce(datetime, end_datetime) and use appropriate bilateral less than and greater than statements.

I think the biggest question is do we always want to use some sort of "merged" time to query against or only with a flag or in certain circumstances.

@paudley
Copy link

paudley commented Jul 28, 2021

The tztsrange solution would certainly be more flexible for queries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants