| Age | Commit message (Collapse) | Author |
|---|
|
transformations using geoidgrids)
When importing from a PROJ4 string with +towgs84, +nadgrids or
+geoidgrids terms, the datum name was just set to 'unknown'. So for
example the datums of '+proj=longlat +ellps=GRS80 +towgs84=1,2,3' and
'+proj=longlat +ellps=GRS80 +towgs84=4,5,6' were considered identical,
because they had the same name 'unknown' and used the same ellipsoid.
This affected the transformation of such CRS when they had an
additional +geoidgrids term, which resulted in an erroneous +proj=push
+v_1 +v_2 step to be added to preserve the horizontal coordinates.
|
|
PROJ4_GRIDS
Fix issue reported in https://lists.osgeo.org/pipermail/gdal-dev/2022-March/055587.html
|
|
to 2D CRS / add --3d to cs2cs
Previously, when computing transformation between a compound CRS and a
geographic/projected 2D CRS, the behaviour was similar to implicitly
promoting the 2D CRS to 3D CRS in the pipeline computation logic, hence
a geoid model could be applied. But note that when doing a geographic 3D
to geographic/projected 2D CRS transformation, we *did* not do this implicit
promotion and if a Helmert transformation existed between the datums, it
was done only in 2D. So this is a bit inconsistent and triggered the
comment in https://github.com/OSGeo/PROJ/issues/2318#issuecomment-1068924513
With this commit, we no longer do any vertical transformation when doing
compound CRS to the 2D CRS, but just take the transformation of the
horizontal part of the compound CRS to the 2D CRS.
Said otherwise, NAD83+NAVD88 to NAD83 will no longer lead to the
application of the geoid model. Unless you explicitly ask for the
promotion NAD83 to 3D.
Also related, in https://github.com/OSGeo/PROJ/issues/1563 that went to 6.3.0,
I changed cs2cs to automatically promote to 3D the CRS as soon as one of
them was compound, for the sake of being consistent with the past
behaviour. But it then becomes difficult to predict PROJ behaviour
depending on which level of it you consider...
This commit undoes that and adds an explicit --3d switch to cs2cs, similarly to
projinfo, to ask for promotion.
Other bug fix found in the process, when using legacy syntax, +init=epsg:4979,
(WGS 84 3D), the resulting CRS was 2D and not 3D.
|
|
CRS -> +proj=longlat +lon_wrap (fixes #3095)
|
|
prime meridian, created from WKT (fixes OSGeo/gdal#5408)
|
|
DerivedGeographicCRS coming from WKT
|
|
depth
Fixes #2739
Verified with example from IOGP Guidance Note 7-2 (ver 62, Dec 2021) page 169, with
38 = h_obs - D_obs = 50 - 12.
$ echo 60.0015 4.9960 38 | PROJ_LIB=data PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:4937 EPSG:9883
60.0015 4.9960 5.8827
$ echo 60.0015 4.9960 38 | PROJ_LIB=data PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:4937 EPSG:4258+9672
60.0015 4.9960 5.8827
$ echo 60.0015 4.9960 5.8827 | PROJ_LIB=data PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:9883 EPSG:4937
60.0015 4.9960 38.0000
$ echo 60.0015 4.9960 5.8827 | PROJ_LIB=data PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:4258+9672 EPSG:4937
60.0015 4.9960 38.0000
|
|
"NAD83(CSRS) + CGVD2013(CGG2013) height"
That transformation involves doing CGVD28 height to CGVD2013(CGG2013)
height by doing:
- CGVD28 height to NAD83(CSRS): EPSG registered operation
- NAD83(CSRS) to CGVD2013(CGG2013) height by doing:
* NAD83(CSRS) to NAD83(CSRS)v6: ballpark
* NAD83(CSRS)v6 to CGVD2013(CGG2013): EPSG registered operation
|
|
for vertical transformations
In particular helps with transformation between "NAD83 + NAVD88 height" and WGS 84 that
have regressed in 8.2.0
Fixes #2936
|
|
|
|
longitude)
|
|
This seriously impacts French CRS users with the introduction of new
datums, geodetic CRS and projected CRS based on "RGF 93 v2" and "RGF 93 v2b",
and the previous single "RGF 93" being renamed as "RGF 93 v1".
To be noted too, the addition of a null transformation between NAD83(2011)
and WGS 84, which impacts a number of tests in the test suite.
|
|
geocentric latitude
|
|
This also fixes conversion between geocentric latlong and geodetic latlong
with cs2cs. This was dealt with in PR 1093, but in the wrong direction
(the geocentric latitude must be <= in absolute value to the geodetic one)
The issue here was linked to the semantics of the +geoc specifier, which
affects the semantics of the input coordinates in the forward direction
(+geoc means that the input coordinate is is a geocentric latitude),
which defeats the logic of doing A to B by using the inverse path of A
and the forward path of B.
|
|
a CRS that has a fallback-to-PROJ4-string behaviour and is a BoundCRS of a GeographicCRS (fixes #2804)
|
|
Fix issue reported in https://lists.osgeo.org/pipermail/proj/2021-July/010318.html
|
|
|
|
CompoundCRS are involved (fixes #2720)
|
|
|
|
Non-trivial updates:
- some vertical CRS are now encoded as DerivedVerticalCRS. e.g EPSG:8228
"NAVD88 height (ft)", with base EPSG:5703 "NAVD88 height". As we don't
have support in our PROJ db model for DerivedVerticalCRS, modify the
import script to 'resolve' the derivation up to the original datum.
- Method EPSG:1069 'Change of Vertical Unit' is no longer used. It is
replaced by a generic-purpose EPSG:1104 method that doesn't take any
conversion factor. And generic conversions EPSG:7812 and EPSG:7813 are
now used in concatenated operations, which require code changes as
well.
|
|
regression)
|
|
createBetweenGeodeticCRSWithDatumBasedIntermediates() reachable...
... and optimize its execution time by rewriting it completely.
This code path was no longer triggered in tests since EPSG got a direct
transformation for GDA94 to WGS 84 (G1762).
|
|
Issue spotted by GDAL autotest suite.
|
|
(fixes #2588)
when the source and target CRS share the same geog CRS, but the interpolation
CRS of the vertical transformation isn't the same, and a Helmert
transformation exists between them...
For example, for "CH1903+ + EGM96" to CH1903+ 3D where the interpolation
CRS is WGS84.
|
|
|
|
RGF93 and CH1903+ (fixes #2541)
|
|
|
|
|
|
Database: update to EPSG v10.011
|
|
|
|
|
|
|
|
ellipsoidal height
|
|
from BoundCRS of projected CRS based on NTF Paris to BoundCRS of geog CRS NTF Paris. Fixes https://github.com/OSGeo/gdal/issues/3273
|
|
|
