| Age | Commit message (Collapse) | Author |
|
from their components
Support following syntaxes:
- OGC URN combining references for compoundCRS:
e.g. "urn:ogc:def:crs,crs:EPSG::2393,crs:EPSG::5717"
- its GDAL shortcut: e.g. "EPSG:2393+5717"
- OGC URN combining references for concatenated operations:
e.g. "urn:ogc:def:coordinateOperation,coordinateOperation:EPSG::3895,coordinateOperation:EPSG::1618"
|
|
|
|
doing geog2D<-->geog3D conversions of same datum
Seen when testing transformations between "CR 05" (EPSG:5365) and "CR-SIRGAS" (EPSG:8907)
which require going through their corresponding 3D GeogCRS to find a Helmert
transformation.
|
|
CMake: Remove need to fiddle with CMAKE_C_FLAGS / CMAKE_CXX_FLAGS
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14055
Credit to OSS Fuzz
|
|
Remove (most) needs to fiddle with CMAKE_C_FLAGS / CMAKE_CXX_FLAGS
|
|
Add no-op operation. It does nothing.
|
|
intermediate IDs (fixes #1343)
|
|
|
|
createOperations(): improve BoundCRS<-->non-bound-CRS case
|
|
Fixes #1301
This function takes the output PJ from proj_create_crs_to_crs(),
and add (or undo) the needed axis swap operations so that the
object returned by proj_normalize_for_visualization() has the usual
GIS axis order.
In this implementation, this does something only if the coordinate
system of the source or target CRS, geographic or projected, has
NORTH, EAST ordering.
CompoundCRS wrapping those objects are also handled.
|
|
Fixes #1388
Typically helps for
projinfo -s "+proj=longlat +ellps=GRS80 +towgs84=1,2,3 +type=crs" -t EPSG:4258
by researching operations from the pivot WGS84 implied by the towgs84 clause
to EPSG:4258.
|
|
pj_strerrno: enable system error messages
|
|
Grid related fixes
|
|
the file system, but not in the database
|
|
HAVE_STRERROR is defined in proj_config.h.
|
|
|
|
|
|
|
|
even if there is one on upper node
This is a particular logic allowed by paragraph 7.3.3 Identifier
of OGC 18-010r6
|
|
This is a particular logic allowed by paragraph 7.3.3 Identifier
of OGC 18-010r6
|
|
This is the standard logic, that is now possible since ID is
allowed in BASEGEOGCRS and similar node
|
|
|
|
- Allow ID[] in base CRS of Derived CRS
- Allow VERSION[] in non-conversion coordinate operations
- Use VERSION[] to set operationVersion member of CoordinateOperation
- Export operationVersion in WKT2:2018
|
|
Normalize CMake with cmakelint, 2-space indent
|
|
#1329)
In case several coordinate operations are returned for a CRS to CRS transformation,
we currently determine the one to use by selecting the first operation whose
bounding box contains the input point.
This commit adds a fallback case where after doing that first iteration and finding
no appropriate candidate, we try again by selecting the first operation available
that does not involve grid based transformations.
|
|
|
|
|
|
|
|
|
|
transformations between geographic CRS of same datum (typically 3D to 2D)
|
|
|
|
used to know if it includes a very approximative transformation term
|
|
name we are lacking an ellipsoid height to vertCRS height correction
|
|
swap/unitconvert to avoid useless simplification rules
|
|
|
|
transformation when needed, and also sort Null geographic offset transformation in last
|
|
from X to X' in transformation name
|
|
substitution for VERTCON method
|
|
Relax tolerances in a few unit test, and in laea code.
Seen with gcc 5.3 and also 7.1
Related to the use of the 387 floating-point math, since they
disappear with gcc 7.1 if using non-default -mfpmath=sse -msse
|
|
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.
|