| Age | Commit message (Collapse) | Author |
|---|
|
Add --version option to gie and cct.
|
|
Additionally correct a spelling error in optargpm.h and
remove two lines of leftover cruft from gie.c
|
|
Fixes: #763
|
|
Avoid buffer overflow - OSSFuzz issue 5903
|
|
|
|
|
|
Remove Windows CE cruft (wince/msvc80)
|
|
|
|
|
|
Closes #582
|
|
|
|
make local derivatives available in PJ_FACTOR
|
|
|
|
|
|
|
|
|
|
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>
|
|
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
|
|
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.
|
|
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.
|
|
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
|
|
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
|
|
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
|
|
the Reykjavik 1900 datum (Iceland)
|
|
Previously, when expanding init=foo.bar calls, pj_chomp was first called after collecting all lines, effectively discarding everything after the start of the first comment
|
|
* Some corrections in response to a review by Kristian Evers
|
|
in GeographicLib). Details:
Workaround bugs in handling of -0.0 in fmod and sin in Visual Studio 10,
11, and 12.
Relax unrealistically strict delta for GeodSolve59 in geodtest.
|
|
Fixes #699
|
|
Declare non-local variables as const where possible
|
