mundialis / esa-snap Goto Github PK

Docker image of ESA Sentinel Application Platform (SNAP) from http://step.esa.int/main/toolboxes/snap/ . Download at https://hub.docker.com/r/mundialis/esa-snap

License: GNU General Public License v3.0

Dockerfile 54.54% Shell 45.46%

sentinel snap snappy sentinel-1 sentinel-2 docker-image hacktoberfest

esa-snap's Introduction

ESA SNAP 9 docker images

Docker images of ESA Sentinel Application Platform (SNAP) from http://step.esa.int/main/toolboxes/snap/

The related docker images are created and available for download from here:

https://hub.docker.com/r/mundialis/esa-snap

Tag	Description	GitHub branch	Base image	Size	docker pull command
s1tbx	Only s1tbx toolbox	s1tbx	Alpine 3.18 based	1.4 GB	`docker pull mundialis/esa-snap:s1tbx`
latest	Only s1tbx toolbox	s1tbx	Alpine 3.18 based	1.4 GB	`docker pull mundialis/esa-snap:latest`
ubuntu	All SNAP toolboxes	ubuntu	Ubuntu 18.04 based	2 GB	`docker pull mundialis/esa-snap:ubuntu`

Installation

Pull the Alpine Linux based image (only SNAP Sentinel-1 toolbox):

docker pull mundialis/esa-snap:latest

Tutorial

We recommend the following tutorial:

http://step.esa.int/docs/tutorials/SNAP_CommandLine_Tutorial.pdf

Usage examples

SNAP Graphical User Interface - GUI

Using the GUI, among other functionality the GraphBuilder is available.

Start of GUI, with volume mapping of current directory (pwd; may be set to a different directory) to /data/ within docker:

docker run -it --rm --volume="$(pwd)/:/data" \
    --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" \
    --env DISPLAY=$DISPLAY --device="/dev/dri/card0:/dev/dri/card0" \
    mundialis/esa-snap:latest \
    /usr/local/snap/bin/snap

SNAP Graph Processing Tool - command line

Using the SNAP Graph Processing Tool (GPT):

# show help of gpt tool
docker run -it --rm mundialis/esa-snap:latest /usr/local/snap/bin/gpt -h

One can pass the required processing settings in an XML-encoded graph file which is passing this graph as parameter to the gpt tool:

docker run -it --rm mundialis/esa-snap:latest /usr/local/snap/bin/gpt <GraphFile.xml> [options] [<source-file-1> <source-file-2> ...]

For further gpt usage please refer to the official documentation.

Background info

This docker image is based on Alpine Linux and only contains the s1tbx toolbox. Furthermore,

