PROJ/test/unit, branch azp

createOperations(): fix wrong pipeline generation with CRS that has +nadgrids= and +pm= (#1998)

2020-02-29T12:24:58+00:00

Fixes issue reported at
https://lists.osgeo.org/pipermail/gdal-dev/2020-February/051749.html

The generated pipeline assumes that the input coordinates for the grid transformation
were related to the non-Greenwich based datum, so we must compensate for that and
add logic to go back to Greenwich.

Formatting fix

2020-02-28T15:05:56+00:00

Make tests independent of proj-datumgrid

2020-02-27T12:19:13+00:00

Fixes #1984

- Copy BETA2007.gsb, MD, alaska, conus, ntf_r93.gsb, ntv1_can.dat grids
  from proj-datumgrid to data/tests.
- Replace a couple uses of nzgd2kgrid0005.gsb in tests by ntf_r93.gsb
- Add downsampled/subsetted versions of egm96_15.gtx as tests/egm96_15_downsampled.gtx
  and ntv2_0.gsb as tests/ntv2_0_downsampled.gsb
  This results in a few changes in expected results
- Simpify travis/install.sh due to less configurations to test

This results in a hopefully acceptable increase of the proj-X.Y.Z.tar.gz
from 2.9 to 5.3 MB

Database: register 4 height Austrian grids from https://github.com/OSGeo/PROJ-data/pull/13 + handle 'Vertical Offset by Grid Interpolation (BEV AT)' method

2020-02-26T15:23:39+00:00

Database: update to EPSG v9.8.7

2020-02-26T13:04:09+00:00

createOperations(): be robust to a GeographicCRS having a wrong ID attached to it (fixes #1982)

2020-02-25T14:32:28+00:00

CompoundCRS::create(): reject combinations of components not allowed by ISO 19111

2020-02-24T23:19:19+00:00

createOperations(): keep height/z value in Helmert transform between 3D CRS

2020-02-24T19:37:49+00:00

This is the consequence of a private email thread between me, Joel Haasdyk and
Roger Lott. I initially raised that the GDA2020 technical manual advertized the
Helmert transformation between GDA94 to GDA2020 to be a 3D one, with example of
a test point where ellipsoidal heights where modified. It appears this was intended.

The corresponding record in EPSG uses the EPSG:9607 "Coordinate Frame rotation (geog2D domain)"
method between the 2D geographic CRS of GDA94 and GDA2020. From the email exchange,
it appears that there's a lot of legacy explaining that Helmert transformations
are registered only between 2D CRS, which doesn't mean that when applied to the
corresponding 3D CRS, the change in ellipsoidal height should be discarded. Related
to that, the EPSG database, while it has methods flagged "(geog3D domain)" never uses them.

So... this changeset slightly ammends PROJ behaviour to ignore the "(geog2D domain)" flag,
but only consider the dimensionality of the source & target CRS. However, for a EPSG
transformation, those are always 2D CRS, hence introduce the use3DHelmert_ hack when
we know that ultimately the 'real' source & target CRS are 3D.

I wouldn't be surprised if in more complex pipeline the above logic would be lacking.
But it fixes at least simple transformations.

Fix mapping of Vertical_Near_Side_Perspective (fixes #1965)

2020-02-24T11:43:00+00:00

Merge pull request #1962 from mwtoews/shared

2020-02-22T00:35:36+00:00

CMake: rename BUILD_LIBPROJ_SHARED to BUILD_SHARED_LIBS