-
Notifications
You must be signed in to change notification settings - Fork 37
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
Conversation
…pt at handling overlaps.
for more information, see https://pre-commit.ci
…pand_time_resolutions # Conflicts: # tests/test_time_res_method.py
Codecov Report
Additional details and impacted files@@ 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
|
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. |
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
…pand_time_resolutions
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
…pand_time_resolutions
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?
|
return "solar_day" | ||
else: | ||
return group_by_statistical() | ||
return self.time_resolution.dataset_groupby(is_mosaic=self.mosaic_date_func is not None) |
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 am surprised flake8 let this long line through
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.
Must be just under the limit.
The implementation here is to label the timestep with the start date:
This doesn't support what you want - but does make supporting it much easier (in future PRs). |
Major refactor of time resolution handling.
There are now only 3 time resolution options:
solar
Replaces the old "raw" option - local-solar-day time model, used for imagery captured in daily swathes by satellites in heliosynchronous orbits.
summary
Replaces the old
day
,month
, andyear
options. Only looks at the "start" datetime, and so neatly supports products withoverlapping or non-exclusive dataset date-ranges. Expects the time portion of the start date to always be "midnight UTC". Used for summary/calculated products.
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
andsummary
options explicitly ignore the time component of thetime
parameter passed by the user. If you need the time component to be significant, you must usesubday
. Thesubday
option closes #876This 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/