i.sentinel.download: use EODAG as a unified API for downloading sentinel products

[HamedElgizery]

This PR will reimplement i.sentinel.download making use of the i.eodag module to use the EODAG API as the main source of Sentinel products.

[lucadelu]

It seems a big simplification, as soon it will be ready to test let us know.

[HamedElgizery]

@neteler @ninsbl
I was looking for these two products S3OL1RAC & S3OL1SAC on EODAG but they don't exist on Copernicus.
I did find the first one, S3OL1RAC, on two other providers (WEKEO & SARA), but for the second product, S3OL1SAC, I don't seem to find it anywhere. Do you have any suggestion about them and if they are necessary to have?

[veroandreo]

I left a couple of comments. Would you mind updating the manual page too, so it's easier to test?

[HamedElgizery]

I left a couple of comments. Would you mind updating the manual page too, so it's easier to test?

Thanks @veroandreo, I will update the manual ASAP.

[ninsbl]

Do you have any suggestion about them and if they are necessary to have?

S3 OL 1 RAC is an internal product. Perfectly fine to drop it... Not sure what the background of the SAC product has been. But I did not find documentation either. So fine to drop as well...

[ninsbl]

A general question is how backwards-compatibility is handled or if we should put a lot of effort into it?

Some features will disappear in this PR (e.g. possibility to download from DHUS portals = sentinelsat).

Personally, I would give priority to basic tests in i.eodag...

[HamedElgizery]

Thanks for the review, @ninsbl.

Personally, I would give priority to basic tests in i.eodag...

I will be working on that in parallel with this PR now.
This PR should be ready soon, as I think what is remaining for the most part is:

1. Updating the manual.
2. Emulate the -p flag to give a similar output as the previous implementation.

Is there any points that I might have not recognized?

[ninsbl]

I will be working on that in parallel with this PR now. This PR should be ready soon, as I think what is remaining for the most part is: (...)
2. Emulate the -p flag to give a similar output as the previous implementation.

For me it is no problem if the format of printed info changes a bit after switching to eodag... Not an issue I would invest a lot of time in. As mentioned, I think there will be breaking changes anyway...

[veroandreo]

There are unresolved conversations here, a merging conflict and then we need an approval to merge. Can you please check the unresolved conversations and merge conflict @HamedElgizery ? After that I'd merge and do a second round of review once all is in

[ninsbl]

As @veroandreo mentioned, backwards compatibility is not that a hard requirement for addons, But I think users should get a heads-up (GRASS-dev / GRASS-users ML) before breaking changes are submittet.

[veroandreo]

As @veroandreo mentioned, backwards compatibility is not that a hard requirement for addons, But I think users should get a heads-up (GRASS-dev / GRASS-users ML) before breaking changes are submittet.

I agree we can do a courtesy heads up, but that's not common practice for addons really. COAH and sentinelsat stopped working almost one year ago, so users of i.sentinel should already know, I suppose.

I am moreover for merging this, update the manual with a notice about COAH and sentinelsat not working anymore, and sending an email afterwards.

[ninsbl]

I am moreover for merging this, update the manual with a notice about COAH and sentinelsat not working anymore, and sending an email afterwards.

No objections from my side...

[wenzeslaus]

Please wait for OSGeo/grass#4205 to be merged, then restart the failing job.