| Age | Commit message (Collapse) | Author |
|---|
|
Remove unnecessary functions and restructure proj.def.
|
|
|
|
[WIP] 4D API cs2cs style
|
|
|
|
The GIGS tests that are known to work are added to the CMake test
setup. The GIGS gie files have been auto-translated from the
existing json-files and some corrections to tolerances have been
necessary since gie uses different norms than GIGS specify. The GIGS
tolerances are specified as the infinity norm of angular coordinates,
whereas gie uses the actual distances between calculated and expected
coordinates (using geodesics). In a few tests +towgs84 is overriden
from the EPSG inits to avoid creeping numerical inaccuracy in
roundtrips.
Co-authored-by: Thomas Knudsen <thokn@sdfe.dk>
Co-authored-by: Kristian Evers <kristianevers@gmail.com>
|
|
|
|
Parameters such as towgs84, nadgrids and geoidgrids was previously only
handled by pj_transform(). This commit add a compatibility layer in
proj_create() by calling the pj_cs2cs_emulation_setup() function. This
function sets up a handful of predefined transformation objects on the
PJ object that is being created. Each of these transformation objects
are related to the cs2cs-style parameters we are trying to emulate in
the 4D API. That is, if the +towgs84 parameters is used we create
P->helmert with the parameters specified in +towgs84. Similarly for
+axis, +nadgrids and +geoidgrids. When these transformation objects
exists we use them in the prepare and finalize functions in pj_fwd/
pj_inv. If no cs2cs-style parametes are specified we skip those
parts of the prepare and finalizing steps.
Co-authored-by:Thomas Knudsen <thokn@sdfe.dk>
Co-authored-by:Kristian Evers <kristianevers@gmail.com>
|
|
Add pj_has_inverse().
|
|
With the introduction of the "inverted" flag on PJ objects
you can no longer rely on checking that the inv, inv3d and inv4d
functions are available on said PJ object. The function is used
internally a few places and otherwise exposed in proj_api.h to
ensure that users of the old programming interface can safely
check if an operation has an inverse.
|
|
|
|
d0dbf48438f9e152314abf294467cb54f9ae0e70 changes. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5649. Credit to OSS Fuzz
|
|
Handle ellipsoid parameters correctly when using +nadgrids=@null.
|
|
Make sure to not change ellipsoid parameters to WGS84 when applying the
null grid. Coordinates will still refer to the input ellipsoid so we
keep the original parameters which in turn will be used when the
coordinates are transformated to/from cartesian/geocentric space.
Adjusted regression test material in nad/proj_outIGNF.dist slightly to
accomodate numerical differences at the mm level. The transformations
in question are at best accurate to about 1m so this shouldn't change
real world usage of these transformations.
|
|
|
|
documentation [skip ci]
|
|
|
|
Pipeline and cct inverse fixes
|
|
|
|
"+proj=pipeline +inv +step +urm5 +n=0.5 +inv" now works as expected,
returning the forward operation of urm5. In principle adding more +inv's
should also work, resulting in the forward operation when an even number
of +inv's are present, and the inverse when an odd number of +inv's
are present.
"+proj=pipeline +step +urm5 +n=0.5 +inv" fails at initialization since
no forward operation can be performed. This is a new requirement, but
aligns perfectly with the rest of the library since no operation without
a forward method exists.
|
|
axisswap initialization: avoid switch case fallthrough
|
|
Some projections do not have an inverse mapping. If such a projection is used
as a (forward) step in a pipeline we won't be able to perform an inverse
operation using the pipeline. By setting the inv, inv3d and inv4d pointers to
zero we signal to the caller that an inverse mapping is not available.
|
|
Similar to proj and cs2cs, cct now returns immediately when trying to
do an inverse operation that is not possible, for example using
proj=urm5 which doesn't have an inverse:
$ cct.exe -I +proj=pipeline +step +proj=urm5 +n=0.5
Inverse operation not available
|
|
case without break are really confusing, and should be avoided as much
as possible IMHO.
Also error out if a unrecognized character is provided as the axis value.
|
|
|
|
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5073. Credit to OSS Fuzz. master only
|
|
Remove or use unused macros
|
|
Download grid files as the first thing in the travis install script and
that 'make check' can be run without errors caused by missing grids.
|
|
|
|
|
|
|
|
Some macros seemed to be leftover from earlier code, so I removed them.
Others seemed like they should have been used, but weren't.
There should be no functional change, except the following: in floating-
point arithmetic, x / y is not the same as x * (1.0 / y). It can be
argued that using the multiplication is significantly faster, and the
algorithm is approximative anyway. Otherwise, the constants are
obviously not required.
Also fixes one location in PJ_aitoff.c, where an enumeration value
should have been used.
|
|
Instead of +order the classic PROJ.4 parameter +axis can used instead.
This is mostly an inititive to simplify backwars compatibility in the
4D API. P->axis is initialized in pj_init() it can be assumed that it
is set up correctly.
+order and +axis are mutually exclusive.
|
|
|
|
|
|
|
|
|
|
|
|
Added the possibility to use custom unit factors. Similar to the
classic +to_meter parameter the conversion factor is related to meters,
i.e. the factor for conversion from kilometers meters is 1000. The
custom unit factors is given using the existing xy_in, xy_out, z_in and
z_out parameters, for example:
proj=unitconvert xy_in=4.5 +xy_out=mm
|
|
|
|
In cases such as:
proj=pipeline step proj=utm zone=32 ellps=GRS80 ...
The pj_init code would pick up the ellps information (and other material such as false eastings and northings) from the utm step and place it into the PJ object of the pipeline driver.
This is not the intention, and is eliminated in this PR by terminating parameter searching (done by pj_param) once a step parameter is reached.
|
|
arbitrary dimensionality in test code
* Call trans func of same dimensionality as input in gie
* Refactor prep/fin code for pj_fwd/pj_inv 2D,3D,4D
* Remove prime meridian handling from pj_transform (now handled in pj_fwd_prepare/pj_inv_finalize)
* Introduce prep/fin skips, mostly in support of axisswap and pipeline drivers
* Refactor fwd/inv subsystem
* pj_transform: Let pj_fwd/inv handle scaling
* Let pj_fwd/inv3d fall back to 2D eventually
|
|
Parameters for the plate motion models (PMM) for ITRF2008 and ITRF2014
are added to the ITRF2008/2014 init-files. The PMMs allow coordinates
to be moved back and forward in time in plate fixed reference frames
such as GR96 in Greenland which is defined as ITRF94@1996.623.
Transforming an ITRF2014-coordinate to GR96 is done with:
+proj=pipeline +step +init=ITRF2014:NOAM +t_epoch=1996.623 +t_obs=2017.584
+step +init=ITRF2014:ITRF94 +t_obs=1996.623
where the first step transforms the coordinate back in time to
ITRF2014@1996.632 by using the ITRF2014 PMM. The second step transforms
the ITRF2014 coordinate to ITRF94.
|
|
|
|
Repair column selector bug
Fixes #723
|
|
|
|
Avoid zero-division in ccon.
|
|
Credit to OSS-Fuzz. https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4695
|
|
Reykjavik (1900) datum, prerequisites: Danish (Andræ) ellipsoid, and Copenhagen meridian introduced in support of the Reykjavik 1900 datum (Iceland).
The magnitude of the Danish (1876) ellipsoid was originally given in French toise (fathoms) - the Andræ ellipsoid already in PROJ seems to have been transformed to meters using a conversion factor for German fathoms.
This version, based on a French conversion factor of 1.94903631 m/toise, corresponds to the official value for the semimajor axis used by the Icelandic NMA, Landmælingar Íslands, LMI (Guðmundur Valsson, LMI, pers. comm. 2017-12-15).
This value deviates by approximately one centimeter, compared to the truncated value of 6377019.27 m, given in the EPSG:7051 record.
|
|
the Reykjavik 1900 datum (Iceland)
|
