| Age | Commit message (Collapse) | Author |
|
MapServer/MapServer#6478)
|
|
commit. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43546
|
|
|
|
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
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39033
|
|
longitude)
|
|
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
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36751
|
|
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.
|
|
|
|
The big size of coordinateoperation.cpp could require significant amount
of RAM to build it with -O2 level, and cause compiler crashes in some
environments.
|