Thanks for this discussion Paul, I can also add into the chaos that
Windows Server x64 has known issues with reading environment variables
(so in my case, for all MS4W x64 deployments, I have MS4W search known
locations for the bundle, as a workaround for the code that fails to
find the environment variables in the GDAL/PROJ/MapServer stack).
Recently MapServer now has a config file where you can set these
variables, to avoid that problem. I believe the GDAL/PROJ stack needs
something like this as well, to avoid the reliance on these system
environment variables (full disclosure: I need to test if proj.ini
accepts the cacert bundle as an environment variable, so my above point
could be wrong, totally). But I'm often wrong ha.
-jeff
--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
On 2022-02-11 1:24 p.m., Paul Harwood wrote:
I have an application that uses GDAL with Proj Networking set on.
This is a cross platform application. It works on some platforms but on
mac (for instance) I get runtime errors like this
GDAL failure (1) PROJ: Cannot open
https://cdn.proj.org/us_nga_egm96_15.tif
<https://cdn.proj.org/us_nga_egm96_15.tif>: error setting certificate
file: xxx/cacert.pem
Proj is looking in the wrong place for the cacert file - which is in the
proj search path. I would rather avoid using environment
variables (complicated). Is there a programmatic way to set the Proj
cacert location or a default location?
currently - the following are set
Gdal.SetConfigOption("CURL_CA_BUNDLE", Path.Combine(gdalData,
"cacert.pem"));
Osr.SetPROJSearchPath(projData);
Osr.SetPROJEnableNetwork(true);
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
