Radar: Requirements that need new STAC extensions / fields

[m-mohr]

Required:

• 1.6.4 Source Data Acq. Params (observation mode, antenna pointing, beam ID)
• 1.6.5 Source Data Orbit Info (Orbit data source)
• 1.6.6 Source Data Processing Params (separate range number of looks values for each beam)
• 1.6.7 Source Data Image Attrs (Geometry slant/groung range, near/far indident angle)
• 1.6.9 Performance Indicators
• 1.7.6: Product Filtering
• 1.7.10 Product Pixel Coordinate Convention
• 1.7.12 Look Direction Polynomials [ORB only]
• 1.7.13 Radar Unit Look Vector [GSLC only]
• 1.7.14 Slant Range Sensor to Surface [GSLC only]
• ...
• 4.3 Geometric Accuracy

Optional missing pieces are not listed.

Open issues:

• SAR: Relax metadata format requirements in 2.1 ceos-org/ceos-ard#25
• SAR: Req. category 1.6 ambiguous and unnecessary? ceos-org/ceos-ard#26
• SAR: Req. 1.7.9 - File Header Size ceos-org/ceos-ard#27

[abradley60]

Hi Matthias, thought I would follow up on this issue given you have already flagged a few of the 'missing' parameters.

We have been undergoing the development of our STAC metadata to meet the CEOS-ARD PFS for SAR v1.1 specifications for our NRB product. Most of the required parameters for compliance are supported through existing STAC extension fields. For the fields not currently supported (such as those you have listed above), I have temporarily introduced two new tags nrb: and sourcedata: as these mainly address missing information for the source data and and NRB-specific processing. The table below shows the CEOS-ARD section and the tag I am proposing.

We can keep these in the metadata with the tags I have proposed, but I thought it would be a good time to reach out and see if you were planning to build on any existing extensions to accommodate these (for example, adding some of these as ceosard:). I have also attached a draft sample metadata.json file which has most of these proposed tags included with values.

Note I could cover the threshold requirements for some of the sections you list above with existing extensions. I can send through my self-assessment if you would like to see these.

Let me know if you have any questions, happy to catch up again if needed.

Product Family Specification, Synthetic Aperture Radar v1.1

Section	CEOS-ARD product	General Metadata	Proposed STAC Fields
1.6.6	[ALL]	Source Data Processing Parameters	sourcedata:id sourcedata:product_type sourcedata:product_level sourcedata:processing_facility sourcedata:processing_date sourcedata:software_version sourcedata:number_of_looks_range sourcedata:number_of_looks_azimuth
1.6.7	[ALL]	Source Data Image Attributes	sourcedata:geometry sourcedata:reference_geometry sourcedata:pixel_spacing_azimuth sourcedata:pixel_spacing_range sourcedata:resolution_azimuth sourcedata:resolution_range sourcedata:near_range_incident_angle sourcedata:far_range_incident_angle
1.6.9	[ALL]	Performance Indicators	sourcedata:max_noise_equivalent_sigma_zero
1.7.3	[ALL]	Product Sample Spacing	nrb:pixel_spacing_x nrb:pixel_spacing_y
1.7.4	[NRB] [POL] [ORB]	Product Equivalent Number of Looks	nrb:multilooking_method  (fixed_window or adaptive) nrb:number_of_looks_range (if fixed window) nrb:number_of_looks_azimuth (if fixed window)
1.7.5	[ALL]	Product Resolution	nrb:resolution_x nrb:resolution_y
1.7.6	[NRB] [POL] [ORB]	Product Filtering	nrb:speckle_filter_applied nrb:speckle_filter_type nrb:speckle_filter_window
3.1	[ALL]	Backscatter Measurements	nrb:measurement_type nrb:measurement_convention
3.2	[ALL]	Scaling Conversion	nrb:conversion_eq
3.3	[ALL]	Noise Removal	nrb:noise_removal_applied
4.3	[ALL]	Geometric Accuracy	nrb:geometric_accuracy_range nrb:geometric_accuracy_azimuth nrb:geometric_accuracy_ALE nrb:geometric_accuracy_rmse   OR ADD these to accuracy extension   https://github.com/stac-extensions/accuracy

Sample Draft Metadata File

metadata.json

[m-mohr]

Hey!

A bit of background context: We had an old and complete CARD4L (former name of CEOS-ARD) extension, which include the properties you are looking for: https://github.com/stac-extensions/card4l/blob/main/sar/README.md

Due to the renaming and our learnings from the old extension, we have decided to go for another route in the future and instead of adding missing properties to the CEOS/CARD4L extensions, we dtrive to create more generic extensions that can be reused by others (not with a ceosard: prefix, rather with something more generic, e.g. extending the sar extension or creating something separate). Proprietary fields are not very interoperable, so I'd try to avoid ceos prefixed fields etc. The proposal to extend accuracy could be followed, for example. If you want you can reuse the old card4l: fields for now, given that they will be deprecated at some point (but the same would likely happen with your own additions?!). But your nrb: prefixed fields would also be fine for now, but maybe consider that the CEOS-ARD product column in your example shows that the fields would also apply to other products and as such the nrb: prefix is a little too specific if someone would implement other product types.

The sourcedata: prefiexed fields don't make sense in STAC context though. In STAC it's a bad practice to mix product and source metadata in a single Item. Instead, you'd create multiple items (1 for product, 1+ for sources). In the source file you can then reuse the existing STAC extensions without creating new proprietary fields, e.g. you'd use processing:facility instead of sourcedata:processing_facility and product:type instead of sourcedata:product_type. This would make most or all of your sourcedata: prefixed fields obsolete.

Having that said, it's planned that I continue working on this, but due to other priorities within CEOS, it will not be withing this year, I assume. We could try to discuss some of the changes in the generic extensions though, e.g. in SAR and Accuracy.

Hope this helps...

[abradley60]

Thanks for the advice Matthias that does help (sorry for the delayed response). This is still a WIP so I may reach out again but this is helpful.