diff options
| author | Even Rouault <even.rouault@spatialys.com> | 2020-01-23 18:31:32 +0100 |
|---|---|---|
| committer | Even Rouault <even.rouault@spatialys.com> | 2020-01-23 18:31:32 +0100 |
| commit | b6db297c5a7c78727bd27978b8022cb21bdae999 (patch) | |
| tree | 1f6b46e1f83ae437e9b4c851fd47a8f5b0adb2e6 /src/sqlite3_utils.cpp | |
| parent | db31b6dfa9c8fe37d5706d95ce81012b8db3c3b9 (diff) | |
| download | PROJ-b6db297c5a7c78727bd27978b8022cb21bdae999.tar.gz PROJ-b6db297c5a7c78727bd27978b8022cb21bdae999.zip | |
Fix wrong use of derivingConversionRef() that caused GDAL bug
Hopefully final cut at solving the same class of bug that the one
that affected QGIS in December.
This time, this hit GDAL in the situation of
https://lists.osgeo.org/pipermail/gdal-dev/2020-January/051500.html
The bug fix for that particular issue is in
PROJStringParser::createFromPROJString()
But grepping more in the code base, I could find other potential smelly
situations (might not be issues, but better be safe than sorry),
so let's fix them too.
Bottom line is:
derivingConversionRef() should *only* be used for consultation, and
never to create a new ProjectedCRS()
Diffstat (limited to 'src/sqlite3_utils.cpp')
0 files changed, 0 insertions, 0 deletions