Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
normalizeForVisualization() and other methods applying on a ProjectedCRS: do not mess the derivingConversion object of the original object (fixes #1736) #1746
normalizeForVisualization(), promoteTo3D(), demoteTo2D(), alterGeodeticCRS(),
So bottom line is use derivingConversion() for anything that is not pure
This is confirmed to be the fix for the QGIS scenario in
In QGIS use case, the issue arised when using a projected CRS with a non-GIS
…CRS: do not mess the derivingConversion object of the original object (fixes #1736) normalizeForVisualization(), promoteTo3D(), demoteTo2D(), alterGeodeticCRS(), alterCSLinearUnit() and alterParametersLinearUnit() all used the object returned by derivingConversionRef() to create a new ProjectedCRS. While doing so, this caused the derivingConversion of the original object to have its targetCRS set to the object returned by normalizeForVisualization() and similar. If that object died, then the weak pointer would be reset, and the original ProjectedCRS() has now its derivingConversionRef()->targetCRS() nullptr So bottom line is use derivingConversion() for anything that is not pure reading !!! This is confirmed to be the fix for the QGIS scenario in qgis/QGIS#30569 (comment) In QGIS use case, the issue arised when using a projected CRS with a non-GIS friendly axis (that is where normalizeForVisualization() created a new projectedCRS)
@kbevers Jürgen Fischer announced on https://lists.osgeo.org/pipermail/qgis-developer/2019-November/059411.html that he had cherry-picked the fix to generate a 6.2.1 patched OSGeo4W package. So I guess we can probably just follow the original plan of a 6.3.0 release beginning of January. Speaking about that, PROJ master uses 7.0.0 numbering currently. Should it be changed to 6.3.0 or will you do so when you create the 6.3 branch from master ?
@nyalldawson @rouault @gioman So you all have made quite a bit of progress, I have reproduced some failures quite unintentionally since I hadn't followed the progress on this thread till now. I use Windows 10 64x. It started with adding multiple layers simultaneously...
Using ESRI 104019 (ITRF2014) (World - not Australia) GCRS as a Project Canvas CRS because I need to use projected data that will not work accurately with psuedo mercators (all tiled web maps Bing Google etc), and 3.10 is crashing with a projected canvas, i.e. with the Bing/Google Base map projected to match my data.
Adding GCRS layer worked fine on close and reopen.
Reopening I chose the same GCRS 104019 world. QGIS crashed. Here is the error log.
AND THE FOLLOWING HAPPENED BEFORE THE PROJECT REFERENCED ABOVE CRASHED QGIS. I DON'T KNOW IF ITS A SEPARATE OR RELATED ISSUE. TRYING TO RELOAD A SAVED LAYOUT 3.11 CANT FIND THEM, WHEN I MANUALLY INPUT THE LOCATION IT LOADS QGIS 3.46 (THE VERSION THE LAYOUT WAS MADE IN) THE LESSON IS DON'T TRY TO TRANSPORT ANY PART OF AN OLD PROJECT TO 3.1?
THE SPECIFIED FOLDER NOW SHOWS UP IN THE DEFAULT LAYOUT MGR. A CLOSE AND REOPEN AFTER THIS ISSUE WORKED (CHOOSING THE ESRI104019 (ITRF2014) BUT CRASHED ON THE MULTIPLE LAYERS ISSUE.
An error has occurred while executing Python code:
RuntimeError: wrapped C/C++ object of type ContourGeneratorAlgorithm has been deleted
Python version: 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)]
CAN I IMPLEMENT ANY OF YOUR FIXES; WOULD IT HELP? OR SHOULD I JUST DO WORK AROUNDS?
@happydeb just wait till 3.10.1 is released at the end of the week -- it will include this fix.
This is a bug in the "contour" plugin, you'll need to report this one with the authors of that plugin.