gdal_translate : projection error?

Question

I am using GDAL library routines to build a tiled hierarchy of images for use with Google Earth. The images are just PNG files created using Matplotlib. To tile the images, we are using gdal_translate, gdalwarp and gdal2tiles.py. When using the Macports installation of GDAL (installed via sudo port install gdal, everything works beautifully, and the tiled hierarchy is created and loads into Google Earth. But for reasons I don't understand, the Anaconda installation is giving us an error.

Here is the results of gdalinfo on a typical PNG file that we produce :

% gdalinfo plot.png
Driver: PNG/Portable Network Graphics
Files: plot.png
Size is 2400, 2400
Coordinate System is `'
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0, 2400.0)
Upper Right ( 2400.0,    0.0)
Lower Right ( 2400.0, 2400.0)
Center      ( 1200.0, 1200.0)
Band 1 Block=2400x1 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA 
Band 2 Block=2400x1 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA 
Band 3 Block=2400x1 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA 
Band 4 Block=2400x1 Type=Byte, ColorInterp=Alpha

The image we are loading is assumed to be in lat/lon coordinates.

When we use the Macports installation of gdal_translate, things work :

/opt/local/bin/gdal_translate -of VRT -a_srs EPSG:4326 -gcp 0 0 -120   0  -gcp     2400     0  -60   0 -gcp 2400  2400  -60 -60 -90 plot.png plot_tmp.vrt
Input file size is 2400, 2400

The file plot_tmp.vrt is created, and can be used by gdalwarp and gdal2tiles.py.

However, the same call to the Anaconda installation of gdal_translate gives us an error :

/anaconda/bin/gdal_translate -of VRT -a_srs EPSG:4326 -gcp 0 0 -120   0  -gcp 2400     0  -60   0 -gcp 2400  2400  -60 -60 -90 plot.png plot_tmp.vrt
ERROR 6: EPSG PCS/GCS code 4326 not found in EPSG support files.  Is this a valid EPSG coordinate system?
Failed to process SRS definition: EPSG:4326

I have GDAL_DATA set to an existing file gcs.cvs (although this doesn't seem to matter, as the MacPorts installation doesn't need this file).

I have exactly the same installed versions in both cases :

/anaconda/bin/gdal_translate --version
GDAL 1.11.2, released 2015/02/10

/opt/local/bin/gdal_translate --version
GDAL 1.11.2, released 2015/02/10

Is the Anaconda installation broken? Or is it making assumptions that the MacPorts version isn't? Or, maybe the Macports version is picking up something in my PATH that the Anaconda version isn't?

We would like to build these tiling capabilities into a visualization package were are developing, and don't want users to have to rely on one installation over the other (especially since we tell users to install Anaconda Python!)

(I apologize for the cross-posting this question, but I just now discovered this stack-exchange site, and don't yet know how to migrate my question).

Answer 1

As of a week or so ago, the Anaconda packaging of GDAL now includes all of the projection files. The install command for the Anaconda packaging of GDAL is

% conda install gdal

The projection files are stored under $ANACONDA/gdal/share$ so settingGDAL_DATA` to this path is all that is needed to avoid the problems I was having above.

% export GDAL_DATA=$ANACONDA/share/gdal

No more need to rely on MacPorts, Frameworks, HomeBrew, gdal.org and so on for these additional files.

Answer 2

(Note : this is a partial answer!)

I figured out that the .vrt files created by the MacPorts installation and the Anaconda installation were different. The "WKT" string for the Anaconda version contained an additional "TOWGS84[0,0,0,0,0,0,0]" string, i.e.

plot.vrt (Anaconda)

....
<SRS>GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
    AUTHORITY["EPSG","7030"]],
    TOWGS84[0,0,0,0,0,0,0],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9108"]],
    AUTHORITY["EPSG","4326"]]</SRS>

MacPorts (plot.vrt)

<SRS>GEOGCS["WGS 84",
     DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
     AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
     PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
     UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
     AUTHORITY["EPSG","4326"]]</SRS>

So I created a "pro.prj" file that contains the WKT string (the Anaconda version, with the additional TOWGS84[0,0,0,0,0,0,0]" string), and passed this to `gdal_translate'

% gdal_translate -of VRT -a_srs proj.prj -gcp 0 0 -120   0  -gcp 2400     0  -60   0 -gcp 2400  2400  -60 -60 -90 plot.png plot_tmp.vrt

and both versions seem to be happy.

Passing the same string to gdalwarp also does the trick for both installations :

% gdalwarp -of VRT -t_srs proj.prj -overwrite plot_tmp.vrt plot.vrt

But now, when I use gdal2tiles.py, I get an error (in both installations, although the tiling proceeds)

% gdal2tiles.py --s_srs="EPSG:4326" --zoom=2-6 --profile=geodetic --force-kml --resampling=near plot.vrt      
ERROR 6: EPSG PCS/GCS code 4326 not found in EPSG support files.  Is this a valid
EPSG coordinate system?
ERROR 6: EPSG PCS/GCS code 4326 not found in EPSG support files.  Is this a valid
EPSG coordinate system?
ERROR 6: No translation for an empty SRS to PROJ.4 format is known.
ERROR 6: No translation for an empty SRS to PROJ.4 format is known.
ERROR 6: EPSG PCS/GCS code 4326 not found in EPSG support files.  Is this a valid
EPSG coordinate system?
ERROR 6: No translation for an empty SRS to PROJ.4 format is known.
ERROR 6: No translation for an empty SRS to PROJ.4 format is known.
Generating Base Tiles:
0...10...20...30...40...50...60...70...80...90...100 - done.
Generating Overview Tiles:
0...10...20...30...40...50...60...70...80...90...100 - done.

In fact, this happens regardless of how I set the --s-srs flag (to "EPSG:4326" or proj.prj). With my original settings for `-a_srs=EPSG:4326' (as in the original posting) I didn't get these warnings when using the Macports version.

At one point, I tried setting a s_srs (and t_srs) to a URL (in gdal_translate and gdalwarp). This worked fine for the Anaconda version (although I still got the error with gdal2tiles.py) but not for the MacPorts version. Apparently GDAL on MacPorts is not built with libcurl, and so it can't follow URL links.

Answer 3

Problem solved! In hindsight, the problem was very simple.

The MacPorts installation would run fine (although gdal2tiles.py issued warnings) without the GDAL_DATA environment variable set. So I had come to believe that my problem was "simple" enough not to require additional data files.

However, the Anaconda version would not run without GDAL_DATA set properly. And for some reason, the data files installed with Macports do not work for Anaconda (the files names are all the same, but there are subtle differences in content).

Anaconda will work with its own data files :

export GDAL_DATA=/Library/Frameworks/GDAL.framework/Versions/Current/Resources/gdal

Note that this works for MacPorts as well.

And for the record, even though MacPorts didn't seem to need a GDAL_DATA setting for my simple problem, setting

export GDAL_DATA=/opt/local/share/gdal

suppresses all annoying warnings that gdal2tiles.py issues with Macports. Again, these data files do NOT work with Anaconda, for reasons I couldn't not even begin to understand!