Le 10/11/2024 à 16:21, Javier Jimenez Shaw via gdal-dev a écrit :
Just FYI
I just rebased my master from upstream, and there are failing tests in
conda
https://github.com/jjimenezshaw/gdal/actions/runs/11765891451/job/32772764349
yes, this is the same issue as what is blocking the conda-forge
Just FYI
I just rebased my master from upstream, and there are failing tests in conda
https://github.com/jjimenezshaw/gdal/actions/runs/11765891451/job/32772764349
Cheers,
Javier.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.or
Actually, you might have meant 3.0.3 and 3.5.3. When using 3.0.3, LVBAG
files are read through the generic GML driver. When using 3.5.3, they
are read with the new LVBAG driver
(https://gdal.org/en/latest/drivers/vector/lvbag.html). When reviewing
it, I saw that it ran a IsValid() check, even i
Jan,
What are those 3.03 and 3.53 versions ? They don't match GDAL official
version numbers. I thought you meant 3.0.3 and 3.5.3, but the LVBAG
driver is new to 3.2.0, so that can't be it. Xerces is *not* a required
DLL for that driver. It uses Expat. Do you use the
AUTOCORRECT_INVALID_DATA=
My c++ utility-app collects Kadaster BAG data in postgresql tables for use
in "populatie service".
It has functioned for several years, with a typical runtime of 40 minutes.
In the process of rounding this off, I updated the gdal binaries from 3.03
to 3.53, as well as added some threaded workloads