the original installer provided by ESA ships its own oracle java
Alpine is based on musl libc and busybox. As Oracle JAVA depends on glibc, it doesn't work smoothly. With https://github.com/sgerrand/alpine-pkg-glibc this can be workarounded to a certain way but in our case not sufficient (conflicting dependencies).
From SNAP Version 8, oracle java > 8 and openjdk in general will be supported officially (https://forum.step.esa.int/t/problems-running-tests-in-intellij/9350/8)

Where is the Ubuntu based docker image?

Find the Ubuntu based docker image related files in branch ubuntu (see here). See there for related instructions.

Alpine dev stuff

Alternatively, a build approach was tried out. Kept here if needed further. As the stable SNAP version 7.0.2 needs maven 3.6.0 (while alpine offers 3.6.3), so SNAP 8 was built for testing.

FROM alpine:edge

<!-- ARG SNAP_ENGINE_TAG=8.0.0 -->
ENV JAVA_HOME "/usr/lib/jvm/java-1.8-openjdk"

RUN apk add git openjdk8 maven
RUN git clone https://github.com/senbox-org/snap-engine.git /src/snap/snap-engine
WORKDIR /src/snap/snap-engine
<!-- RUN git checkout $SNAP_ENGINE_TAG -->
RUN sed -i 's+<module>snap-classification</module>+<!--<module>snap-classification</module>-->+g' pom.xml
RUN mvn clean install -DskipTests

WORKDIR /src/snap/s1tbx
git clone https://github.com/senbox-org/s1tbx.git /src/snap/s1tbx
cd s1tbx
mvn clean install

WORKDIR /src/snap/snap-enginge
java -cp snap-runtime/target/snap-runtime.jar org.esa.snap.runtime.BundleCreator ../snap.zip "/src/snap/snap-engine" "/src/snap/s1tbx"

esa-snap's People

Contributors

Stargazers

Watchers

esa-snap's Issues

Update alpine image after snappy supports more recent python

From https://github.com/orgs/actinia-org/discussions/395:

ninsbl
[...]
Meanwhile, Alpine 3.18 is out. And the biggest obstackle that I encountered for now (or the first blocker in a way), is snappy, which does not seem work with more recent Python/jpy versions. See e.g.:
https://forum.step.esa.int/t/problem-installing-snappy-on-mac-m1/37032

The problem in short: Snappy does not support jpy > 0.9.0 and jpy <= 0.9.0 does not work with Python > 3.9...

and as a response from the esa forum:

marpet
With the next release (scheduled for end of June) there will be a revised version compatible with newer Python version (at least 3.10).

So let's hope that python 3.11 will be supported which is contained in alpine 3.18 to which we are upgrading the actinia images.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

dockerfile

Dockerfile

alpine 3.18

github-actions

.github/workflows/docker.yml

actions/checkout v4@b4ffde65f46336ab88eb53be808477a3936bae11

docker/metadata-action v5

docker/setup-qemu-action v3

docker/setup-buildx-action v3

docker/login-action v3

docker/build-push-action v5

Check this box to trigger a request for Renovate to run again on this repository

Back-Geocoding crashes with SNAP 8 (Alpine)

Hello,
I used to call the Back-Geocoding operator with mundialis/esa-snap:s1tbx-7.0v2.
I had to install an old version of libgfortran using the following commands :

FROM mundialis/esa-snap:s1tbx-7.0v2
RUN apk add curl &&
curl -O http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/libgfortran-10.2.1_pre1-r1.apk &&
apk add libgfortran-10.2.1_pre1-r1.apk

It worked well.

But I don't manage to call the Back-Geocoding operator using the latest mundialis/esa-snap:s1tbx (snap v8).

I have the following fatal error :

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000002076, pid=112, tid=0x00007fe66b8b9b20
#
# JRE version: OpenJDK Runtime Environment (8.0_232-b09) (build 1.8.0_232-b09)
# Java VM: OpenJDK 64-Bit Server VM (25.232-b09 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea 3.14.0
# Distribution: Custom build (Tue Mar  3 13:24:22 UTC 2020)
# Problematic frame:
# C  0x0000000000002076
#
# Core dump written. Default location: //core or core.112
#
# An error report file with more information is saved as:
# //hs_err_pid112.log
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   https://icedtea.classpath.org/bugzilla
#
Aborted (core dumped)

I don't manage to make it work...

I can provide the full error report file if needed.

Thank you for your help

Vincent

SNAP 9.0: ESA releases new and improved version of SNAP

There is a new SNAP release which may be worth packaging:

https://step.esa.int/main/download/snap-download/

--> The current version is 9.0.0 (29.06.2022 15:00 UTC).

I'm a new SNAP user, any suggestions on where to find this on the image so I can add it to the PATH? I'm interested in using gpt to run my workflow since I've heard from others that it is faster and less prone to out of memory errors than snappy.

Topographic phase removal

I've been trying to create an interferogram for my research but I keep getting an OperatorException error at the topographic phase removal stage. The error says "A problem has occurred during target product initialisation", without a message. What could the problem be?

Alpine docker image: java.lang.UnsatisfiedLinkError

At time the Alpine build shows an error (only with master but not with s1tbx branch):

(https://hub.docker.com/repository/registry-1.docker.io/mundialis/esa-snap/builds/6208008b-0d7b-4813-9db0-aa11c7bfbf95)

Step 28/29 : RUN /usr/bin/python3 -c 'from snappy import ProductIO'
---> Running in 1ddf37da2ed9
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: GDAL not found on system. Internal GDAL 3.0.0 from distribution will be used. (f1)

INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: Internal GDAL 3.0.0 set to be used by SNAP.

Native library load failed.

java.lang.UnsatisfiedLinkError: /root/.snap/auxdata/gdal/gdal-3-0-0/lib/jni/libgdalalljni.so: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /root/.snap/auxdata/gdal/gdal-3-0-0/lib/jni/../libgdal.so.26)


SEVERE: org.esa.s2tbx.dataio.gdal.GDALLoader: Failed to initialize GDAL native drivers. GDAL readers and writers were disabled.java.lang.reflect.InvocationTargetException

INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing external tool adapters
INFO: org.esa.snap.core.util.EngineVersionCheckActivator: Please check regularly for new updates for the best SNAP experience.

Removing intermediate container 1ddf37da2ed9
---> 0058cf302741
Step 29/29 : RUN /usr/bin/python3 /root/.snap/about.py
---> Running in 9922a10ae5a8
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: GDAL not found on system. Internal GDAL 3.0.0 from distribution will be used. (f1)
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: Internal GDAL 3.0.0 set to be used by SNAP.

Native library load failed.
java.lang.UnsatisfiedLinkError: /root/.snap/auxdata/gdal/gdal-3-0-0/lib/jni/libgdalalljni.so: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /root/.snap/auxdata/gdal/gdal-3-0-0/lib/jni/../libgdal.so.26)

SEVERE: org.esa.s2tbx.dataio.gdal.GDALLoader: Failed to initialize GDAL native drivers. GDAL readers and writers were disabled.java.lang.reflect.InvocationTargetException
INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing external tool adapters
INFO: org.esa.snap.core.util.EngineVersionCheckActivator: Please check regularly for new updates for the best SNAP experience.

JVM size: 9102.5 MB
SNAP VERSION: 8.0

Not sure of this is related to #8 but a fix might be needed.

Infinite loop while downloading DEM in mundialis/esa-snap:ubuntu docker image

