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

additional values for sensortype #1

Closed
ycespb opened this issue Jan 31, 2024 · 5 comments
Closed

additional values for sensortype #1

ycespb opened this issue Jan 31, 2024 · 5 comments

Comments

@ycespb
Copy link

ycespb commented Jan 31, 2024

Could the type property (sensor-type) values which are also useful beyond (CEOS) ARD be extended with other sensor type values and for example align with the codelist values proposed for sensorType in https://docs.ogc.org/is/17-003r2/17-003r2.html#table_16 ?

@m-mohr
Copy link
Contributor

m-mohr commented Feb 23, 2024

You mean ceos_ard:type? In principle yes, but it's meant to reflect the types defined by CEOS for ARD PFS and they only distinguish between Optical and Radar right now. So this is an upstream change, I just reflect the CEOS ARD types here. Be aware, this field is meant to identify the CEOS ARD PFS, this is not meant to be a generic sensor type field. Whenever CEOS would add another type, we'd also add it here.

@ycespb
Copy link
Author

ycespb commented Feb 26, 2024

@m-mohr, my understanding is that the ARD "Product Family Specifications" ( or their identifiers) are sufficient and define uniquely the CEOS ARD PFS specification and the type of data they apply to (See https://ceos.org/ard/). In my opinion, CEOS is defining the "PFS" and not specific values for "type"... A codelist for "sensor types" makes sense even without a PFS having been defined or for metadata not intending to comply with an existing ARD PFS for such "type" of data.

@m-mohr
Copy link
Contributor

m-mohr commented Feb 26, 2024

In my opinion, CEOS is defining the "PFS" and not specific values for "type"

Don't quite agree, the type field here just reflects what is provided here (+ version and PFS):
grafik

Whether this is needed or not is another question on its own.

A codelist for "sensor types" makes sense even without a PFS having been defined or for metadata not intending to comply with an existing ARD PFS for such "type" of data.

Yes, but it's not the scope of this extension.

Right now I don't see a todo for this extension. Can this be closed and/or potentially be moved to somewhere else?

@emmanuelmathot
Copy link
Member

A quite old issue is till open on the same subject here. Maybe it is worth considering a real sensor extension?

@m-mohr
Copy link
Contributor

m-mohr commented Feb 27, 2024

I agree, let's move this to radiantearth/stac-spec#1124 - The CEOS ARD extension is certainly not the right place for it.

@m-mohr m-mohr closed this as not planned Won't fix, can't repro, duplicate, stale Feb 27, 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