On samedi 23 novembre 2019 12:23:12 CET Paolo Cavallini wrote: > Hi Tim, > > Il 23/11/19 11:22, Tim Sutton ha scritto: > > For windows at least we could ‘freeze’ 3.4.x by pointing them to use the > > standalone installers but then we have an LTR that is not getting bug > > fixes. As I read Jürgen’s roadmap [1] we still have 4 more bug fix > > releases of 3.4 before 3.10 becomes LTR, which is quite a long time to > > have our ’stable’ version out there with no bug fixes. > > yes, that's what I meant. It's a kind of bad hack, so as Bas also > pointed out the proper solution is just to go ahead and fix the bugs. > I feel bad about people wasting their time to fix this compatibility bug > that will be useful just for a relatively short period, however.
I'm pretty sure there will be problems with CRS handling with QGIS 3.4 + GDAL3/PROJ6 that will *not* be fixable, due to intended changes of behaviour in GDAL3/PROJ6, particularly the export of CRS definition to PROJ strings, that QGIS 3.4 still uses it, that is deprecated now and works only in a degraded mode regarding export datum information (retrospectively, I should probably have completely remove exportToProj4() to make that obvious). QGIS 3.4 to work properly with GDAL3/PROJ6 would require backporting all the PROJ6 specific work started with 3.8, which is another big no no. For example just seing that srs.db in 3.4.13 package has for OSGB36: parameters (String) = +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +units=m +no_defs where GDAL 2 based versions have an extra +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 which is essential to make things work properly in a PROJ4 string oriented workflow as used by 3.4. I'v just tried with a GPKG in WGS84 with a single point in England, and a conversion of it to OSGB36 (with ogr2ogr of GDAL 3 or GDAL 2): when loaded in 3.4.13 based on GDAL 3, the points are distant of 130 m (which is the missing datum shift). Whereas when loaded with 3.4.13 based on GDAL 2 (or 3.10 with GDAL 3), they overlay properly. So people dealing with datums != WGS84 should better stick with 3.4.12 on Windows currently, if wanting to stay in the 3.4 series. QGIS 3.4 combined with GDAL3/PROJ6 is a *design* bug, not a regular bug that can be fixed. I don't see why QGIS 3.4 on OSGeo4W using a GDAL 2.4.3 + PROJ 5.2 wouldn't be technically achievable. Isn't there a gdal and gdal-dev package in it, several QGIS variants already ? So why not a gdal2_4 ? Well, I guess that doing that now would require creating a grass package that depends on gdal2_4 etc. So yes, that might be painful to do at that stage. Dunno... But for the future, I can imagine we could have: qgis3_10 depending on gdal3 (or possibly even gdal3_0 ?) and proj6 and qt_whatever_we_use_currently And qgis3_12 could decide to upgrade one of its dependencies without impacting qgis3_10. Whatever a hot fix, or a long term solution (pun intended :-)) along the above lines or better is chosen, it would seem to me as a very appropriate use of funds of the project to investigate what is possible. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
