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

[Sean Gillies]

On Wed, Jan 9, 2019 at 11:12 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> > PROJ 6 new API has a proj_context_set_database_path() function but I've
> not
> > used/exposed through GDAL for now. It is something per-context (and thus
> > potentially per thread since in my new GDAL branch PROJ contexts are per-
> > thread variables, which are not exposed in GDAL API), and only for
> proj.db
> > itself, not other PROJ resources (such as grid files) normally accessible
> > through PROJ_LIB / ${prefix}/share/proj
> >
> > There's also a related ticket in PROJ tracker:
> > https://github.com/OSGeo/proj.4/issues/1150
> > We'd probably need to expose pj_set_searchpath() in the public PROJ API.
>
> 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?

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?

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190109/ff22e337/attachment-0001.html>