Skip to content

Invalid parameter used in eodag search request for polarisation mode

This issue has been reported on the discourse forum.

The issue

We are calling eodag.EODataAccessGateway.search() method with polarizationMode to filter what is of interest. The actual parameter expected by eodag seems to be polarisation: it will be translated to what each provider actually expects.

Tombé en marche

As a consequence, as of now, data download only works with PEPS.

If it has appeared to be working so far, it's because most tests were conducted with PEPS (which knows how to translate polarizationMode), and because eodag plainly forwards unknown keys as they are received instead of returning an error.

Related issues?

Fixing this is required to interact with any other data provider. It also concerns GDH.

Workaround

In the mean time, it possible to work around the issue for other providers by injecting the requested bindings in ~/.config/eodag/eodag.yml. We need to extract the binding for polarizationChannels used with the provider we use. The reference bindings can be found in eodag/resources/providers.yml

For Copernicus, it could be solved in the following way:

cop_dataspace:
...
  search:   # Search parameters configuration: the part that needs the patch
    metadata_mapping:
      polarizationMode:
        - polarisation
        - '$.properties.polarisation'
...

Searching for the exact parameter

At this point, I not sure what the exact parameter needs to be. eodag#154 addresses a similar issue of API harmonization.

Setting eodag log level to INFO, we can observe that:

When using `polarizationMode=..."

  • PEPS is sent: https://peps.cnes.fr/resto/api/collections/S1/search.json?polarisation=VV VH&sensorMode=IW&orbitDirection=descending&relativeOrbitNumber=110&platform=S1A&startDate=2023-11-01&completionDate=2023-11-10&geometry=POLYGON ((0.5332 42.3384, 0.5332 43.3474, 1.9047 43.3474, 1.9047 42.3384, 0.5332 42.3384))&productType=GRD&maxRecords=20&page=1

  • But Copernicus is sent: http://catalogue.dataspace.copernicus.eu/resto/api/collections/Sentinel1/search.json?polarizationMode=VV VH&sensorMode=IW&orbitDirection=descending&relativeOrbitNumber=110&platform=S1A&startDate=2023-11-01&completionDate=2023-11-10&geometry=POLYGON ((0.5332 42.3384, 0.5332 43.3474, 1.9047 43.3474, 1.9047 42.3384, 0.5332 42.3384))&productType=GRD&maxRecords=20&page=1&exactCount=1

When using polarizationChannels=

  • Copernicus is sent: http://catalogue.dataspace.copernicus.eu/resto/api/collections/Sentinel1/search.json?polarisation=VV VH&sensorMode=IW&orbitDirection=descending&relativeOrbitNumber=110&platform=S1A&startDate=2023-11-01&completionDate=2023-11-10&geometry=POLYGON ((0.5332 42.3384, 0.5332 43.3474, 1.9047 43.3474, 1.9047 42.3384, 0.5332 42.3384))&productType=GRD&maxRecords=20&page=1&exactCount=1

  • PEPS is sent: https://peps.cnes.fr/resto/api/collections/S1/search.json?polarizationChannels=VV VH&sensorMode=IW&orbitDirection=descending&relativeOrbitNumber=110&platform=S1A&startDate=2023-11-01&completionDate=2023-11-10&geometry=POLYGON ((0.5332 42.3384, 0.5332 43.3474, 1.9047 43.3474, 1.9047 42.3384, 0.5332 42.3384))&productType=GRD&maxRecords=20&page=1

    and it still seems OK

When using polarisation=

It's sent exactly as to PEPS as well as Copernicus and still works fine.