Add CPHD, SICD, and SIDD to sar:product_type

[jmorrison1847]

I have actually two favors to ask:

1. One new Type called Phase History which is similar to, but not the same as, complex data
2. Three new sar:product_type:

• Compensated Phase History Data (CPHD) | Phase History
• Sensor Independent Complex Data (SICD) | Complex
• Sensor Independent Detected Data (SIDD) | Amplitude

Each of these is a very highly specified form of standard ("sensor independent") metadata requirements and organization created by the National Geospatial Intelligence Agency. You'll start to notice them in the API and product documentation for every commercial customer with aspirations to sell to them, and it would be wonderful to help encourage these organizations to use STAC.

[m-mohr]

Please note that the table in https://github.com/stac-extensions/sar#sarproduct_type is not meant to be exhaustive / complete, it is just a list of suggestions. But I'm happy to discuss and accept PRs with the community. :-)

[emmanuelmathot]

similar comment as per https://github.com/stac-extensions/sar/issues/9#issuecomment-1172046369. I read about those sensor independent format some time ago and there are indeed interesting, especially in the ARD context. IMO, It is worth to list them in the documentation but I'd like to have concrete samples to base STAC item examples on. @jmorrison1847, would you have some to recommend?

[jmorrison1847]

@emmanuelmathot apologies for the radio silence, I just forgot to check Github for a month. Showing my true colors...

A great example of this just happened in the time since posting it - Capella released sample data via AWS that includes a collection of SICD files compliant with the STAC standard.

You can get to it by going to the main page on the AWS open data website and navigating to the STAC Catalog or STAC Browser on the right-hand side there: https://registry.opendata.aws/capella_opendata/

[pmallas]

Well, this is probably going to open a can of worms, but does product type mean processing level or file format? Because a SICD is basically a SLC in NITF format. And a SIDD would be likely a GEC or GTC type product in NITF. CPHD would be RAW (as S1 calls them). I don't think these two things should be conflated.

[m-mohr]

Processing level!

File Format should be specified in the asset property type.

[emmanuelmathot]

Yes the sar:product_type is the combination of the SAR operating mode and the processing level. It should easily give information about the data you'll find inside (amplitude, phase...) and it's refining (raw, geocoded, terrain corrected...). So it is better if we keep using "common" types, especially for cross-mission search in the catalogs.

[pmallas]

I put together (hopefully error-free), the five general processing levels available from current vendors (or at least, the ones I am familiar with) and what they call their processed product levels. I think there should be a generic name, one per level. This not include derived products (like RTC). Let me know what you think.

Data Description	Sentinel-1	RADARSAT-2	TerrsSAR-X	COSMO SkyMed	Capella	Iceye	Umbra
Raw phase history	RAW	RAW	SRE	RAW	CPHD	None	CPHD
Single-look, slant range, complex data	SLC	SLC	SSC	SCS	SLC, SICD	SLC	SICD
Multilooked, ground range, satellite-path geometry, detected data	GRD	SGF, SGX, SGC, SCN, SCW	MGD	DGM	None	GRD	None
Multilooked, ground range, geocorrected, detected data	None	SSG, SPG	GEC	GEC	GEC, SIDD*	None	GEC, SIDD*
Multilooked, ground range, terrain corrected, detected data	None	SSG, SPG	EEC	GTC	GEO, SIDD*	None	SIDD*

*These formats support ellipsoid corrected and terrain corrected data

[pmallas]

Also, I don't think "Single-look Ground projected Complex image" is a thing.

The SLC entry for Sentinel-1 - that is certainly not ground projected.

[m-mohr]

Closing in favor of #14