Hi,

I am using the mundialis/esa-snap:ubuntu as a base image for building my own image. My algorithms run a typical pre-processing routine on Sentinel-1. When arriving at the Range-Doppler Terrain Correction step my workflow gets stuck in the following infinite loop where it tries to retrieve a DEM:

INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving http://download.esa.int/step/auxdata/dem/SRTM90/tiff/srtm_39_03.zip
INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving https://download.esa.int/step/auxdata/dem/SRTM90/tiff/srtm_39_03.zip
INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/srtm_39_03.zip
SEVERE: org.esa.snap.core.dataop.dem.ElevationFile: Server returned HTTP response code: 403 for URL: http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/srtm_39_03.zip

I found some solutions in ESA STEP Forum such as this but they are not applicable in this case.

The strange part is that there is instability in the following sense:

Case 1

Run a container
Run my algorithm
Gets stuck and CTRL+C
Re-run algorithm
Gets stuck and CTRL+C
Problem never gets solved

Case 2

Run a container
Run my algorithm
Gets stuck and CTRL+C
Re-run algorithm
Works perfectly from now on and the infinite loop never shows up again

Case 3

Running Terrain Correction from GUI -from another machine though- always works.

Case 4 (UPDATE)

Run a container
Run my algorithm (with SRTM 3Sec as dem name)
Gets stuck and CTRL+C
Run my algorithm (with SRTM 3 Sec as DEM name: Notice the spacebar added)
Algorithm spits errors (see message below) and CTRL+C
Run my algorithm (with SRTM 3Sec as DEM name again)
Works perfectly from now on and the infinite loop never shows up again (same happens if I use another valid DEM instead of SRTM 3Sec for the first run of my algorithm)

Message in step 5:

INFO: org.esa.snap.core.gpf.common.WriteOp: Start writing product Subset_S1B_IW_GRDH_1SDV_20180810T051813_20180810T051838_012196_016778_3134_Orb_NR_Cal_TC to /home/AOIs/aoi_1/stage_1/S1B_IW_GRDH_1SDV_20180810T051813_20180810T051838_012196_016778_3134_Sub_orb_TNR_cal_TC
The DEM 'SRTM 3 Sec' is not supported.
The DEM 'SRTM 3 Sec' is not supported.
SEVERE: org.esa.snap.core.util.SystemUtils$SnapImagingListener: JAI error occurred: 'Problem occurs when computing a tile by the owner.' at com.sun.media.jai.util.SunTileScheduler@479225c9
org.esa.snap.core.gpf.OperatorException: The DEM 'SRTM 3 Sec' is not supported.
        at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:440)
        at org.esa.s1tbx.sar.gpf.geometric.RangeDopplerGeocodingOp.computeTileStack(RangeDopplerGeocodingOp.java:1067)
        at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeRect(OperatorImageTileStack.java:122)
        at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeTile(OperatorImageTileStack.java:86)
        at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
        at javax.media.jai.OpImage.getTile(Unknown Source)
        at javax.media.jai.PlanarImage.getData(Unknown Source)
        at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
        at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:449)
        at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:435)
        at org.esa.snap.core.gpf.internal.OperatorImage.computeRect(OperatorImage.java:75)
        at javax.media.jai.SourcelessOpImage.computeTile(Unknown Source)
        at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
        at javax.media.jai.OpImage.getTile(Unknown Source)
        at com.sun.media.jai.util.RequestJob.compute(Unknown Source)
        at com.sun.media.jai.util.WorkerThread.run(Unknown Source)
Caused by: org.esa.snap.core.gpf.OperatorException: The DEM 'SRTM 3 Sec' is not supported.
        at org.esa.s1tbx.sar.gpf.geometric.RangeDopplerGeocodingOp.computeTileStack(RangeDopplerGeocodingOp.java:846)
        ... 14 more
Caused by: java.io.IOException: The DEM 'SRTM 3 Sec' is not supported.
        at org.esa.snap.dem.dataio.DEMFactory.getDemDescriptor(DEMFactory.java:375)
        at org.esa.snap.dem.dataio.DEMFactory.createElevationModel(DEMFactory.java:77)
        at org.esa.s1tbx.sar.gpf.geometric.RangeDopplerGeocodingOp.getElevationModel(RangeDopplerGeocodingOp.java:490)
        at org.esa.s1tbx.sar.gpf.geometric.RangeDopplerGeocodingOp.computeTileStack(RangeDopplerGeocodingOp.java:843)
        ... 14 more

Notes

I have implemented this from 3 different public IPs, so it is not a "blacklisted IP issue"
It's not an issue of too many requests, because in a matter of seconds (i.e., deleting and rebuilding my image/container) the behavior can be different (e.g., sometimes it works after running my algorithm only once and some others it does not)
I am modifying the value of this key DEM.srtm3GeoTiffDEM_HTTP=http://download.esa.int/step/auxdata/dem/SRTM90/tiff/ both manually and automatically (using sed) prior to first run of my algorithm, without any luck.
Updating SNAP does not help