[QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Even Rouault]

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