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
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
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.