Re: Proposal for the inclusion of new packages
Dear Francesco,
Il 01/07/23 16:50, Francesco P. Lovergine ha scritto:
On Sat, Jul 01, 2023 at 03:31:07PM +0200, Antonio Valentino wrote:
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.
As in the first days of the Science Hub - when I wrote a scihub
downloader myself - I was considering to eventually
replace the obsolete API with the new one (the non STAC one) in
sentinelsat and submit a PR. Shouldn't be too much complicated
because both them are REST interfaces.
Of course I hate duplicating the efforts, so I'm just procrastinating
the task, just in case one of the committers was still interested
in the tool evoluton.
understood
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.
Yep, I even saw that folks that worked on the i.sentinel.download
Grass add-on are looking at eodag because it would be more general.
I'm quite sure it is an interesting tool to generalize data access
to free satellite data, including Landsat.
I'm not persuaded that eodag would be a package light enough to be
considered as a Python dependency for other tools, on those
regards: probably PySTAC would be much more appropriate.
Interesting point, I didn't consider this aspect.
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.
For what it's worth, my main goal in considering packaging activity
for d-gis is selecting packages which are stable and sustainable
enough in the medium/long run. For all the rest, the PyPI and other hubs
are more than enough.
understood
- 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.
The server side STAC support would be of interest even here, to
share maps and metainfo in a more evolute way.
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.
Ah, ESA Snap is PITA for licensing. I'm now quite sure it does not embed
JAI (not more perphaps), but even for building of the desktop tool you
would need Install4J which is not free, AFAIK.
Even, it embeds a full special edition of JRE with pieces taken
from JAVAFX. IMHO packaging such a beast is not woth the giant effort
requited (you also should check tons of licenses and an upload would
stay in
queue for months/years waiting ftpmasters).
I'm quite sure that you should provide an alternative build setup, even.
And the result would not be guaranteed. I don't know about you, but in
my case I have no possibility to extend a day to 48hs :-)
A downloader with a few postinst hacks to prepare a decent setup
would be more than enough.
Honestly, this kind of approach is exactly that I had in mind.
But still I would need to check the licenses and understand if we need
to prompt for some kind of EULA, correct?
Regarding postinst scripts, if you already have something in mind,
please let me know.
cheers
--
Antonio Valentino
Reply to: