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

Enhanced time resolution handling (subday and overlapping summary periods) #933

Merged
merged 38 commits into from
Mar 17, 2023

Conversation

SpacemanPaul
Copy link
Contributor

@SpacemanPaul SpacemanPaul commented Mar 9, 2023

Major refactor of time resolution handling.

There are now only 3 time resolution options:

  1. solar
    Replaces the old "raw" option - local-solar-day time model, used for imagery captured in daily swathes by satellites in heliosynchronous orbits.
  2. summary
    Replaces the old day, month, and year options. Only looks at the "start" datetime, and so neatly supports products with
    overlapping or non-exclusive dataset date-ranges. Expects the time portion of the start date to always be "midnight UTC". Used for summary/calculated products.
  3. subday
    New option.
    Used for for products with multiple time values per day (e.g. hourly/minutely data). Uses the "start" datetime of the dataset.

Note that the solar and summary options explicitly ignore the time component of the time parameter passed by the user. If you need the time component to be significant, you must use subday. The subday option closes #876

This ended up being a quite extensive PR requiring a significant overhaul of test frameworks which in turn uncovered several long-standing bugs at the intersection of various OWS features - which this PR also fixes.

I am now fairly confident that this PR introduces no major regressions on previously existing functionality.


📚 Documentation preview 📚: https://datacube-ows--933.org.readthedocs.build/en/933/

@codecov
Copy link

codecov bot commented Mar 9, 2023

Codecov Report

Merging #933 (64e294f) into master (3ee0c2a) will decrease coverage by 0.27%.
The diff coverage is 90.60%.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #933      +/-   ##
==========================================
- Coverage   94.00%   93.73%   -0.27%     
==========================================
  Files          43       43              
  Lines        6385     6496     +111     
==========================================
+ Hits         6002     6089      +87     
- Misses        383      407      +24     
Impacted Files Coverage Δ
datacube_ows/wcs1_utils.py 94.91% <75.00%> (-1.21%) ⬇️
datacube_ows/wms_utils.py 92.08% <76.47%> (-1.18%) ⬇️
datacube_ows/data.py 83.63% <84.00%> (-0.51%) ⬇️
datacube_ows/product_ranges.py 83.70% <87.75%> (+1.83%) ⬆️
datacube_ows/mv_index.py 96.70% <95.23%> (-0.60%) ⬇️
datacube_ows/ows_configuration.py 95.96% <98.24%> (+0.06%) ⬆️
datacube_ows/update_ranges_impl.py 87.70% <100.00%> (ø)
datacube_ows/utils.py 100.00% <100.00%> (ø)
datacube_ows/wcs2.py 92.38% <100.00%> (+0.14%) ⬆️
datacube_ows/wcs2_utils.py 91.70% <100.00%> (+0.33%) ⬆️

... and 3 files with indirect coverage changes

@robbibt
Copy link
Contributor

robbibt commented Mar 9, 2023

This looks super cool! Could new the "subday" support potentially support @mitchharley's coastal photography use case I mentioned a while back, i.e. potentially multiple georeferenced GeoTIFFs per day across time?

@SpacemanPaul
Copy link
Contributor Author

This looks super cool! Could new the "subday" support potentially support @mitchharley's coastal photography use case I mentioned a while back, i.e. potentially multiple georeferenced GeoTIFFs per day across time?

Yes! #876 is the GH issue I referred to in that Twitter thread.

@SpacemanPaul SpacemanPaul marked this pull request as ready for review March 17, 2023 04:54
@robbibt
Copy link
Contributor

robbibt commented Mar 17, 2023

Not so much a review as a question about how this may work for our upcoming DEA Intertidal product: do you think these changes will support the following scenario?

  • A multi-timestep product with overlapping 3 year median composites, e.g.:
    • timestep 1: 2019, 2020, 2021 data
    • timestep 2: 2020, 2021, 2022 data
    • timestep 3: 2021, 2022, 2023 data etc
  • In OWS/Terria, we will probably want data to be labelled with the "middle" year for each composite, e.g.:
    • 2020 timestep: 2019, 2020, 2021 data
    • 2021 timestep: 2020, 2021, 2022 data
    • 2022 timestep: 2021, 2022, 2023 data etc

return "solar_day"
else:
return group_by_statistical()
return self.time_resolution.dataset_groupby(is_mosaic=self.mosaic_date_func is not None)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am surprised flake8 let this long line through

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Must be just under the limit.

@SpacemanPaul SpacemanPaul merged commit c5ecdea into master Mar 17, 2023
@SpacemanPaul SpacemanPaul deleted the expand_time_resolutions branch March 17, 2023 05:47
@SpacemanPaul
Copy link
Contributor Author

* In OWS/Terria, we will probably want data to be labelled with the "middle" year for each composite, e.g.:
  
  * 2020 timestep: 2019, 2020, 2021 data
  * 2021 timestep: 2020, 2021, 2022 data
  * 2022 timestep: 2021, 2022, 2023 data etc

The implementation here is to label the timestep with the start date:

  • 2019 timestep: 2019, 2020, 2021 data
  • 2020 timestep: 2020, 2021, 2022 data
  • 2021 timestep: 2021, 2022, 2023 data etc

This doesn't support what you want - but does make supporting it much easier (in future PRs).

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 this pull request may close these issues.

Sub-day time resolution support
3 participants