SAR: Req. category 1.6 ambiguous and unnecessary?

[m-mohr]

The "category" 1.6 in the Radar PFS seems to describe a requirement, but it's unclear whether it's a minimum or goal requirement:

Note: Source data attribute information are described for each acquisition and sequentially identified as acqID= 1, 2, 3, …

While I can easily make the attribute information available for each acquisition through derived_from links in STAC, there's no standardized way to specify an id that follows the 1, 2, 3, ... numeration approach.

Also, I'm wondering isn't this implicitly define by the acquisition timestamps? Let's say I link to all acquisitions and they have distinct timestamps associated with them, shouldn't that be enough to create a sequence of images? Do we really need to enfore the 1,2,3 numbeing? It's fine if that's required in the XML spec, but it would be great if I don't need to do that in STAC.

cc @akerosenqvist

[akerosenqvist]

Item 1.6 "Source Data Attributes" and item 1.7 "CEOS-ARD Product Attributes" is the way the SAR PFS accommodates multi-source products.

In the case a CEOS-ARD product is generated from more than one data source (such as a mosaic product), the parameters 1.6.1 - 1.6.12 will need to be provided for each of the source data. The same parameter names are thus repreated several times (as many times as there are datatakes) in the metadata file and the "acqID" parameter is therefore required to indicate which datatake a given parameter refers to (so in this sense, it is indeed a Threshold requirement). See example here: https://www.dropbox.com/scl/fi/0u93aqhh4lcyvu205xxbg/N83W080_2023_F02DAR.xml?rlkey=vk6zb3t3b8it80lwafafurmmr&dl=0

How you resolve this in the STAC extension, I'd need to understand the alternatives better in order to have an opinion. I've copied in John again.

CC: @johntruckenbrodt

[m-mohr]

@akerosenqvist That's understood, thanks.

In STAC the Source data + metadata is located in other STAC Items that the product links to. The product STAC Item marks then as "derived from" the following source(s) ... It doesn't make sense in STAC to number then. That an encoding specific that should be in the XML metadata spec, I think. acqID is not defined in the PFS, it's an XML encoding detail. In STAC you can derive the sequence from the timestamps of the individual STAC Items of the source data. I believe that should work and give the same order as just 1,2,3,... , but the PFS doesn't allow it but insists on numbers.

I think the quote above should be split into two pieces:

PFS PDF:

Note: Source data attribute information are described for each acquisition and must idenfity the sequence of the acquisitions, e.g. through the acquisition timestamps or an enumerated list.

XML Spec:

Note: The source data for each acquisition must be sequentially identified as acqID= 1, 2, 3, …

or something similar.

[m-mohr]

I guess I found the place why the acqID is as it is: It's in req 2.8. But there it actually also seems to allow day or time references instead of ID...

[akerosenqvist]

Adding @francoischarbonneau to the discussion

[johntruckenbrodt]

@m-mohr, exactly, the ID was meant to correspond to the numbering in 2.8. Perhaps just describing in 2.8 that the numbering corresponds to the list of source images sorted by acquisition time in ascending order would be enough.

[strobpr]

I believe techniques such as 'mosaicking' or 'data fusion' are relevant beyond SAR and should not be buried here. The real issue I see behind this is that the distinction between 'general' and 'per pixel' metadata, which we so far have prominently in all PFSs (afaik), becomes inadequate as soon as we allow 'mosaicking', starting with different acquisition times, to later different sensors and missions.

We should have this discussion, but for that we need a better categorisation of product types and/or processing levels and what they exactly entail.