search

OSGeo / grass-addons

GRASS GIS Addons Repository
https://grass.osgeo.org/grass-stable/manuals/addons/
GNU General Public License v2.0
104 stars 154 forks source link

i.sentinel: Usage of an alternative data source for Sentinel-2 data #417

Open griembauer opened 3 years ago

griembauer commented 3 years ago

The Problem

Since all Sentinel-2 data from ESA's SciHub that is older than 12 months is moved to a long-term-archive (LTA), getting data from this time period is difficult and time-consuming, and was only now made feasible via i.sentinel.download (https://github.com/OSGeo/grass-addons/pull/415).

Possible Solutions

It would be preferable to add an option to use an alternative data source with full Sentinel-2 archive and no LTA for i.sentinel. The most obvious choice would be the USGS Earth Explorer (although maximum Sentinel-2 preprocessing level there is L1C).

@veroandreo already created an addon downloading Landsat data from the USGS Earth Explorer in i.landsat. This addon in turn relies on the really helpful python library landsatxplore by @yannforget for communication with the USGS API. Some first tests indicate that landsatxplore can be easily adapted to also allow the download of Sentinel-2 data from the USGS API (https://github.com/yannforget/landsatxplore/issues/27).

However, the current version of the USGS API used by landsatxplore will be deprecated on March 17,2021 (new API documentation available here).

Because of this, there would be two main options to implement USGS support to i.sentinel(.download):

What do you think @neteler @lucadelu @veroandreo @mlennert @anikaweinmann? Of course there can be also more options than this. Maybe someone even knows a completely different data-source for Sentinel-2 data?

lucadelu commented 3 years ago

The Problem

Since all Sentinel-2 data from ESA's SciHub that is older than 12 months is moved to a long-term-archive (LTA), getting data from this time period is difficult and time-consuming, and was only now made feasible via i.sentinel.download (#415).

Possible Solutions

It would be preferable to add an option to use an alternative data source with full Sentinel-2 archive and no LTA for i.sentinel. The most obvious choice would be the USGS Earth Explorer (although maximum Sentinel-2 preprocessing level there is L1C).

Yes this would be really great!

Because of this, there would be two main options to implement USGS support to i.sentinel(.download):

  • Adapt landsatxplore for Sentinel-2 support and implement it into i.sentinel.download. This would require fewer changes for i.sentinel.download, but would assume that landsatxplore is updated to handle the new version of the USGS API. @yannforget, maybe you could comment on whether this is currently planned?

This could be the best solution for me, and I could help if needed

yannforget commented 3 years ago

Yes, I plan to update landsatxplore to the new API before the depreciation. I'll keep you updated :)

For S2 data I was also planning to write something based on Google Cloud (https://cloud.google.com/storage/docs/public-datasets/sentinel-2).

mlennert commented 3 years ago

I think using an enhanced landsatexplore sounds like a good solution, especially if that means that @yannforget gets some support from other developers.

In the long run it would obviously be nice to have some generic library that handles different data sources and different data types, and whose maintenance could be shared amongst more teams, but I don't know how realistic this is.

Moritz

yannforget commented 3 years ago

The DLR is working on an integrated solution to access multi-spectral and SAR imagery catalogs (dlr-eoc/ukis-pysat). For now they are using sentinelsat, landsatxplore and pylandsat, but the objective seems to harmonize everything under the SpatioTemporal Asset Catalogs spec.

neteler commented 3 years ago

See also new PR #419

griembauer commented 3 years ago

Thank you all for the feedback and thank you @yannforget for the flexibility and continuous support of landsatxplore ;) I started experimenting a little in #419 but the implementation is not very ideal so far. @lucadelu (and of course everyone interested) if you want you can have a look, adapt,etc. I will try to optimize/complement.