| Age | Commit message (Collapse) | Author |
|
|
|
|
|
specializations of cea
Shared credits with @pramsey / PR #3063
|
|
|
|
Cf thread https://lists.osgeo.org/pipermail/gdal-dev/2022-February/thread.html#55391
|
|
|
|
|
|
|
|
Doc: clarify build requirements
|
|
|
|
|
|
|
|
|
|
(fixes #3011)
|
|
|
|
Transition Clang Static Analizer to use CMake
|
|
|
|
downloadable at that URL)
|
|
(fixes #2999)
|
|
|
|
|
|
update "Edit on GitHub" button branch
|
|
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.
|
|
I also removed the leading slash, since I noticed the links contained a double slash. That worked fine, but still.
(cherry picked from commit 80e32d55d076fa48f753d5014cf828d85a0d1bce)
|
|
|
|
|
|
|
|
|
|
CMake: add option USE_CCACHE=OFF to use ccache to compile C/C++ objs
|
|
|
|
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>
|
|
|
|
Refs #2540.
|
|
transformation operations (#2914)
Fixes #2512
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 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
|
|
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
|
|
transformation (#2882)
Fixes #2779
|
|
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).
|
|
|
|
DOC: Add content for Development/Error handling page.
|
|
* DOC: Refresh Development/Quickstart and remove Development/Threads
The document Development/Threads was severely out of date, and was
focussed on contrasting the current API with an old API that was
deprecated several years ago, and removed from the current PROJ earlier
this year.
Update Development/Quickstart to give more information about the use of
threading context, as a replacement for the content that was previously
in Threads.
Also give the example code examples/pj_obs_api_mini_demo.c a cleanup
pass to make it at least internally consistent with its own code style.
The header comments of the example code are still, much like the Threads
document, fixated on comparing proj.h against proj_api.h, which is an
interesting historical curio to be sure, but probably doesn't need to
persist here. It might be worth cleaning this up further as a separate
exercise.
Fixes #2451
|