cs-si / eopf-stac-extension Goto Github PK

It looks like this extensions heavily mixes concerns: some fielda are about ids, some are instrument-related, same are processing-related, etc. It feels like everything that wasn't found yet in STAC was just put into one place. That's not a good idea, I think. Also, what's the relation with other extensions:

For example, pixel_classification seems related to the classification extension. It may need some improvements (stac-extensions/classification#47) but generally, the changes should probably be made there instead of adding a new field.

Image size seems related to proj:shape. Shouldn't this be part of the bands, too?

eopf:instrument_mode seems related to sar:instrument_mode, but you may need that for additional types of instruments of course.
Same for eopf:instrument_swath, this should probably be proposed as a general purpose field, e.g. in an instrument extension?

Generally, many of these fields don't look overly EOPF specific. I'd try to avoid that to not run into a proprietary niche regarding tooling support.

Regarding eopf:type:
producttype is present in older catalog standards, but STAC did not include it as a standard property, which I consider a very good decision.
In 99% of cases, a collection should contain a single producttype, because collections with multiple product types are often too heterogenous, so the collection level metadata becomes so generic that it's effectively useless.

I've seen examples where the collection is simply 'sentinel-3', and the wide variety of sentinel-3 product types is contained in that collection. Hence it becomes impossible to create sensible collection level metadata.

Of course, I don't object to having the propery, as it can also be set to the same value for all items in a given collection, although I'm afraid that it will invite catalog providers to create overly heterogenous collections. Hence it requires a clear warning in the documentation of this extension if we want to avoid that.