| Age | Commit message (Collapse) | Author |
|
|
|
This fixes the current forward implementation of Peirce Quincuncial proj to correctly flip/reflect out the southern hemisphere to four triangles, and rotate entire result to a square or diamond. (It there resolves the issues identified with pull request https://github.com/OSGeo/PROJ/pull/2230 , where southern hemisphere was wrongly projected over northern, and reverses the restriction to northern hemisphere introduced there). It also adds additional lateral projection of the hemispheres.
- This PR adds an optional parameter `+type` which allows selection of projection. The `+type=square` and `+type=diamond` types match in principle ESRI's twin implementations of square and diamond PQ projs. The **default** if not specified is `+type=diamond`.
- The previous behaviour restricted to the northern hemisphere can be reproduced using the `+type=nhemisphere`, though this is an edge case only.
- An additional `+type=horizontal` and `+type=vertical` rectangular lateral versions have been added that place each hemisphere side-by-side. This is primarily to allow creation of projections such as Greiger Triptychial, which also require the additional optional params `scrollx` or `scrolly` in order to shift parts of the projection from one side of the map to the other.
- Additional documentation has been added to proj description, including quoting the usual meridian used in common usage of projection, and images showing the different types.
|
|
WKT1 import: correctly deal with missing rectified_grid_angle parameter
|
|
createOperations(): improvement for "NAD83(CSRS) + CGVD28 height" to "NAD83(CSRS) + CGVD2013(CGG2013) height"
|
|
Cache result of proj_get_type() to help for performance of proj_factors() (fixes #2965)
|
|
Co-authored-by: Rohit <rohitpingale103@gmail.com>
Co-authored-by: Brendan Jurd <brendan.jurd@geoplex.com.au>
Co-authored-by: Mike Taves <mwtoews@gmail.com>
|
|
DOCS: Add doxygen entry for proj_context_set_search_paths.
|
|
division by zero. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41045
|
|
[Backport 8.2] createOperationsCompoundToCompound(): fix null pointer dereference when connection to proj.db doesn't exist.
|
|
createOperationsCompoundToCompound(): fix null pointer dereference when connection to proj.db doesn't exist.
|
|
createOperations(): do not stop at the first operation in the PROJ namespace for vertical transformations
|
|
PROJStringFormatter::toString(): avoid invalid iterator increment (fixes #2931)
|
|
[Backport 8.2] DOC: Add warning in proj_as_proj_string about potential information loss with CRS
|
|
DOC: Add warning in proj_as_proj_string about potential information loss with CRS
|
|
DOC: add available keys to proj_context_get_database_metadata
|
|
Database: update to EPSG v10.039
|
|
BoundCRS WKT import: fix setting of name
|
|
|
|
lib_proj.cmake: add a PROJ::proj alias and add BUILD_INTERFACE include directories...
|
|
directories, so that proj can be used as a subdirectory of a larger project (fixes #2905)
|
|
- Remove the explicit PROJ_MSVC_DLL_IMPORT symbol used for importing
symbols from a MSVC .dll: by default on MSVC, we use
now __declspec(dllimport), unless PROJ_MSVC_DLL_EXPORT is defined
by PROJ at build time. This makes it easier for users: they
don't have to define anything special. This simplifies in particular
the build of our binaries
- For static builds, export -DPROJ_DLL= as public, so that users
that import PROJ through CMake mechanism don't have to do it
manually.
|
|
add fallback strategy for tinshift transform to use closest triangle for points not in any
|
|
- this bumps format_version of tinshift JSON to 1.1 for the new field
fallback_strategy
- the default behaviour without that field is retained
- if fallback_strategy is set to "nearest_side", then points that do not fall
into any of the triangles will be transformed according to the nearest
triangle
- if fallback_centroid is set to "nearest_side", then points that do not fall
into any of the triangles will be transformed according to the triangle
with the nearest centroid
|
|
|
|
if conversion factor is 0. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40050
|
|
conversion factor of target unit is 0. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39969
|
|
|
|
explicit configuration
|
|
(and thus extrapolating a VERTCS) (fixes #2757)
|
|
EPSG equivalent and have parentheses in their name
|
|
CMake build: generate invproj/invgeod binaries (symlinks on Unix, copy otherwise) (fixes #2852)
|
|
CMake build: add generate_wkt1_parser and generate_wkt2_parser manual target, and logic to detect when they must be run
|
|
CMake: add a BUILD_APPS to be able to disable build of all applications
|
|
target, and logic to detect when they must be run
|
|
Co-authored-by: Even Rouault <even.rouault@spatialys.com>
|
|
358434, 358435)
|
|
This makes it easier to turn off all programs, rather than individually.
Useful for example to avoid https://github.com/OSGeo/gdal/blob/master/gdal/fuzzers/build.sh#L138
|
|
|
|
Due to libtool wrapper scripts, it is easier to build fully fledged
binaries.
The installed binaries will be symlinks, as before.
|
|
otherwise) (fixes #2852)
|
|
1SP or 2SP (fixes #2892)
|
|
conversion is the first or last operation (fixes #2890)
|
|
|
|
(fixes #2886)
|
|
EQUIVALENT mode if one of them is lacking an explicit CS order (refs #2886)
|
|
meridian is involved
This fixes a regression introduced in 7af1d5741da08d9546b907e0da2c21c54c61b27 / PROJ 7.2.0
where reprojection of area of use was broken when the source/target CRS
did not use Greenwich as prime meridian.
Fixes https://lists.osgeo.org/pipermail/gdal-dev/2021-October/054764.html
Now with the fix:
- using grid:
$ echo 286415 431434 | PROJ_NETWORK=ON src/cs2cs -d 4 EPSG:20790 EPSG:3763
86412.4262 131434.1706 0.0000
- not using it:
$ echo 286415 431434 | src/cs2cs -d 4 EPSG:20790 EPSG:3763
86412.5265 131433.8561 0.0000
|
|
transformation (#2882)
Fixes #2779
|
|
Add IAU_2015 CRS definitions
|
|
proj_factors(): accept P to be a projected CRS (fixes #2854)
|
|
Updated doc:
Starting with PROJ 8.2, the P object can be a projected CRS, for example
instantiated from a EPSG CRS code. The factors computed will be those of the
map projection implied by the transformation from the base geographic CRS of
the projected CRS to the projected CRS.
The input geodetic coordinate lp should be such that lp.lam is the longitude
in radian, and lp.phi the latitude in radian (thus independently of the
definition of the base CRS, if P is a projected CRS).
|