[gdal-dev] gdal-utils: Testing?

2022-02-11 Thread Matt Wilkie
Hi, Is there a way to run autotests/pytest only for gdal-utils, or only those tests that involve a certain folder tree? -matt ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How to fix path for gdal .py scripts in Anaconda-Windows?

2022-02-11 Thread Matt Wilkie
Upon reflection it seems to me that both of these are work arounds for not having regular python wrapper executables created. Now that we can `pip install gdal-utils` perhaps it's better to use pip to create the wrappers. I have a little bit of experience with that and am will to tackle the nec

Re: [gdal-dev] How to fix path for gdal .py scripts in Anaconda-Windows?

2022-02-11 Thread Matt Wilkie
On 2022-01-12 2:26 p.m., Idan Miara wrote: I had the same problem, here's my solution : https://github.com/OSGeo/gdal/blob/master/swig/python/gdal-utils/osgeo_utils/auxiliary/batch_creator.py On 2022-01-12 4:40 p.m., matt.wil...@yukon.ca wrote: Also see OSGEO4W make-bat-for-py.bat

Re: [gdal-dev] GDAL, Proj and cacert

2022-02-11 Thread Jeff McKenna
On 2022-02-11 3:48 p.m., Howard Butler wrote: On Feb 11, 2022, at 1:41 PM, Jeff McKenna mailto:jmcke...@gatewaygeomatics.com>> wrote: Unfortunately this issue comes up very often, as you said, so much of our stack relies heavily on environment variables.  My hope is that in the long run, t

Re: [gdal-dev] GDAL, Proj and cacert

2022-02-11 Thread Greg Troxel
Howard Butler writes: >> On Feb 11, 2022, at 1:41 PM, Jeff McKenna >> wrote: >> >> Unfortunately this issue comes up very often, as you said, so much >> of our stack relies heavily on environment variables. My hope is >> that in the long run, the ini-style of settings can help battle this >>

Re: [gdal-dev] GDAL, Proj and cacert

2022-02-11 Thread Howard Butler
> On Feb 11, 2022, at 1:41 PM, Jeff McKenna > wrote: > > Unfortunately this issue comes up very often, as you said, so much of our > stack relies heavily on environment variables. My hope is that in the long > run, the ini-style of settings can help battle this Windows Server x64 issue > (y

Re: [gdal-dev] GDAL, Proj and cacert

2022-02-11 Thread Jeff McKenna
On 2022-02-11 3:29 p.m., Howard Butler wrote: On Feb 11, 2022, at 1:25 PM, Jeff McKenna mailto:jmcke...@gatewaygeomatics.com>> wrote: Thanks for this discussion Paul, I can also add into the chaos that Windows Server x64 has known issues with reading environment variables What does this

Re: [gdal-dev] GDAL, Proj and cacert

2022-02-11 Thread Howard Butler
> On Feb 11, 2022, at 1:25 PM, Jeff McKenna > wrote: > > Thanks for this discussion Paul, I can also add into the chaos that Windows > Server x64 has known issues with reading environment variables What does this mean, specifically? Much of GDAL's behavior is controlled with environment var

Re: [gdal-dev] GDAL, Proj and cacert

2022-02-11 Thread Jeff McKenna
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 environ

Re: [gdal-dev] cmake status update - 99% good news!

2022-02-11 Thread Kurt Schwehr
Just a note on static builds to follow-on to Even's comments: I do static builds of gdal driven by bazel. This has pros and cons: - Plugins are explicitly not allowed in the system I work in for security reasons (I also remove almost all networking) - The resulting bins are big, but VMs are very

Re: [gdal-dev] cmake status update - 99% good news!

2022-02-11 Thread dg0yt
Even, I understand the downsides and agree with everything you say. I work with the static builds because this is what is tested in vcpkg CI for macOS and Linux. For Windows, there are also dynamic builds in CI. Dynamic options for Linux and macOS exist but aren't tested, so I guess some of gda

Re: [gdal-dev] GDAL, Proj and cacert

2022-02-11 Thread Paul Harwood
Ok - thanks. On Fri, 11 Feb 2022 at 17:38, Even Rouault wrote: > > Le 11/02/2022 à 18:24, Paul Harwood a écrit : > > 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 runt

Re: [gdal-dev] GDAL, Proj and cacert

2022-02-11 Thread Even Rouault
Le 11/02/2022 à 18:24, Paul Harwood a écrit : 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/u

[gdal-dev] GDAL, Proj and cacert

2022-02-11 Thread Paul Harwood
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: error setting certificate file:

Re: [gdal-dev] cmake status update - 99% good news!

2022-02-11 Thread Even Rouault
Kai, there's a point I had in mind regarding your mention of static builds but forgot to mention. I consider GDAL static builds as inferior in term of capabilities compared to dynamic builds because: - they don't allow to have GDAL drivers built as plugins : due to the design of GDAL drivers