GDAL 3.6.0

[visr]

See JuliaGeo/GDAL.jl#143.
I saw locally that 9 ArchGDAL tests were failing using that branch, but from a quick glance nothing serious. Though let us know if you want us to hold off merging and tagging that PR.

[yeesian]

I saw locally that 9 ArchGDAL tests were failing using that branch, but from a quick glance nothing serious. Though let us know if you want us to hold off merging and tagging that PR.

Should we upperbound the dependency on GDAL here? In the NEWS, it's written that

Breaking changes: Remove use of compatibility wrappers _GetProjectionRef / _GetGCPProjection / _SetProjection / _SetGCPs (#6186)

So I think this package will need to be updated to remain compatible with GDAL 3.6+.

(Update: oh, those are for "out-of-tree vector drivers", so I don't have a good understanding whether that applies to the usage in this package.)

[yeesian]

Oh to answer the question: no issues with you merging and tagging the PR in GDAL.jl.

[visr]

Some more info looking at CI results using GDAL.jl 1.5:

https://github.com/yeesian/ArchGDAL.jl/actions/runs/3570501592/jobs/6001534020

The geotransform and nearblack failures are due to changes in GDAL, I also had to update GDAL.jl tests for that: JuliaGeo/GDAL.jl@736192b

The getfield related failures, I don't know why they are failing on the new GDAL.

[evetion]

Should we upperbound the dependency on GDAL here? In the NEWS, it's written that

I think we must. We've seen multiple times that upstream releases (not only GDAL, also PROJ for example) introduces changes that break tests or actual production code. You can't prevent that with pinning ArchGDAL.

[evetion]

The getfield related failures, I don't know why they are failing on the new GDAL.

That would be the bugfix:

• OGRFeature::FillUnsetWithDefault(): do not set driver-specific default values on unset numeric fields