| Age | Commit message (Collapse) | Author |
|---|
|
|
|
#1198)
|
|
We store the PJ_CONTEXT* in the PJ_OBJ objects, but this
might cause issues in multi-threaded uses.
For example, before this change, let's imagie:
- a PJ_OBJ is created in thread A with a PJ_CONTEXT that
is specific to this thread A
- PJ_OBJ is transfered to another thread that operates on
it. It might thus use the PJ_CONTEXT that was TLS(A)
- in the meantime thread A does completely different things,
but still operate on its PJ_CONTEXT. We might get a
concurrent use of the PJ_CONTEXT despite working on
different PJ_OBJ
Another situation is when using constructor functions that
take two PJ_OBJ. Up to now, we arbitrarily selected the context
of one of the arguments to attach it to the new object.
So better be explicit on which context is used.
For reference, in those wrappers of the C++ API, the
context is mostly used for two things:
- reporting C++ exceptions as PROJ errors with the error handler
attached to the PJ_CONTEXT
- using the database handle that is associated with the PJ_CONTEXT.
|
|
|
|
the data/epsg and data/IGNF files
|
|
|
|
of use argument, and make createFromUserInput() recognize init=epsg: / init=IGNF: in legacy mode, that is when proj_context_get_use_proj4_init_rules() is used
|
|
Closes #1107
|
|
in +towgs84 case, we use sprintf() with floating-point formatter to output
the ellipsoid parameters. For a locale with decimal separtor != dot, the
resulting string will not be parsed correctly by proj_atof(), leading to
wrong numeric result.
The fix is similar to the one done in pj_latlong_from_proj()
Note for later: if using C++, we could use a locale-independent formatting
solution to avoid such issue.
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10033. Credit to OSS Fuzz. master only
|
|
forbids +transpose (fixes #1091)
As identified in #1091, Helmert implementation in PROJ 5.0 and 5.1 is confusing.
It happens that by default it used the coordinate_frame convention, contrary to
the position_vector convention used traditionaly for +towgs84. The documentation
of Helmert was also wrongly specifying that the default convention was
position_vector.
This commit:
- bans the confusing +transpose parameter
- removes the concept of a default convention, since in practice both are
equally found, and requires +convention as soon as a rotational term parameter
is present.
For translation only, convention is ignored and optional, as having no effect.
- fixes all the identified uses of proj=helmert in code, doc and tests
This is obviously a breaking change:
- users will have to adapt their pipeline expressions
- in particular, init files that would use helmert must be adapted
However, as designed, the break will be explicit, and not silent.
|
|
When there are no arguments, we set PJD_ERR_NO_ARGS, just like the old
API does in that case.
On allocation failure we set ENOMEM as usual.
|
|
|
|
(detected by gcc 8.1)
|
|
|
|
We are relying more and more on C99 math functions. On C89 systems where
those functions are not available our own custom versions of those
functions are used instead. So far these has been spread across the code
base. This commit gathers them in the same file and introduces the
proj_math.h header. The build system checks for C99 math functions. If
not found the proj_math.h header make sure that C99 functions are
defined as their pj_ equivalent.
Ideally proj_math.h is included instead of math.h. This removes the need
for any checks against HAVE_C99_MATH in the code making it easier to
read.
For this commit the functions hypot, log1p and asinh has been taken care
of.
|
|
original ellipsoid parameters (before any projection mess with them)
|
|
geodetic->cartesian->geodetic (fixes #881)
|
|
#871. (#873)
|
|
|
|
|
|
Remove 'pj_' prefix from static functions
|
|
|
|
Functions should only be prefixed with 'pj_' when they can be used in
other parts of the code base and not just within a single file.
Takes care of the last step in #675.
|
|
* Avoid using angle brackets for PROJ headers.
Switching from #include <proj.h> to #include "proj.h",
and correspondingly for projects.h and proj_api.h,
reduces the risk of accidentally picking up a system
installed older version of the header while building
a new version of PROJ.
* Also handle geodesic.h
|
|
Changes use of 'PJ_COORD coo' to 'PJ_COORD coord' so that variable names in
public function prototypes are consistent.
Closes #842.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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
|
|
Having non-const variables of static lifetime or even global scope is
usually a bad idea. These variables are inherently constants, and this
should be enforced.
This required marking some functions as not modifying input parameters
and marking some pointers as pointers to const.
One advantage is that the compiler usually puts const static variables
in a read-only code segment, so they can't be modified physically.
This can be verified with `nm` (on POSIX systems).
To avoid changes to the public API, functions returning non-const
pointers to data tables were left intact, but the returned data may not
be modified. Internally we prefer using the proj_list_* functions over
the pj_get_*_ref functions, because the former return const pointers.
|
|
* Free format now in cmd lines, in gie, and in init files
* Corrected handling of defaults
* Add demo of integrated definition and validation
* Repair stack-smashing memmove in get_init
* repair paralist corruption, clean up debug output
* Install test files for nmake builds
* Add many improvements following suggestions by @schwehr
* Be consistent in requiring lower case everywhere in gie.c
Also, this Fixes #703 and Fixes #697
|
|
|
|
Increase the focus on PJ_COORD as primary datatype: Eliminate use of PJ_TRIPLET etc.
Trim proj.h by removing material that has become unnecessary.
Improve constness
Make proj_factors work in proj.h space, by providing a trimmed down PJ_FACTORS (which even has more meaningful field names)
|
|
* Replace pj_ell_set with reimplementation supporting ellipsoid inheritance
* remove unreachable code from pj_ell_set.c
* Swap steps, so ellps args are read first, in accordance with historical behaviour
* Add ellipsoid tests to CI targets
* Reduce some optimistic tolerances
OS/X appears to have a slightly off float handling, resulting in differences at the nanometer level. Switching to 10 nm.
|
|
* Introduce geodetic-geocentric conversions, as PJ_xxx style conversion step and as API entry points
* minor improvements and minor bug squashing
|
|
* Support numerical factors only
* Make sure h positive. Improve some comments
* Let pole overshoot check have effect even for geocentric latitudes
* Factor-typological constants, now all returning false, for backwards compatibility
|
|
* Poder dual autochecking implementation
* Debugging aid: Improvements in PJ_vgridshift.c and gie.c
* Most likely, the bugbeing tripped is in the gridshift code, so. uncomment suspicious lines in deformation.gie and merge this to support the debugging effort
|
|
proj_create is now indifferent whether or not proj definition terms start with a '+' character. Also, improve gie to support testing this.
|
|
|
