Greg, > 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.
Packaging systems with an experimental staging area should be able to package it hopefully, and add it to the other packages supporting PROJ 6 already. > > 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. I understand your concern, but what would have be supposed to do: wait for others to upgrade to PROJ 6 as well and defer until they did :-) ? We're tracing the road away by adopting PROJ 6 too. Projects which don't follow the trend are doomed to be left aside ultimately. Sorry, supporting older PROJ versions wasn't really wishable from a GDAL maintainability point of view. What happened is a deep change. A lot of code has been """moved"""" to PROJ: instanciation of CRS from the EPSG database, WKT1 support, ESRI WKT support and PROJ string import/export. Actually, all that code has been deleted from GDAL and rewritten in a completely different way in PROJ. Supporting older PROJ versions in GDAL 2.5 would mean maintaining a lot of ancient code, that behaves in subtle different ways. Would be a mess to have the test suite working in both mode, etc. GDAL is a complicated and big enough beast like it is already. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
