-
Notifications
You must be signed in to change notification settings - Fork 1
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
timeliness #1
Comments
But why can't this be expressed as Durations so that people can search for this? |
I agree that the values should be strings as the different categories (NRT product, consolidated product) this property indicates may be more important than the exact number of hours (duration). When performances improve you may also not want to have to change the "duration" value in all your metadata. Also in https://docs.ogc.org/is/17-003r2/17-003r2.html#table_20, the consensus was to use a string for this field. |
So what values could we put in the enum that people agree on? |
This is very related to the ground segment product output. That is why a free text make sense to me. Then when it is used for copernicus missions, you'll have |
Following discussions with ESA, there is a need to express both duration and codification of the timeliness since they may be not aligned across missions. |
Sounds good to me. Can we come up with a suggested list of common values similar to processing:level for example? |
Timeliness is also a quite abstract concept that becomes specific to the mission and the related ground segment.
The value type for the
product:timeliness
should be a simple string.For instance, under the Copernicus programme, products are released on three levels of timeliness:
https://creodias.eu/cases/timeliness-and-frequency-of-sentinel-satellite-products-explained/
The text was updated successfully, but these errors were encountered: