make rasters work with products that cross antimeridian

[vincelhx]

files concerned are files that cross the antimeridian (RS2/RCM/S1). Before the PR, an error was generated.
rasters are concerned because there is an operation of mapping the raster on the grid, it requires continuity.

[vincelhx]

remark : the footprint in dataset.attrs will be defined from longitudes in [-180;180], so the Polygon is not good. The footprint comes from BaseMeta.footprint that comes from BaseMeta.geoloc.

Note that if we apply BaseDataset.recompute_attrs() for the cases that cross antimeridian, the footprint get defined in [0,360], as in BaseDataset.footprint and the polygon is correct.

At the moment we decide to keep the .dataset['footprint'] polygon to have an homogeneous code.

[agrouaze]

No remarks on the code itself.
But on the PR, can you:

• describe the scope of the PR (is it for RS2, RMC and S1?, what was the status before this PR? why ECMWF raster is impacted?)
• can you add a unit test with a real product crossing the anti meridian or a mock product?
• can you confirm sphinx compiles successfully
• can you confirm pytest are successful

[vincelhx]

files concerned are files that cross the antimeridian (RS2/RCM/S1). Before the PR, an error was generated.
rasters are concerned because there is an operation of mapping the raster on the grid, it requires continuity.

[vincelhx]

https://github.com/umr-lops/mapraster will make map_raster out of xsar

[oceanscoper]

I agree that adding a (or several) unit test for the specific case of anti-meridian crossing is a good idea !

[vincelhx]

@agrouaze doc OK

[vincelhx]

review

[vincelhx]

just waiting for the conda version of 'mapraster'

[vincelhx]

@agrouaze @oceanscoper mapraster is now on conda-forge. could you validate this PR?

[vincelhx]

reviewed