<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>David,</p>
<p>does calling OSRCleanup() help ?</p>
<p>Even<br>
</p>
<div class="moz-cite-prefix">Le 07/10/2025 à 17:00, David Klaus via
gdal-dev a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAJNrnBUKswuuCCscfLZ-Xk3DKVQKpBD_ejHdV-=o71xNRxNGeg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<style type="text/css">.style1 {font-family: "Times New Roman";}</style>
<div dir="ltr">Hello GDAL community,
<div><br>
</div>
<div>The product that I work on uses the CPP GDAL library for a
number of routines. Occasionally, this requires supplementary
files -- Currently, we supply <a
href="https://github.com/OSGeo/PROJ-data/releases/tag/1.20.0"
moz-do-not-send="true">proj-data 1.20</a> -- 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.</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>GDALDestroy()</div>
<div>GDALAllRegister()</div>
<div><br>
</div>
<div>However, the documentation says the following:</div>
<div><br>
</div>
<div>///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////FROM
DOCUMENTATION///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////</div>
<div>Finalize GDAL/OGR library.<br>
<br>
This function calls GDALDestroyDriverManager() and
OGRCleanupAll() and finalize Thread Local Storage variables.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<b>Note: no GDAL/OGR code should be called after this call!</b></div>
<div>///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////FROM
DOCUMENTATION///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>GDAL Version: GDAL 3.10.3, released 2025/04/01<br>
Proj Version: 9.6.0</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>SetEnvironmentVariable("PROJ_LIB",
"c:/path/to/proj-data/folder");<br>
_putenv_s("PROJ_LIB", "c:/path/to/proj-data/folder"); // (See:
GETENV_NOTE)</div>
<div><br>
</div>
<div>P.P.S Here is the GETENV_NOTE:</div>
<div>// GETENV_NOTE:</div>
<div>// _putenv_s() is used to ensure compatibility with
getenv(). getenv() operates on environment variables loaded
into the _environ global variable (loaded at "process
startup.")<br>
// SetEnvironmentVariable() affects the environment variables
set for this process but does not change _environ. _putenv_s()
updates _environ and ensures compatibility w/<br>
// genenv().</div>
<div><br>
</div>
<div>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.</div>
<div><br clear="all">
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">David Klaus
<div>Carlson Software</div>
</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>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>