Improve Source Processing Object

[maawoo]

Hi @m-mohr,

currently the bandwidth fields of the source processing object are in my opinion too ambiguous and it should be more explicit which number belongs to which beam ID. Also considering that other missions might use this extension in the future.

This is how our implementation currently looks (with values still in Hz 😉):

"card4l:source_processing_parameters": {
      "lut_applied": "IW_Default",
      "range_look_bandwidth": {
        "iw1": 56500000.0,
        "iw2": 48300000.0,
        "iw3": 42789918.40322842
      },
      "azimuth_look_bandwidth": {
        "iw1": 327.0,
        "iw2": 313.0,
        "iw3": 314.0
      }
    }

Let me know what you think and I could also include this in #8. I'll likely fail with the json schema though.

[m-mohr]

So the idea is that it's easy to read so I decided to go with an array, this way you don't end up with random object keys that have no inherent order. Can you elaborate more on why this is better/less ambiguous than what we have right now?

[maawoo]

Here is a list of possible swath IDs* from the Sentinel-1 Product Specification:

I'm not familiar with the swath IDs of other SAR missions, but as you can see there are a lot of possible IDs. Those are, however, not 'random object keys' but defined for each mission and then consistently used across metadata, software, etc. I think that this kind of information should be close to the data. A user shouldn't have to search for documents or Github repos only to find out which number in an array belongs to which swath ID. Furthermore, this can secure the automation of processes or the scraping of metadata. Of course, we can just assume the values in an array are always stored in an ascending order based on the numbered swath IDs. But as the creation of the metadata is left to data providers/users, this is a source of error. At least with the keys we could identify permutations with the json schema:

      "azimuth_look_bandwidth": {
        "iw1": 327.0,
        "iw3": 314.0,
        "iw2": 313.0
      }

      "azimuth_look_bandwidth": [
        327.0,
        314.0,
        313.0
      ]

*I mentioned beam IDs above. I actually think that's a mistake in the CARD4L documents. At least for some of the fields such as look bandwidth.

[m-mohr]

Go for an object for "azimuth_look_bandwidth" etc as proposed above.