diff options
| author | Even Rouault <even.rouault@spatialys.com> | 2019-11-25 04:54:17 +0100 |
|---|---|---|
| committer | Even Rouault <even.rouault@spatialys.com> | 2019-11-25 13:14:35 +0100 |
| commit | bce4b158ab5f7d146de8e8fc98df4612dc8c2c9e (patch) | |
| tree | d0158eb03d39b9d2249a30ea88f333c8e560f351 /docs/source/development/reference/cpp | |
| parent | 6b067b1190d7abab3c493275017a6389b53970f5 (diff) | |
| download | PROJ-bce4b158ab5f7d146de8e8fc98df4612dc8c2c9e.tar.gz PROJ-bce4b158ab5f7d146de8e8fc98df4612dc8c2c9e.zip | |
normalizeForVisualization() and other methods applying on a ProjectedCRS: 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
https://github.com/qgis/QGIS/issues/30569#issuecomment-540060919
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)
Diffstat (limited to 'docs/source/development/reference/cpp')
0 files changed, 0 insertions, 0 deletions