Closed zakjan closed 1 year ago
When writing the spec, I was actually thinking about this "lifecycle" in https://github.com/stac-extensions/timestamps/#lifecycle, but I agree that your proposed way also make sense. Looking forward to some more opinions.
Also discussed right now in #1. This will certainly be changed.
I've updated the Readme accordingly.
The spec for datetime emphasises that it should be the most useful datetime for a user to search for. It's allowed to contain a representative datetime instead of an acquisition datetime.
I'm wondering whether reference and forecast datetime could be swapped in regards to the above? I.e. forecast datetime would be a primary datetime in
datetime
, and reference datetime would be a secondary datetime e.g. inforecast:reference_datetime
.Also, it would improve the usability of required Collection Temporal Extent Object in
extent.temporal
. As old forecasts are always marked as deprecated and cleaned up frequently, it would be more useful if the temporal extent contains a forecast temporal extent instead of a reference temporal extent.