Re: Proposal for the inclusion of new packages
Dear Francesco,
Il 01/07/23 14:14, Francesco P. Lovergine ha scritto:
On Sat, Jul 01, 2023 at 10:20:17AM +0200, Antonio Valentino wrote:
Dear Sebastiaan dear all,
please find below a list of Python packages that IMHO could be
interesting to have in Debian GIS.
* MetPy: https://github.com/Unidata/MetPy
MetPy is a collection of tools in Python for reading, visualizing and
performing calculations with weather data.
* eodag: https://github.com/CS-SI/eodag
EODAG (Earth Observation Data Access Gateway) is a command line tool
and a plugin-oriented Python framework for searching, aggregating
results and downloading remote sensed images while offering a unified
API for data access regardless of the data provider.
Antonio,
nice to hear about that from you. Indeed, I still have not see any
activity about the Copernicus API switching in sentinelsat for their
issue #583, so python3-sentinelsat would become obsolete after September
2023.
About that, probably we would have a couple of possibility
for stable:
- simply asking for dropping the package
- asking for updating to a future(?) version which eventually
includes the new API.
I have still not totally lost the hope that something could evolve on
the sentinelsat front.
Let's see.
EOdag could be a nice tool to use even for accessing Sentinel data,
at least by rumors.
Yes, eodag seems to be promising and have a very nice design.
Moreover, the company developing it is directly involved in the
activities in the Copernicus Data Ecosystem.
At the moment, by the way, it still does not have all the nice features
of sentinelsat.
Regarding the download of sentinel data, probably it would be a good
idea to consider also tools like asf-search
(https://github.com/asfadmin/Discovery-asf_search) and asfsmd
(https://github.com/avalentino/asfsmd) to download data from the ASF
archive.
Specially for archive data ASF is quite handy because all the products
are always online, they do not have the concept of Long Term Archive (LTA).
* A set of packages developed by the Laboratory for Ocean Physics and
Satellite remote sensing (https://github.com/umr-lops), mostly xarray
based libraries to access Synthetic Apreture Radar data:
- xsar: https://github.com/umr-lops/xsar
- xarray-safe-s1: https://github.com/umr-lops/xarray-safe-s1
- xarray-safe-rcm: https://github.com/umr-lops/xarray-safe-rcm
- xradarsat2: https://github.com/umr-lops/xradarsat2
- xarray-ceos-alos2: https://github.com/umr-lops/xarray-ceos-alos2
- xsarsea: https://github.com/umr-lops/xsarsea
+ xrft: https://github.com/xgcm/xrft
* A set of tools for working with SpatioTemporal Asset Catalogs (STAC)
(https://github.com/stac-utils):
- pystac: https://github.com/stac-utils/pystac
- pystac-client: https://github.com/stac-utils/pystac-client
- stactools: https://github.com/stac-utils/stactools
- MEDIUM PRIORITY
+ stac-check: https://github.com/stac-utils/stac-check
+ stac-validator: https://github.com/stac-utils/stac-validator
+ stac-vrt: https://github.com/stac-utils/stac-vrt
PySTAC and friends are a must IMHO. I still had not time to
work onto our next tool chain for being up-to-date on those regarfs, I
surely will work on that from the of July and August and can
evaluate many of those tools. If you already had comments about
that it would be great.
I cannot say that I'm an expert user at the moment, but I plan to use
them quite intensely for job in the coming months.
stac-validator and stac-check seem to be quite in overlap.
Apparently stac-check includes also a linting feature that is always
nice to have.
- LOW PRIORITY
- stac-task: https://github.com/stac-utils/stac-task
- xstac: https://github.com/stac-utils/xstac
- xpystac: https://github.com/stac-utils/xpystac
- stac-terminal: https://github.com/stac-utils/stac-terminal
- stactools packages (https://github.com/stactools-packages)
+ https://github.com/stactools-packages/sentinel1
+ https://github.com/stactools-packages/sentinel1-grd
+ https://github.com/stactools-packages/sentinel2
+ https://github.com/stactools-packages/sentinel3
+ https://github.com/stactools-packages/sentinel5p
+ https://github.com/stactools-packages/landsat
+ https://github.com/stactools-packages/palsar
+ https://github.com/stactools-packages/esa-worldcover
+ https://github.com/stactools-packages/esa-cci-lc
+ https://github.com/stactools-packages/cop-dem
+ https://github.com/stactools-packages/alos-dem
+ https://github.com/stactools-packages/ecmwf-forecast
+ https://github.com/stactools-packages/datacube
+ https://github.com/stactools-packages/browse
I think that it would be very important to have in Debian at least
pystack, pystack-client and stacktools. The other ones are maybe less
relevant. Maybe we could select a subset and discuss about priorities.
For all the above packages I have not even started the packaging work.
I would like to hear your opinion before doing it.
I could definitively give an hand with some of those packages,
after prioritization.
From my side I would tend to start from packages for SAR data and for
DEM (with priority for Copernicus related ones).
Please note that, at the moment, I have not included any server side
package for STAC. That could be also something interesting to consider.
A final comment regarding ESA SNAP.
I have not included it in the list because I remember that you made an
analysis of the licenses an there was something blocking.
Could you please point me to the relevant email thread?
Maybe something is changed in the meanwhile.
kind regards
--
Antonio Valentino
Reply to: