| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Fix proj.h + proj_api.h inclusion errors
|
|
|
|
together.
|
|
This version takes to add the include path to the target definition for
cmake 2.8.11 and later. Also the documentation sticks to the existing
convention of using cmake variables ${PROJ4_LIBRARIES} and
${PROJ4_INCLUDE_DIRS}. However, the namespace variables are still being
included.
Here's the roll-out plan
(0) Version 4.9.x: The target is proj and PROJ4_LIBRARIES is set to
this.
(1) Version 5.0.x: Two targets, proj and PROJ4::proj, are defined;
PROJ4_LIBRARIES = proj.
(2) In a year or two: Two targets, proj and PROJ4::proj, are defined;
PROJ4_LIBRARIES = PROJ4::proj.
(3) With a change in the library which breaks backwards compatibility:
The target is PROJ4::proj and PROJ4_LIBRARIES = PROJ4::proj.
|
|
Make 4D API fully 4D:
Remove PJ_XY, PJ_LP, PJ_XYZ, PJ_LPZ etc. from the API surface and
make all formal parameters of the API fully 4D PJ_COORD.
This operation primarily influences the proj_XXX_dist functions,
which mostly work by calling Charles Karney's geodesic
subsystem, keeping the distance, and throwing away the start and
end azimuths for the geodesic computed.
Also a PJ_GEOD(esic) persona is introduced for the PJ_COORD type.
The proj_geod function returns a PJ_GEOD, representing the geodesic
between the points represented by its PJ_COORD arguments.
Finally, the proj_factors functions had its lp argument changed
from PJ_LP to PJ_COORD.
|
|
Also make corresponding sign corrections in a number of tests,
and comment out a few tests which work correctly, but report
failure since gie is not yet ready to handle unusual axis
orders in cases with angular output coordinates.
|
|
|
|
|
|
|
|
Functionnaly equivalent to https://github.com/OSGeo/proj.4/pull/371 by Jürgen Fischer
See
http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/de_dhdn2etrs_beta.php
Confirmed with Uwe Schmitz <uwe.schmitz@bezreg-koeln.nrw.de> that free
redistribution is allowed and welcome.
|
|
Remove unnecessary definitions of UV and UVW from project.h that collides with
external libraries. To prevent similar problems in the future the
datatypes XY, LP, UV, XYZ, LPZ and UVW has been prefixed by PJ_ in
proj.h and proj_internal.h
|
|
* Shrink PJ_XXX_INFO structs, but keep same syntax.
A number of the fixed length strings in the INFO structs are simply
reflections of material that already exists as static strings at a
number of places in the library (or in the case of PJ_INFO, really
*should* exist, and now is implemented).
This PR replaces these cases of constant length strings with const
char pointers. The usage syntax is unchanged, and so is the nice
property of having the return value allocated on the stack, and
hence not requiring explicit memory management by the caller.
proj_info now only does setup once - and the searchpath entry of
PJ_INFO is not arbitrarily truncated at 512 bytes. Repeated calls
simply returns a copy of already prepared material.
The id, description and definition entries of PJ_PROJ_INFO are now
also guaranteed to hold the entire text of the corresponding static
string, by being represented by a const char pointer to that actual
static string.
PJ_GRID_INFO and PJ_INIT_INFO (i.e. the two smallest INFO structs)
are unchanged.
* Eliminate pj_strlcpy - not needed anymore: Remining calls could
safely be replaced by strncpy.
* Extend PROJ_INFO with paths from pj_set_searchpath.
NOTE: Need to call pj_set_searchpath before first call to proj_info
Huge thanks to Kristian Evers and Even Rouault for comments, debugging and advice.
|
|
|
|
Error codes can't be specified directly in pj_free. With this change the
error number in proj_errno() is passed on to P->destructor to ensure
that we communicate the correct reason why the PJ object is being freed.
This was a problem in the cs2cs_emulation setup when auxillary
operations failed to create. The error was not propagated properly when
destroying the parent object.
|
|
Introducing a new keyword 'skiperror' that when given a error
code like pjd_err_failed_to_load_grid will skip tests if that
error is returned when creating the operation. This is useful
for grids that can't be located.
|
|
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.
|
|
|
|
|
