Hi David, be careful that the former PROJ_LIB environment variable was
changed to PROJ_DATA since the PROJ 9.1.0 release (the former may work
for you now, but, you should change your packaging process to the
correct name, depending on what PROJ version you have).
Also, you can follow the PROJ_DATA releases at
https://github.com/OSGeo/PROJ-data/releases
Thanks,
-jeff
--
Jeff McKenna
GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
co-founder of FOSS4G
http://gatewaygeo.com/
On 2025-10-07 12:00 p.m., David Klaus via gdal-dev wrote:
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
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
