I apologize for resurrecting this thread, but we are running into the same problem, even after updating the the head of the "release/3.0" branch which contains Even's fix.
Previously, we would set PROJ_LIB as an environment variable but after upgrading to 3.x/6.x we now receive thousands of "proj.db not found" errors. After checking out the above branch, I removed the environment variable and call OSRSetPROJSearchPaths before calling GDALAllRegister at the start of my main thread but the problem remains. What's odd is that it only happens if we use a lot of threads, which makes me think there may still be a race condition somewhere in GDAL? If I change my code to be single-threaded, the problem goes away completely. And advice you could offer would be much appreciated. Thanks! On Wed, Jul 17, 2019 at 1:27 PM Dirk Vanden Boer <[email protected]> wrote: > > > Op wo 17 jul. 2019 om 17:57 schreef Even Rouault < > [email protected]> > >> > I did some more investigation, and it seems like the threading is >> > indeed not the issue. >> > The issue seems to be that the geotiff library also creates proj >> > contexts and these contexts do not have >> > the search paths that are passed to the OSRGetProjTLSContext call. >> >> Should be fixed per >> >> https://github.com/OSGeo/gdal/commit/48793b5613cf1bf789125516ba845947dc63098f >> in master >> and >> >> https://github.com/OSGeo/gdal/commit/ffb0ad0c862cf4ef5d6907d1d83cc76fcf8c305b >> in 3.0 branch >> > > Great, thanks for the quick response and fixes! > >> >> _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
