aboutsummaryrefslogtreecommitdiff
path: root/src/iso19111/c_api.cpp
diff options
context:
space:
mode:
authorEven Rouault <even.rouault@spatialys.com>2020-01-23 18:31:32 +0100
committerEven Rouault <even.rouault@spatialys.com>2020-01-23 19:11:05 +0100
commit79eed0da28abdc41c996dc55ee231f1fcffe4fd2 (patch)
tree97e5a634014d57543cd4642c4407e5847597fccc /src/iso19111/c_api.cpp
parenta217239fa55b5c7002d37a5b17fb41117dfb4b64 (diff)
downloadPROJ-79eed0da28abdc41c996dc55ee231f1fcffe4fd2.tar.gz
PROJ-79eed0da28abdc41c996dc55ee231f1fcffe4fd2.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/iso19111/c_api.cpp')
-rw-r--r--src/iso19111/c_api.cpp2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/iso19111/c_api.cpp b/src/iso19111/c_api.cpp
index 5a5e97f6..6fef5518 100644
--- a/src/iso19111/c_api.cpp
+++ b/src/iso19111/c_api.cpp
@@ -3563,7 +3563,7 @@ PJ *proj_crs_create_projected_3D_crs_from_2D(PJ_CONTEXT *ctx,
crs_name ? crs_name
: cpp_projected_2D_crs->nameStr().c_str()),
NN_NO_CHECK(cpp_geog_3D_CRS),
- cpp_projected_2D_crs->derivingConversionRef(), newCS));
+ cpp_projected_2D_crs->derivingConversion(), newCS));
} catch (const std::exception &e) {
proj_log_error(ctx, __FUNCTION__, e.what());
if (ctx->cpp_context) {