sar:product_type to sat extension ?

[ycespb]

Product_type (defined in the "sar" extension) is a useful property, not only for SAR granules. Could it not be moved to a more general extension such as "sat" to use it for optical and other instruments ? Alternatively, a similar "product_type" property could be added to the "sat" extension as well.

[m-mohr]

On the one hand, I see that it can be useful for other products that are not SAR. On the other hand, I think it's useful for search to either a specific enum or at least some common values for better alignment between catalogs and those values should be listed in the corresponding extensions. This also allows to search product of specific "types", like only for SAR or only UAV if we add uav:product_type for example. Another question is whether it's best suited in SAT or somewhere else? Product Types don't seem to be really SAT specific and could also be part of aerial imagery, UAVs etc. This might even go into Common Metadata as there's no better place yet.

[ycespb]

Agree this is not specific for satellites. Is the EO extension assumed to be more general than "SAT" and a better place then ? We also have sensorType, operationalMode etc if you want to make precise searches and these do not only apply to "sar" instruments... The mapping for these is currently not obvious in https://github.com/stac-utils/stac-crosswalks/blob/master/OGC_17-003r2/README.md. Would be nice to give these a proper place and allow for a mapping.

[m-mohr]

EO (Electro-Optical! - not Earth Observation) is not really suitable for SAR, so then we wouldn't have the product_type for SAR any longer. I don't really know yet where to put it... @matthewhanson

[matthewhanson]

I think it might better belong in common metadata, but we would want recommendations on how to use it for different types of data. Optical data would have product types for surface reflectance or TOA, while SAR we have enumerated.

What other types of datasets would use products?

[ycespb]

The OGC specs https://docs.opengeospatial.org/is/10-157r4/10-157r4.html and https://docs.opengeospatial.org/is/17-003r2/17-003r2.html were the result of consultations with many agencies and productType is in both specs a property that can be used for any mission (optical (opt), radar (sar), altimetric (alt), synthesis, etc.) It may have ground-segment or mission specific values. E.g. the altimetric mission Cryosat-2 has about 20 possible values like SIR_GDR2, SIR_GOP2, SIR_GOPM_2, SIR_GOPM1B... Note that in the layered representations of earth observations (shown below copied from OGC 10-157r4, including SAR), productType was a property at the "EOP" thus most general level.

[m-mohr]

Yeah, I feel like we should make product_type common metadata, but clearly refer to the extensions which define potential values.

[cholmes]

On call 1-4-21 we decided we should have one more discussion on this before release.

Allow in common but don't allow any values? And extensions can only put values in.

[cholmes]

Ok, discussed on a call, and we decided to not move ahead with this since it becomes just a free text field that anyone can put anything in. We should encourage extensions to re-use the product_type field, but each should define their own enumeration of the values that are expected there. If in a couple years there really emerges a consensus of X number of product types that people actually use (or a standards org defines 'these are the product types') we could upgrade it to be in core.

[m-mohr]

=> https://github.com/stac-extensions/product