[gdal-dev] Discoverability of the new proj.db and GDAL_DATA/PROJ_LIB?

[Even Rouault]

> > I've just submitted a PR https://github.com/OSGeo/proj.4/pull/1218 to add
> > a
> > 
> > proj_context_set_search_paths(
> > 
> >  PJ_CONTEXT *ctx, int count_paths,const char* const* paths)
> > 
> > If called on the default PROJ context (NULL) before GDAL creates it own
> > contexts, this should allow you to specify your own search path.
> 
> Or I could call pj_set_searchpath?

It is part of the proj_api.h that will be deprecated in PROJ 6 and eventually 
removed in PROJ 7. Its effect in PROJ 6 will be identifcal to using 
proj_context_set_search_paths() with the default PROJ context.

> 
> I'm a little concerned about the need to race GDAL to the default context.
> I'm not sure how I'll be able to do this in practice. Even if Rasterio were
> to call pj_set_searchpath immediately on import, which I'd like to avoid
> for a number of reasons, any user who imported a different module that
> loads GDAL (osgeo.gdal, for example) before importing Rasterio would lose
> that insurance and may experience some trouble that is hard to diagnose.

> Could a GDAL API function that allowed modification of the search path in
> GDAL's own context help?

ok, I'll probably add a

void CPL_DLL OSRSetPROJSearchPaths( const char* const* papszPaths );

that will internally call proj_context_set_search_paths() on PROJ context 
managed by GDAL (affecting the already created TLS ones, and future ones)

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