pyproj "crs not found" (GDAL/Docker) - Python

Question

I am attempting to run a Docker container which contains several Python scripts to be executed in sequence, including one that converts UTM coordinates to their latitude/longitude equivalent. The script works when run as a standalone script (eg in the Spyder environment), but I am getting errors when execute the same script inside my docker container. Here is the segment of the script that retrieves the projections for EPSG 3857 and EPSG 4326:

import glob
from osgeo import gdal, osr, ogr
from pyproj import Proj, transform

for file in glob.glob("*.tif"):
    dem = gdal.Open(file)
    epsg_zone='EPSG:'+ osr.SpatialReference(dem.GetProjection()).GetAttrValue("PROJCS|AUTHORITY", 1))
    P3857 = Proj(init=epsg_zone)
    P4326 = Proj(init='epsg:4326')

My docker container was built by installing GDAL v3.0.2 and pyproj v.3.0.0.post1 among other libraries. However, when this specific script is launched I am encountering an error when the processing gets to the line segment that reads "P3857 = Proj(init=epsg_zone)":

File "pyproj/_crs.pyx", line 2302, in pyproj._crs._CRS.__init__
pyproj.exceptions.CRSError: Invalid projection: +init=epsg:None +type=crs: (Internal Proj 
Error: proj_create: crs not found)

I further identified another issue regarding how the GeoTIFF is being read. When I run a print statement for "dem.GetProjection()" for running the script in my docker container, it returns an empty string while it returns the full projection and coordinate reference system information when run as a standalone tool. It specifically reads the dem object (print(dem)) as follows:

osgeo.gdal.Dataset; proxy of <Swig Object of type 'GDALDatasetShadow *' at 0x7f5e48651120>

I am confused as to why the script runs fine as a standalone from the Spyder environment, but I get these errors from within the Docker container. Any assistance is most appreciated!

Answer 1

GDAL relies on a directory full of data files to do its job. It is likely that either this data directory was not copied into the container, or the GDAL search path inside the container does not match the installation location.

The GDAL library will use the environment variable GDAL_DATA to find the data directory. First, find the data (one possible file to search for is epsg.wkt ) in the container. Copy it in if it's not present. Then set GDAL_DATA somewhere in the environment before launching your software