<html><head><style type="text/css">.style1 {font-family: "Times New Roman";}</style></head><body><div dir="ltr">All,<div><br></div><div>I just wanted to give a quick update. I have switched to using PROJ_DATA. Though I did not expect this to fix my original issue, I can confirm that it has not. Is there perhaps a cache that I need to clear or something like that? Or, is there some component of GDAL/Proj that I need to reset?</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Oct 7, 2025 at 1:10 PM David Klaus <<a href="mailto:dklaus@carlsonsw.com">dklaus@carlsonsw.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Jeff,<div><br></div><div>Thank you for that information. I wasn't aware that had changed. I will update our code,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 7, 2025 at 1:07 PM Jeff McKenna via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi David, be careful that the former PROJ_LIB environment variable was <br>
changed to PROJ_DATA since the PROJ 9.1.0 release (the former may work <br>
for you now, but, you should change your packaging process to the <br>
correct name, depending on what PROJ version you have).<br>
<br>
Also, you can follow the PROJ_DATA releases at <br>
<a href="https://github.com/OSGeo/PROJ-data/releases" rel="noreferrer" target="_blank">https://github.com/OSGeo/PROJ-data/releases</a><br>
<br>
Thanks,<br>
<br>
-jeff<br>
<br>
<br>
<br>
<br>
-- <br>
Jeff McKenna<br>
GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev<br>
co-founder of FOSS4G<br>
<a href="http://gatewaygeo.com" rel="noreferrer" target="_blank">http://gatewaygeo.com</a><br>
<br>
<br>
<br>
<br>
On 2025-10-07 12:00 p.m., David Klaus via gdal-dev wrote:<br>
> Hello GDAL community,<br>
> <br>
> The product that I work on uses the CPP GDAL library for a number of <br>
> routines. Occasionally, this requires supplementary files -- Currently, <br>
> we supply proj-data 1.20 <<a href="https://github.com/OSGeo/PROJ-data/releases/" rel="noreferrer" target="_blank">https://github.com/OSGeo/PROJ-data/releases/</a> <br>
> tag/1.20.0> -- which we download when we detect that the dataset is <br>
> needed. Here's the problem, often GDALRegisterAll() is called before the <br>
> proj-data 1.20 files are downloaded. From my testing, it appears that if <br>
> the proj-data 1.20 files are not available when GDALRegisterAll() is <br>
> called, GDAL will not use them regardless of whether or not these files <br>
> are available later.<br>
> <br>
> Now, what I think might be a good solution is appropriately updating <br>
> GDAL's state after proj-data is downloaded s.t. it is able to detect the <br>
> proj-data files. But, I'm not sure how to do this. Calling the following <br>
> seems to produce correct results:<br>
> <br>
> GDALDestroy()<br>
> GDALAllRegister()<br>
> <br>
> However, the documentation says the following:<br>
> <br>
> ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////FROM DOCUMENTATION///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////<br>
> Finalize GDAL/OGR library.<br>
> <br>
> This function calls GDALDestroyDriverManager() and OGRCleanupAll() and <br>
> finalize Thread Local Storage variables.<br>
> <br>
> Prior to GDAL 2.4.0, this function should normally be explicitly called <br>
> by application code if GDAL is dynamically linked (but that does not <br>
> hurt), since it was automatically called through the unregistration <br>
> mechanisms of dynamic library loading.<br>
> <br>
> Since GDAL 2.4.0, this function may be called by application code, since <br>
> it is no longer called automatically, on non-MSVC builds, due to <br>
> ordering problems with respect to automatic destruction of global C++ <br>
> objects.<br>
> <br>
> *Note: no GDAL/OGR code should be called after this call!*<br>
> ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////FROM DOCUMENTATION///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////<br>
> <br>
> So, this doesn't seem like the correct way to address this problem. How <br>
> should I go about updating GDAL's state s.t. it will detect and read the <br>
> downloaded supplementary proj-data files? Or, is there something more I <br>
> should be doing before GDALAllRegister() is called?<br>
> <br>
> GDAL Version: GDAL 3.10.3, released 2025/04/01<br>
> Proj Version: 9.6.0<br>
> <br>
> P.S. To get out in front of what I expect to be the first question, yes <br>
> I am setting the PROJ_LIB environmental variable at runtime to the <br>
> correct folder. Further, I have tried creating an empty proj-data folder <br>
> available to GDAL when GDALRegisterAll() is called. This did not change <br>
> GDAL's behavior. Here is the code I use for setting PROJ_LIB:<br>
> <br>
> SetEnvironmentVariable("PROJ_LIB", "c:/path/to/proj-data/folder");<br>
> _putenv_s("PROJ_LIB", "c:/path/to/proj-data/folder"); // (See: GETENV_NOTE)<br>
> <br>
> P.P.S Here is the GETENV_NOTE:<br>
> // GETENV_NOTE:<br>
> // _putenv_s() is used to ensure compatibility with getenv(). getenv() <br>
> operates on environment variables loaded into the _environ global <br>
> variable (loaded at "process startup.")<br>
> // SetEnvironmentVariable() affects the environment variables set for <br>
> this process but does not change _environ. _putenv_s() updates _environ <br>
> and ensures compatibility w/<br>
> // genenv().<br>
> <br>
> P.P.P.S I do know that there is a more current proj-data dataset <br>
> available. We may update to this dataset in the future. But unless that <br>
> will fix the current issue, I'd rather not do that now.<br>
> <br>
> <br>
> -- <br>
> David Klaus<br>
> Carlson Software<br>
> <br>
> <br>
> *Disclaimer*<br>
> <br>
> The information contained in this communication from the sender is <br>
> confidential. It is intended solely for use by the recipient and others <br>
> authorized to receive it. If you are not the recipient, you are hereby <br>
> notified that any disclosure, copying, distribution or taking action in <br>
> relation of the contents of this information is strictly prohibited and <br>
> may be unlawful.<br>
> <br>
> <br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">David Klaus<div>Carlson Software</div></div></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">David Klaus<div>Carlson Software</div></div></div>
<br><br><p style="font-family: Verdana; font-size:10pt; color:#777777;"><b>Disclaimer</b></p><p style="font-family: Verdana; font-size:8pt; color:#777777;">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.</p></body></html>