| Age | Commit message (Collapse) | Author |
|---|
|
Copy ellipsoid definition for proj=cart directly into the
proj_create call, rather than calling pj_inherit_ellipsoid_def
afterwards.
Previously, the ellipsoid definition was left out from the call.
pj_init_ctx would then pick up WGS84 from proj_def.dat, and the
init would succeed (and the possibly wrong ellipsoid definition
would later on be overwritten with the correct values by
pj_inherit_ellipsoid_def.
But if PROJ_LIB was not set or proj_def.dat was inaccessible for
other reasons, things went wrong.
|
|
Due to the slightly involved way a pipeline is set up, only a small
subset of the definition parameters are directly read by the pj_init
code. The remaining parameters will not get their "used" flag set,
and for that reason will not be included in the projection definition
element of a PJ_PROJ_INFO, returned by proj_pj_info.
For now, we force the "used" flag of all elements of a pipeline to be
set. The code is tested by introducing cct functionality for printing
the projection definition used.
|
|
Reset error type PJD_ERR_MAJOR_AXIS_NOT_GIVEN for operations
that do not need an ellipsoid.
|
|
A few repairs in and around pj_init.c
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
