[gdal-dev] Confusing error behavior of OGR_L_GetSpatialRef

[Even Rouault]

Hi Sean,

(re adding the list)

> > This is driver specific behaviour. How can we reproduce ?
> 
> I see it with this shapefile:
> 
> https://github.com/Toblerity/Fiona/tree/master/tests/data/coutwildrnp.shp
> 
> The .prj file contains
> 
> GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257
> 223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]
> 
> Strictly speaking, it's not OGR_L_GetSpatialRef() that puts the error on
> the stack, but importFromEPSGAInternal() in ogr_fromepsg.cpp.

OK, yes, that's when the driver tries to identify the ESRI WKT with a CRS in 
the EPSG database.

> 
> > Is the SRS returned still meaningful or somewhat dummy ?
> 
> I'm not sure.

Yes, it is meaningful in that case even in the absence of GDAL_DATA

> 
> If I try to reproject the shapefile without any GDAL_DATA, ogr2ogr writes
> an empty file.
> 
> $ GDAL_DATA=/foo/bar ogr2ogr -f GeoJSON -t_srs epsg:26913 /tmp/foo.json
> tests/data/coutwildrnp.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:26913

Yes, that's expected, you need a valid GDAL_DATA to resolve EPSG:26913 from 
the .csv files.

> 
> Though reprojection does seem to work if I pass -t_srs "+init=epsg:26913"
> instead, which is confusing.

Yes, because this syntax goes to PROJ, and read its 'epsg' file instead. 
Hopefully after my current work, both syntax will end up resolving into the 
new proj.db database

> 
> Well, yes, but in my experience unset GDAL_DATA is one of the first gotchas
> for new users who are installing GDAL in new ways (using Anaconda, for
> example). I'm including the GDAL and PROJ support files in my Fiona and
> Rasterio wheels and have it *mostly* foolproof, but not quite.

Is this is an issue with Windows build ? Unix builds should normally not need 
GDAL_DATA and PROJ_LIB and use instead the installation prefix.

> > Anyway soon that will be PROJ_LIB that you will have to define correctly
> > ;-)
> 
> I'm looking forward to having a configuration option for PROJ_LIB. I don't
> like the way I'm patching os.environ in Fiona and Rasterio now.

PROJ doesn't have the equivalent of configuration options, but we could indeed 
have a PROJ C function to set this path.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com