| Age | Commit message (Collapse) | Author |
|
createOperations(): fix transformation involving CompoundCRS, ToWGS84 and PROJ4_GRIDS
|
|
Fix issues with WKT of concatenated operations (#3076)
|
|
|
|
MapServer/MapServer#6478)
|
|
DerivedGeographicCRS coming from WKT
|
|
commit. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43546
|
|
Implement Geographic3D to Depth/Geog2D+Depth as used by ETRS89 to CD Norway depth
|
|
|
|
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
|
|
Projected 3D CRS EPSG:9895 'Luxembourg TM (3D)'
|
|
Since the update to Doxygen 1.9.3, doc generation was broken. With
bisection of doxygen, it was found this was due to commit
https://github.com/doxygen/doxygen/commit/ee8f3fb7a2ed74ee30ae3202707617e97f6641ff
which makes Doxygen honour nested @cond . This revealed bad pairing of
@cond / @endcond in our code, fixed by this commit.
|
|
by setting its value from the azimuth angle.
and on export to PROJ.4 string do not emit a erroneous +gamma=0 when the
parameter it is missing.
Fixes https://lists.osgeo.org/pipermail/proj/2021-December/010475.html
|
|
"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
|
|
division by zero. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41045
|
|
createOperationsCompoundToCompound(): fix null pointer dereference when connection to proj.db doesn't exist.
|
|
connection to proj.db doesn't exist. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40955
|
|
for vertical transformations
In particular helps with transformation between "NAD83 + NAVD88 height" and WGS 84 that
have regressed in 8.2.0
Fixes #2936
|
|
|
|
|
|
if conversion factor is 0. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40050
|
|
conversion factor of target unit is 0. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39969
|
|
1SP or 2SP (fixes #2892)
|
|
conversion is the first or last operation (fixes #2890)
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39033
|
|
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.
|
|
|
|
netCDF datasets using a pole rotation method
|
|
Issue found during https://github.com/OSGeo/gdal/pull/4355 when it was found
that a WKT with Goode_Homolosine projection parsed as ESRI WKT was mapped
wrongly to Interrupted Goode Homolosine
|
|
inverse map projection is involved in non-final step (fixes #2817)
|
|
a CRS that has a fallback-to-PROJ4-string behaviour and is a BoundCRS of a GeographicCRS (fixes #2804)
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36751
|
|
Fix issue reported in https://lists.osgeo.org/pipermail/proj/2021-July/010318.html
|
|
|
|
|
|
CRS with a GEOIDMODEL using a PROJ grid, so that it is later used instead of a ballpark operation (fixes #2768)
|
|
specific to EPSG:9731 now that is is deprecated
|
|
|
|
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.
|
|
|
|
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).
|
|
+hyperbolic
|
|
|
|
|
|
Issue spotted by GDAL autotest suite.
|