[gdal-dev] GDAL 2.5.0 beta1 available

Sebastiaan Couwenberg sebastic at xs4all.nl
Fri Apr 19 07:22:29 PDT 2019


On 4/19/19 4:08 PM, Greg Troxel wrote:
> Even Rouault <even.rouault at spatialys.com> writes:
>> GDAL 2.5.0 *requires* PROJ >= 6.0, and if using external libgeotiff, 
> 
> I would expect then that packaging systems will hold off on this,
> because I don't think we've reached the point that the collateral damage
> of upgrading proj to 6 is ok.
>
> With any luck I'm wrong and most of the proj-using packages have had a
> release that works on 6, but it seems that there are a lot of packages
> not yet able to cope.

It's not as bad as it seems. If you set the accept deprecation flag,
most packages that still use proj_api.h build successfully with PROJ 6.

See: https://lists.debian.org/debian-gis/2019/04/msg00004.html
(and the follow-ups)

The ones that still use projects.h are somewhat hopeless, they tend to
be dead upstream, so are candidates for removal.

The biggest concerns are cartopy, R sf & lwgeom, SAGA, and VTK. I've
seen no progress for the R packages, nor anything tangible for VTK
(although it can be built with its embedded copy of libproj4 3.2).

The cartopy test failures may be (partially) fixed with PROJ 6.1.0 like
the test failures with the RDNAP datumgrid, but I expect more changes
will be required to get all tests to pass.

Once the SAGA changes are available in a future release, it will likely
not be compatible with QGIS, but such is the fate of processing modules.
I stopped caring about anything other that GRASS when it comes to QGIS,
and even for GRASS I'll drop the support when it breaks.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


More information about the gdal-dev mailing list