Re-enable SNAP but without Snappy #70
Conversation
|
|
||
| # GRASS GIS SETUP | ||
| COPY --from=grass /usr/local/bin/grass /usr/local/bin/grass | ||
| COPY --from=grass /usr/local/grass* /usr/local/grass/ | ||
| # COPY --from=grass /usr/lib/gdalplugins/*_GRASS* /usr/lib/gdalplugins/ |
There was a problem hiding this comment.
If you don't copy the GDAL plugins, you might loose quite a lot of GDAL/OGR drivers, depending on the configuration of GDAL.
There was a problem hiding this comment.
Note that this commented line is just added in this PR, nothing was copied before either.
The missing GDAL plugins that are on the osgeo/grass-gis:releasebranch_8_3-alpine but not on the base image actinia:alpine-dependencies are:
- gdal_PNG.so
- gdal_GRASS.so
- ogr_GMLAS.so
- ogr_GRASS.so
- ogr_LIBKML.so
- ogr_MSSQLSpatial.so
- ogr_ODBC.so
but gdal_GRASS.so and ogr_GRASS.so are installed here
There was a problem hiding this comment.
OK, so this Docker file uses GDAL from actinia:alpine-dependencies. In this case it would cause conflicts to copy GDAL plugins from osgeo/grass-gis:releasebranch_8_3-alpine. But GRASS has been compiled against GDAL in osgeo/grass-gis:releasebranch_8_3-alpine, therefore the GDAL versions in the two different images must be the same, otherwise you get errors running GRASS. Considering this, your solution to compile the GDAL GRASS plugin later on in this Dockerfile seems to be the safest option.
There was a problem hiding this comment.
The GDAL versions in the grass image and actinia image are the same GDAL 3.6.4, released 2023/04/17 but this is definitely something we need to be aware of!
| # install GDAL GRASS plugin (required for i.sentinel1.pyrosargeocode) | ||
| RUN mkdir -p /usr/lib/gdalplugins | ||
| RUN git clone https://github.com/OSGeo/gdal-grass.git | ||
| RUN cd gdal-grass && ./configure --with-gdal=/usr/bin/gdal-config --with-grass=/usr/local/grass83 \ | ||
| && make && make install | ||
| RUN cd .. && rm -rf gdal-grass | ||
|
|
There was a problem hiding this comment.
I would prefer these lines to be in the Dockerfile_alpine_dependencies. The goal is to have as much there with a scheduled build which can take as long as it needs and then to have as little things installed here as possible to make the build as quick as possible.
There was a problem hiding this comment.
If I understand correctly, the GRASS installation comes from FROM osgeo/grass-gis:releasebranch_8_3-alpine as grass. This means that Dockerfile_alpine_dependencies does not have any GRASS installed, but the gdal-grass plugin needs to be installed with an existing GRASS and GDAL installation:
RUN cd gdal-grass && ./configure --with-gdal=/usr/bin/gdal-config --with-grass=/usr/local/grass83 \
&& make && make install
So moving the gdal-grass lines to Dockerfile_alpine_dependencies yields
0.816 configure: error: --with-grass=/usr/local/grass83 requested, but libraries not found!
There was a problem hiding this comment.
You are right 😇
How long does it take to compile?
The multistage approach tries to have the best of everything - fast build times and most recent code. If it takes too long, we might need to come up with a different solution.
There was a problem hiding this comment.
This bit
RUN mkdir -p /usr/lib/gdalplugins
RUN git clone https://github.com/OSGeo/gdal-grass.git
RUN cd gdal-grass && ./configure --with-gdal=/usr/bin/gdal-config --with-grass=/usr/local/grass83 \
&& make && make install
RUN cd .. && rm -rf gdal-grass
takes ~ 10 seconds in the docker build command. What really takes time is the installation of GRASS addons (https://github.com/actinia-org/actinia-docker/blob/main/actinia-alpine/Dockerfile#L57) with 5-10 minutes in my local tests. All other lines only take a few seconds max
actinia-alpine/Dockerfile
Outdated
| # commenting out snappy configuration: | ||
| # RUN (cd /root/.snap/snap-python/snappy && pip3 install .) | ||
| # RUN /usr/bin/python3 -c 'from snappy import ProductIO' | ||
| # RUN /usr/bin/python3 /root/.snap/about.py | ||
| # using gpt (graph processing tool) instead: |
There was a problem hiding this comment.
If we can do everything with gpt instead of snappy, no need to keep these comments here.
|
The referenced Alpine Dependencies image has been pushed to Dockerhub, the latest version has been successfully tested locally. |
In order to run i.sentinel.1pyrosargeocode as an alternative to snappy S-1 preprocessing, snappy has to be removed from the installation, but SNAP still needs to be installed with
gptenabled (see mundialis/esa-snap#37)