PROJ/src/iso19111, branch 6.2

normalizeForVisualization() and other methods applying on a ProjectedCRS: do not mess the derivingConversion object of the original object (fixes #1736)

2019-11-25T12:14:35+00:00

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)

Doc: document oddity related to identification of CRS from ESRI WKT

2019-11-09T12:22:48+00:00

Or more generally formulations that don't have an explicit axis order.
Refs https://github.com/pyproj4/pyproj/issues/475

projinfo 'GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]'
returns EPSG:4326 with 100% confidence.
But its axis order is not the same as EPSG:4326.

I've pondered about this, like decreasing the confidence of the match,
but this would have downstream effects on GDAL (shapefiles with the
above content in a .prj would no longer be identified as EPSG:4326).
So for now, document that oddity.

createOperations(): in some circumstances we wrongly promoted a Helmert geog2D transformation to a geog3D

2019-11-03T14:33:55+00:00

Fixes for example EPSG:4979 to EPSG:2189, as raised in
https://github.com/OSGeo/gdal/issues/1972#issuecomment-548814354

createFromWkt(): be tolerant to missing scale_factor parameter (fixes #1700)

2019-10-30T16:49:39+00:00

This is invalid WKT, but GDAL 2.4 used to accept it and make a reasonable
use of it...

Currently we default it to 0 which is non sensical. Better use 1 as GDAL 2.4
did, and emit a warning.

Other fix: proj_create_from_wkt() was documented to operate by default in
non-strict validation mode, but it was actually in strict mode. So do as
documented.

importFromWkt(): fix axis orientation for non-standard ESRI WKT (fixes #1690)

2019-10-25T09:04:16+00:00

createOperations(): fix double vertical unit conversion from CompoundCRS to other CRS when the horizontal part of the projected CRS uses non-metre unit

2019-10-18T19:55:22+00:00

Fix issue reported on https://lists.osgeo.org/pipermail/proj/2019-October/008939.html

createOperations(): allow transforming from a compoundCRS of a bound verticalCRS to a 2D CRS

2019-10-12T09:09:48+00:00

PROJ string CRS ingester: recognize more unit-less parameters, and general handling of +key=string_value parameters

2019-09-28T10:48:17+00:00

Merge pull request #1636 from OSGeo/backport-1633-to-6.2

2019-09-28T08:19:50+00:00

Backport #1633 to 6.2

createOperations() sorting: sort operations that cannot be exported as PROJ pipelines at end

2019-09-27T23:48:18+00:00