[gdal-dev] Properly reinitializing PROJ_LIB search paths after supplementary file download

[Even Rouault]

Le 07/10/2025 à 23:47, David Klaus a écrit :
> Even,
>
> I will check on this in a moment. If there are OGR/Proj/GDAL entities 
> on the heap/stack -- such as OGRCoordinateTransformation -- will 
> calling OSRCleanup cause issues?
That should be fine. You should however avoid any concurrent GDAL call 
in another thread
>
> On Tue, Oct 7, 2025 at 5:43 PM Even Rouault 
> <even.rouault at spatialys.com> wrote:
>
>     David,
>
>     does calling OSRCleanup() help ?
>
>     Even
>
>     Le 07/10/2025 à 17:00, David Klaus via gdal-dev a écrit :
>>     Hello GDAL community,
>>
>>     The product that I work on uses the CPP GDAL library for a number
>>     of routines. Occasionally, this requires supplementary files --
>>     Currently, we supply proj-data 1.20
>>     <https://github.com/OSGeo/PROJ-data/releases/tag/1.20.0> -- which
>>     we download when we detect that the dataset is needed. Here's the
>>     problem, often GDALRegisterAll() is called before the proj-data
>>     1.20 files are downloaded. From my testing, it appears that if
>>     the proj-data 1.20 files are not available when GDALRegisterAll()
>>     is called, GDAL will not use them regardless of whether or not
>>     these files are available later.
>>
>>     Now, what I think might be a good solution is appropriately
>>     updating GDAL's state after proj-data is downloaded s.t. it is
>>     able to detect the proj-data files. But, I'm not sure how to do
>>     this. Calling the following seems to produce correct results:
>>
>>     GDALDestroy()
>>     GDALAllRegister()
>>
>>     However, the documentation says the following:
>>
>>     ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////FROM
>>     DOCUMENTATION///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
>>     Finalize GDAL/OGR library.
>>
>>     This function calls GDALDestroyDriverManager() and
>>     OGRCleanupAll() and finalize Thread Local Storage variables.
>>
>>     Prior to GDAL 2.4.0, this function should normally be explicitly
>>     called by application code if GDAL is dynamically linked (but
>>     that does not hurt), since it was automatically called through
>>     the unregistration mechanisms of dynamic library loading.
>>
>>     Since GDAL 2.4.0, this function may be called by application
>>     code, since it is no longer called automatically, on non-MSVC
>>     builds, due to ordering problems with respect to automatic
>>     destruction of global C++ objects.
>>
>>     *Note: no GDAL/OGR code should be called after this call!*
>>     ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////FROM
>>     DOCUMENTATION///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
>>
>>     So, this doesn't seem like the correct way to address this
>>     problem. How should I go about updating GDAL's state s.t. it will
>>     detect and read the downloaded supplementary proj-data files? Or,
>>     is there something more I should be doing before
>>     GDALAllRegister() is called?
>>
>>     GDAL Version: GDAL 3.10.3, released 2025/04/01
>>     Proj Version: 9.6.0
>>
>>     P.S. To get out in front of what I expect to be the first
>>     question, yes I am setting the PROJ_LIB environmental variable at
>>     runtime to the correct folder. Further, I have tried creating an
>>     empty proj-data folder available to GDAL when GDALRegisterAll()
>>     is called. This did not change GDAL's behavior. Here is the code
>>     I use for setting PROJ_LIB:
>>
>>     SetEnvironmentVariable("PROJ_LIB", "c:/path/to/proj-data/folder");
>>     _putenv_s("PROJ_LIB", "c:/path/to/proj-data/folder"); // (See:
>>     GETENV_NOTE)
>>
>>     P.P.S Here is the GETENV_NOTE:
>>     // GETENV_NOTE:
>>     // _putenv_s() is used to ensure compatibility with getenv().
>>     getenv() operates on environment variables loaded into  the
>>     _environ global variable (loaded at "process startup.")
>>     // SetEnvironmentVariable() affects the environment variables set
>>     for this process but does not change _environ. _putenv_s()
>>     updates _environ and ensures compatibility w/
>>     // genenv().
>>
>>     P.P.P.S I do know that there is a more current proj-data dataset
>>     available. We may update to this dataset in the future. But
>>     unless that will fix the current issue, I'd rather not do that now.
>>
>>
>>     -- 
>>     David Klaus
>>     Carlson Software
>>
>>
>>     *Disclaimer*
>>
>>     The information contained in this communication from the sender
>>     is confidential. It is intended solely for use by the recipient
>>     and others authorized to receive it. If you are not the
>>     recipient, you are hereby notified that any disclosure, copying,
>>     distribution or taking action in relation of the contents of this
>>     information is strictly prohibited and may be unlawful.
>>
>>
>>     _______________________________________________
>>     gdal-dev mailing list
>>     gdal-dev at lists.osgeo.org
>>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>     -- 
>     http://www.spatialys.com
>     My software is free, but my time generally not.
>
>
>
> -- 
> David Klaus
> Carlson Software
>
>
> *Disclaimer*
>
> The information contained in this communication from the sender is 
> confidential. It is intended solely for use by the recipient and 
> others authorized to receive it. If you are not the recipient, you are 
> hereby notified that any disclosure, copying, distribution or taking 
> action in relation of the contents of this information is strictly 
> prohibited and may be unlawful.
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251007/6a4261d5/attachment.htm>