[QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]
Even Rouault
even.rouault at spatialys.com
Sat Nov 23 08:36:52 PST 2019
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
More information about the QGIS-Developer
mailing list