PROJ/include/proj, branch 6.3.1

Database: update to EPSG v9.8.6

2020-01-23T18:05:48+00:00

Fixes #1867

identify(): take into datum name aliases (fixes #1800)

2019-12-16T16:50:39+00:00

createOperations(): fix an exception in transformations between Projected3D CRS and Projected CRS

2019-11-26T22:17:07+00:00

Merge pull request #1737 from rouault/proj_create_derived_geographic_crs

2019-11-25T19:00:19+00:00

Add proj_create_derived_geographic_crs() and proj_create_conversion_pole_rotation_grib_convention() to address GRIB datasets using a pole rotation method

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

2019-11-25T04:19:59+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)

Add proj_create_derived_geographic_crs() and proj_create_conversion_pole_rotation_grib_convention() to address GRIB datasets using a pole rotation method

2019-11-22T01:40:38+00:00

createOperations(): in some situations, consider when going from A to D intermediates B and C, such there's a A->B operation and C->D operation, and A and C are not exactly the same CRS but use the same geodetic datum

2019-11-19T02:01:03+00:00

createGeodeticDatum(): query and set publicationDate

2019-11-18T22:47:17+00:00

createOperations(): remove the concept of geodetic_datum_preferred_hub

2019-11-17T19:13:28+00:00

This was introduced in 63857c92b271bbcd10df0a032304982011acb2a9. Due to
the fix done in the previous commit, we can mostly revert the above commit.
We just keep the added tests and the custom WGS 84<-->WGS 84 (Gxxxx) null
transformations.

findsOpsInRegistryWithIntermediate(): tune it to be able to research operations that belong to different authorities. Should make the concept of geodetic_datum_preferred_hub introduced some time ago obsolete

2019-11-17T19:03:29+00:00