| Age | Commit message (Collapse) | Author |
|
rouault/intermediate_crs_use_only_if_no_direct_transformation
Modify the default strategy of researching intermediate CRS to do it only if there is no direct transformation
|
|
cases on non-x86 arch (fixes #1275)
|
|
there is no direct transformation
|
|
PJ object returned by proj_create_crs_to_crs() when there are several alternatives
|
|
proper CoordinateOperation so that we can call proj_get_source_crs() on it for example
|
|
|
|
GTest provides a configuration file, so we can disable the module
mode. If the GTest package cannot be found, this shall be reported
right here. (Note that while we specify a version, we do not require
an EXACT match.)
|
|
GTest::gtest is the imported target supplied by find_package(GTest).
For the internal build of GTest, this target is created as an alias
for now: find_package cannot be used because the interal build does
not get installed, and so a package config file is not available.
|
|
PROJ requires CMake >= 3.5.
|
|
This fixes issues with MinGW when threads are used.
|
|
the push/pop v_3 operator to preserve the Z component
|
|
from +proj=helmert/molodensky since there are ambiguities
|
|
* Make tmerc an alias for etmerc
This switches the algorithm used in tmerc to the Poder/Engsager
tmerc algorithm. The original tmerc algorithm of Evenden/Snyder
origin can still be accessed by adding the +approx flag when
initializing a tmerc projection. The +approx flag can also
be used when initializing UTM projections, in which case the
Evenden/Snyder algorithm is used as well.
If a tmerc projection is instantiated on a spherical earth
the Evenden/Snyder algorithm is used as well since the
Poder/Engsager algorithm is only defined on the ellipsoid.
+proj=etmerc can still be instantiated for backwards compatibility
reasons.
Co-authored-by: Kristian Evers <kristianevers@gmail.com>
Co-authored-by: Even Rouault <even.rouault@spatialys.com>
|
|
|
|
This method is intended to be used typically by GUI that lists all possible CRS.
What is does could be done by previously existing functions, but it is much faster.
It typically runs in less than 0.1s (hot run) versus ~0.5s with the method that
consists in enumerating all codes and instanciating a PJ object for each of them.
|
|
|
|
|
|
|
|
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12867. Credit to OSS Fuzz. master only
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12854. Credit to OSS Fuzz
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12837. Credit to OSS Fuzz
|
|
only to avoid breaking other use cases
|
|
Update ds to be in correspondence with ITRF2000 file
|
|
operations (fixes #1237)
|
|
Coordinate operation computation with boundcrs / wktext: drop useless early bindins terms in generated pipeline (fixes #1232)
|
|
datum by ellps
|
|
proj_create_crs_to_crs(): defer selection of actual coordinate operation until proj_trans() is called (fixes #1229)
|
|
|
|
|
|
bindins terms in generated pipeline (fixes #1232)
|
|
until proj_trans() is called (fixes #1229)
|
|
|
|
make proj_create() do more or less what proj_create_from_user_input() did before (fixes #1214)
|
|
CRS objects (refs #1214)
|
|
parsed appropriately on the reading side
|
|
|
|
Add API in proj.h to set a file finder callback and search paths; support multiple directories in PROJ_LIB
|
|
transformation (fixes #1220)
|
|
proj_context_set_search_paths() (refs #1150)
|
|
|
|
As discussed in https://github.com/OSGeo/proj.4/issues/1214#issuecomment-452084720,
the introduction of a new PROJ.5 format to export CRS using pipeline/unitconvert/axisswap
as an attempt of improving the PROJ.4 format used by GDAL and other products is
likely a dead-end since it is still lossy in many aspects and can cause confusion
with coodinate operations.
Consequently the PROJ_5 convention will be identical to PROJ_4 for CRS export.
Note: on the import side, I've kept the code that could parse unitconvert and
axisswap when building a CRS definition from a pipeline. It is there as a hidden
feature as it was kind of a tear to remove that code in case it might still be
useful...
|
|
|
|
|
|
is disabled
|
|
With this commit we make sure that proj_angular_input() and
proj_angular_output return the correct result for any given pipeline.
|
|
operations when neededs (fixes #1197)
|
|
|
|
not possible
|
|
|