CARD4L SAR Extension (NRB + POL)

[m-mohr]

The STAC CARD4L SAR Extension has been migrated to a separate repository: https://github.com/stac-extensions/card4l/tree/main/sar

[fangfy]

• In the current xml, IncAngleNearRange and IncAngleFarRange are for the source data, which means this doesn't necessarily correspond to actual incidence angle range for this output. If the view:incidence_angle is intended to be for the sensor, then it's appropriate to use the middle point angle.
• The SAR extension has a few product type defined, so it should be RTC in that list (CARD4L requires RTC). However, the Sentinel-1 product has backscatter provided as power/intensity, not amplitude. Therefore, an additional field is needed in the sar extension.
• There are a few pieces of important information related to processing that's not yet in STAC, e.g. filtering (whether a speckle filter has been applied to the data), thermal noise removal (whether it has been applied), not sure whether they should be in "about".
• where does processing time and software + version go in STAC?

[cholmes]

Looks great. One minor typo fix that I tried to put as a commitable suggestion. Psyched to see this added to STAC.

[m-mohr]

@fangfy Thank you for your comments, very much appreciated! Sorry for the delay, I was waiting for #907 to be merged.

• In the current xml, IncAngleNearRange and IncAngleFarRange are for the source data, which means this doesn't necessarily correspond to actual incidence angle range for this output. If the view:incidence_angle is intended to be for the sensor, then it's appropriate to use the middle point angle.

I understand the spec the way that view:incidence_angle indeed is intended to be for the sensor.

• The SAR extension has a few product type defined, so it should be RTC in that list (CARD4L requires RTC). However, the Sentinel-1 product has backscatter provided as power/intensity, not amplitude. Therefore, an additional field is needed in the sar extension.

@matthewhanson What do you think? You proposed RTC, but what would be the preferred way out? Should we add more product types for SAR or go another route?

• There are a few pieces of important information related to processing that's not yet in STAC, e.g. filtering (whether a speckle filter has been applied to the data), thermal noise removal (whether it has been applied), not sure whether they should be in "about".

We are likely not capturing all details in STAC, but they are available in the additional XML file that is required anyway, right?

• where does processing time and software + version go in STAC?

We've recently introduced the processing extension with PR #907. There are now fields for things like software + version and I'll add that now to the proposal.

[fangfy]

• There are a few pieces of important information related to processing that's not yet in STAC, e.g. filtering (whether a speckle filter has been applied to the data), thermal noise removal (whether it has been applied), not sure whether they should be in "about".

We are likely not capturing all details in STAC, but they are available in the additional XML file that is required anyway, right?

CARD4L doesn't require XML, if all required metadata can be provided in STAC, then only one metadata file is needed.

[m-mohr]

I've finished writing up the document that captures (I hope) all requirements from CARD4L SAR NRB and POL in a single STAC extensions. It got pretty heavy and was quite a bit of effort, but I've now also included a "pure" STAC mode, if you don't want the XML derived from the CARD4L metadata spec. The question is how to proceed with this? Is there a way to get that through some CEOS review or so? For example there is an open question re 1.7.3 in the document... In the best case we could finalize it with CEOS and actually make it somewhat official or so. Read it here: https://github.com/radiantearth/stac-spec/blob/card4l-sar-nrb/extensions/card4l-sar/README.md
@fangfy @alexgleith

[fangfy]

Thank you, @fangfy. I highly appreciate that you took the time and have added your feedback here. It's just in time for us to implement it. I've applied all suggested changes and updated the document accordingly, but some additional comments below:

1. Re 1.7.3: ProductColumnSpacing, ProductRowSpacing are the actual product sampling. They should be in meter or degree (in ground geometry as required by CARD4L, therefore different to the sar:pixel_spacing_azimuth and sar:pixel_spacing_range which are in radar geometry).

In STAC sar:pixel_spacing_azimuth and sar:pixel_spacing_range are always in meters, so it sounds like they could really be used for Src and Prod. I've changed the document accordingly.

Problem is the _azimuth and _range part, which are relative to sensor not ground, so they don't apply to card4L product.

1. the metadata assets (2.3 -2.6) should have relevant unit defined.

I've added a card4l:unit flag that can be set, but we could maybe remove it if it's always the same unit?

The units are different for the different images, hence it's important.

1. for the backscatter image assets (or as overall metadata), BackscatterMeasurement (should be gamma0 for CARD4L, but for other radar product, this can be sigma0, beta0 etc), and BackscatterConvention (amplitude or power, this is important!) should be defined. These two (and probably a few others) would make most sense to be included in the sar extension.

I couldn't find these metadata entries in the official CARD4L SAR NRB metadata specification. Have I missed them? If they are missing there, why are they missing there if this information is important? Also, which part of the specification requires them? It's a bit strange to require them but not list the requirement number.

They are listed as parameters in the backscatter measurements (3.1). They do apply directly to the backscatter images/assets.

I hope these help to clarify. Thanks heaps for implementing these!

[m-mohr]

Thank you again, @fangfy!

Problem is the _azimuth and _range part, which are relative to sensor not ground, so they don't apply to card4L product.

In #962 I'm now proposing some additional fields to be added to the SAR extension. I hope I understood things correctly with my limited SAR knowledge. Thus there are separate fields for row and column. I'd appreciate if you could have a look at PR #962.

The units are different for the different images, hence it's important.

I was not giving the idea clear enough, I think. I meant if it's a fixed unit for the individual assets, one may not give them, but I'm fine to just leave them in and make it explicit.

They are listed as parameters in the backscatter measurements (3.1). They do apply directly to the backscatter images/assets.

Thank you, I found them now and also looked at POL again to align better. I have also tried to add those to the SAR extension directly, see #962.

[m-mohr]

The STAC CARD4L SAR Extension has been migrated to a separate repository: https://github.com/stac-extensions/card4l/tree/main/sar