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

timeliness #1

Closed
emmanuelmathot opened this issue Apr 29, 2024 · 7 comments
Closed

timeliness #1

emmanuelmathot opened this issue Apr 29, 2024 · 7 comments
Assignees

Comments

@emmanuelmathot
Copy link
Member

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:

  • Near Real-Time (NRT): delivered less than 3 hours after data acquisition.
  • Short Time-Critical (STC): delivered within 36 (Sentinel-6) to 48 (Sentinel-3) hours after data acquisition.
  • Non Time-Critical (NTC): delivered typically within 1 month after data acquisition.

https://creodias.eu/cases/timeliness-and-frequency-of-sentinel-satellite-products-explained/

@m-mohr m-mohr self-assigned this Apr 29, 2024
@m-mohr
Copy link
Contributor

m-mohr commented Apr 29, 2024

But why can't this be expressed as Durations so that people can search for this?
The values that providers sometimes use are non-standardized and not overly helpful, can pretty much be omitted.

@ycespb
Copy link

ycespb commented May 3, 2024

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.

@m-mohr
Copy link
Contributor

m-mohr commented May 3, 2024

So what values could we put in the enum that people agree on?
Just using a free-text string doesn't make a lot of sense to me. Then it's not useful for search and we can just omit the field.

@emmanuelmathot
Copy link
Member Author

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 NRT, NTC, STC and Nominal

@emmanuelmathot
Copy link
Member Author

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.
The idea is then to have another field timeliness_code expressing the timeliness code (e.g. NRT, STC, ...)

@m-mohr
Copy link
Contributor

m-mohr commented May 6, 2024

Sounds good to me. Can we come up with a suggested list of common values similar to processing:level for example?
Edit: In the ESA logs the field is named product:timeliness_category

@m-mohr
Copy link
Contributor

m-mohr commented May 8, 2024

Should be solved with eea5ac4 and 597fbc1

For further comments or issues please open a new issue.

@m-mohr m-mohr closed this as completed May 8, 2024
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

No branches or pull requests

3 participants