gdalwarp vsicurl not working in current docker image #101
Comments
|
Based on the PROJ6.3.0 FAQ, this is a common issue. Updated the Dockerfile to use the latest build of jupyter/minimal-notebook. same failure in using Trying to reduce this to the minimal code to test but getting surprising results. rasterio test succeeds, this has been known to fail (rasterio/rasterio#1850) using |
|
It looks like the issue is that the environmental variable |
|
I have tried a few things with no luck so far. This works when I run the docker image in interactive mode using the bash shell, but not when I run the docker image as a notebook: This actually activates the conda environment in the notebooks, and the necessary environmental variable is set, but the code fails with: asking for help on the jupyter discourse site: post |
|
The current access issue seems to be specific to notebooks. Running the below code works when running the docker image in bash: Running above code gets this failure message when run as a bash command in the notebook: |
|
Trying to fix permissions the way they are fixed in the jupyter notebook stacks isn't helping. Tried: Running in notebook I get the same access issues as above. |
|
ok, I don't know if this is related to my permissions issue, but I just figured out that creating and activating a new environment using |
|
So, just to document before we go in another direction (using the base environment), I don't think the error |
|
Trying to install Installs gdal version 3.0.2 (same version installed when I install using an environment and it all works) when I run the container in bash and try For some reason, removing the So now that gdal is installed properly in the base environment, I get the following when running from shell: So, it knows where proj.db is (it is in that folder), but it can't access it Someone else has had this issue and just set the PROJ_LIB and GDAL_DATA environmental variables - conda/conda#9152 |
|
Following advice from conda-forge/geopandas-feedstock#63 (comment), I set |
|
ok, just to benchmark, we can get gdal and proj working again using this Dockerfile: Is this good enough? Should we just add the environmental variable and get on with our lives? At this point I am inclined to say yes. But I will try one more thing: recreating the notebook kernel with the environment activated. Following https://github.com/jupyter/docker-stacks/blob/master/docs/using/recipes.md#add-a-python-3x-environment. But overwriting the original kernel. Why? Because I have come so far and I have this working in the shell, I just need jupyter to play along. |
|
Okay, it appears that trying to overwrite the original kernel doesn't work. I have tried activating the base environment before installing gdal (and therefore proj) and installing a new kernel that activates the base environment, but the Dockerfile: |
|
After 2 days of working through gdal errors in my Dockerfile, I found your post! Thank you for documenting this! |
In the crop-temporal notebook, in cell 23, gdalwarp vsicurl is called to download a portion of a geotiff. In the current docker image, this process fails with the following message:
The current installed version of gdal is 3.0.1. In the past, the version was pinned to 2.4.0.
This may be related to the switch to gdal 3. (ref and possible solutions: PDAL/PDAL#2544)
The text was updated successfully, but these errors were encountered: