1

I am building GDAL 3.0.4 on Windows. GDAL 3.0.4 depends on PROJ. I have chosen PROJ 7.0.0, which depends on Curl, Libtiff, and Sqlite.

I have successfully built all of the dependencies as shared libraries from source. The final output is a GDAL devinstall Release build, which I install to ...\gdal_304_devinstall.

enter image description here

I am able to call GDAL executables in gdal_304_devinstall\bin (ogrinfo.exe, gdalinfo.exe, etc.), and I am also able to call the C++ API using files in gdal_304_devinstall\lib and gdal_304_devinstall\include.

As a test of functionality, I am doing a transformation of a shapefile from EPSG 4326 to EPSG 3857. This task succeeds when I do it through the C++ API. However, it fails when I try to use the command line:

D:\shapefiles>PATH=%PATH%;C:\Users\[USER]\bin\gdal\gdal_304_devinstall\bin
D:\shapefiles>set GDAL_DATA=C:\Users\[USER]\bin\gdal\gdal_304_devinstall\data
D:\shapefiles>set PROJ_LIB=C:\Users\[USER]\bin\proj\proj-7.0.0\inst\share\proj # (contains proj.db)
D:\shapefiles>ogr2ogr -s_srs EPSG:4326 -t_srs EPSG:3857 foobar.shp input.shp
ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
ERROR 1: Failed to process SRS definition: EPSG:3857

I am pretty confused by this. First, I did not expect GDAL to look for a .csv. I thought these were deprecated when GDAL took PROJ as a build dependency. https://github.com/OSGeo/gdal/blob/v3.0.4/gdal/NEWS, "Implement RFC 73".

Second, I am not sure how the transformation succeeds when using the C++ API but not when using the command line. I have informed my C++ program about the location of proj_7_0.dll, but not about the location of proj.db, so I am not sure how it knows how to do the transform. Does it have something to do with the INCLUDE_OGR_FRMTS flag in makefile.vc? I have built GDAL with that both on and off, doesn't seem to fix command line.

Third, and this is odd, if I point GDAL_DATA to the data dir for a much older version of GDAL (2.0.4, which I downloaded precompiled), the command line works! I assume this is some kind of backwards compatibility kicking in.

Finally, as a last resort, I redid the build process using PROJ 6.3.1, but got exactly the same behavior.

Any clues? I don't have a good sense for how the EPSG transform data should be propagated in a modern GDAL build.

Improve this question
3
  • Seems like ogr2ogr from the command line is the older version of the program? What does ogr2ogr --version return?
    – Gabriel De Luca
    Commented Mar 26, 2020 at 4:09
  • Welp. ogr2ogr --version gives 2.2.4. That was hiding in a pgsql installation I did last September. Wish I could say I hadn't lost a whole afternoon tinkering at this, but here I am, haha. Thanks much for the assist.
    – cro
    Commented Mar 26, 2020 at 5:14
  • 1
    You are welcome. A look from outside was necessary. Do not forget to accept your answer.
    – Gabriel De Luca
    Commented Mar 26, 2020 at 6:10

1 Answer 1

Reset to default
3

Gabriel De Luca had the solution. I had an older version of ogr2ogr existing on my path. After removing that, the following works:

D:\shapefiles>PATH=%PATH%;C:\Users\[USER]\bin\gdal\gdal_304_devinstall\bin
D:\shapefiles>PATH=%PATH%;C:\Users\[USER]\bin\proj\proj-7.0.0\inst\bin;C:\Users\[USER]\bin\libtiff\tiff-4.1.0\install\bin;C:\Users\[USER]\bin\curl\curl\install\bin
D:\shapefiles>ogr2ogr -s_srs EPSG:4326 -t_srs EPSG:3857 foo.shp input.shp
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.