Hi,
>> Obvious candidates for
>> standalone CMake projects would likely be for the few drivers that
>> have proprietary dependencies (ECW, JP2KAK, MrSID, Oracle, ...) and
>> aren't shipped by FOSS binary distributions.
> (I don't follow 'and'; surely no FOSS binary distribution could have an
Even Rouault writes:
some thoughts on the thoughts from a packaging viewpoint.
> - you definitely don't want to build all drivers (that can be built as
> plugins) as plugins. This works (this is actually my dev setup, to
> ensure that the core exports all the symbols needed for drivers
> b
Hi Evan,
Thank you for the prompted answer.
I'm discussing this because I testing ogr2ogr node module and it adds
(always) the /vsicurl/ prefix for any resource starting with http [1].
The point is /vsicurl/ can only be used with some http resources.
My question was (but you already answered
Jorge,
Which error for which invocation of the WFS driver do you get ? Your
below tries are already low level attempts.
e.g the below invocation works for me without any error with GDAL master
(in "ghcr.io/osgeo/gdal:alpine-small-3.7.0" Docker image too)
ogr2ogr tmp.gpkg
"WFS:https://irig-
Hi,
I'm getting errors with WFS calls to QGIS Server using /vsicurl/.
Against Geoserver I didn't notice this issue.
I can work on a solution, if the problem is on the QGIS Server side. I
would love to have a second opinion on this.
What I have found:
1) The is no Content-Length: header in
Now that the project has made it to CMake, I wonder if there is enthusiasm to
break apart GDAL's build system to take advantage of its plugin capability in a
default fashion to cut down on the massiveness of our default
stuff-you-actually-want build situation. People rightly complain that
li
> On May 28, 2023, at 5:20 PM, Sean Gillies wrote:
>
> Testing build systems is tough. I know GDAL can't test that all optional
> drivers can be configured and built in isolation. At the same time, profiles
> of drivers between the bare minimum and everything-but-the-kitchen-sink are
> usef
