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

[Even Rouault]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251007/854e625e/attachment.htm>