Closed visr closed 1 year ago
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.)
Oh to answer the question: no issues with you merging and tagging the PR in GDAL.jl.
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: https://github.com/JuliaGeo/GDAL.jl/commit/736192b1751f6264c8ae27482b42517856cecf08
The getfield
related failures, I don't know why they are failing on the new GDAL.
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.
The getfield related failures, I don't know why they are failing on the new GDAL.
That would be the bugfix:
See https://github.com/JuliaGeo/GDAL.jl/pull/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.