aboutsummaryrefslogtreecommitdiff
path: root/src/projections
AgeCommit message (Collapse)Author
2020-11-29Inverse tmerc spherical: fix wrong sign of latitude when lat_0 is used ↵Even Rouault
(fixes #2468) Corrected formula given by @evanmiller
2020-10-25Add +proj=col_urban projection, implementing a EPSG projection method used ↵Even Rouault
by a number of projected CRS in Colombia (fixes #589)
2020-10-25Fix typos spotted by scripts/fix_typos.shEven Rouault
2020-09-30Merge pull request #2361 from rouault/ortho_ellipsoidalEven Rouault
Implement ellipsoidal formulation of +proj=ortho (fixes #397)
2020-09-30ortho.cpp: more precise reference to guidance noteEven Rouault
2020-09-27tmerc: setup_exact(): do not recompute third flattening already available as ↵Even Rouault
P->n
2020-09-27Ortho ellipsoidal inverse: improve accuracy in polar case with (x,y) close ↵Even Rouault
to (0,0)
2020-09-27Ortho ellipsoidal inverse: add domain check for oblique case, and slighly ↵Even Rouault
improve initial guessing
2020-09-26Ortho ellipsoidal inverse: add non iterative implementations for polar and ↵Even Rouault
equatorial
2020-09-26Ortho: add visibility condition for ellipsoidal case. Credits to @cffkEven Rouault
2020-09-26Implement ellipsoidal formulation of +proj=ortho (fixes #397)Even Rouault
- Map ESRI 'Local' to +proj=ortho when Scale_Factor = 1 and Azimuth = 0 - Map ESRI 'Orthographic' to a PROJ WKT2 'Orthographic (Spherical)' which maps to +proj=ortho +f=0 to froce spherical evaluation
2020-08-23lcc: avoid harmless division by zero in untypical case. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24442
2020-08-19Revert compiler generated Fused Multiply Addition optimized routines (#2327)Even Rouault
Fixes #2326 Partially reverts commit b84c9d0cb61f3bd561da6092e15e294ae7e410e0 to remove the use of the gcc 6 mechanism of generated multiple versions of functions with different optimization flags, which was found to causes crashes when dlopen'ing PROJ on CentOS 7.8 with gcc 8.3.1
2020-05-28Implement wink2 inverse by generic inversion of forward methodEven Rouault
- Move the generic method initiated from adams_ws2 to a pj_generic_inverse_2d() method - Use it in adams_ws2 - Use it in wink2 Fixes https://github.com/qgis/QGIS/issues/35512
2020-05-24Merge pull request #2230 from rouault/limit_peirce_q_to_northern_hemisphereEven Rouault
Limit peirce_q to northern hemisphere, and fix images for adams_hemi, guyou and peirce_q
2020-05-19Zone Definition Fixes for igh_o projection (#2233)John Krasting
- Central lon for zone 2 should be -d10, not d10 - Extra lobe was missing for zone 11 - New figure generated - New test suite values generated
2020-05-19Implemented IGH Oceanic View (#2226)John Krasting
- The current implementation of the Interrupted Goode Homolosine projection emphasizes land area. This is a compliment projection that emphasizes ocean area. - A value of lon0=-160 produces a reasonable real-world map.
2020-05-16peirce_q: limit input to positive latitudesEven Rouault
Otherwise it returns junk (negative latitudes are mapped to the same location as positive latitudes) I'm a bit confused by PROJ peirce_q implementation. Looking at the projection of the world, it looks like this matches the diamond formulation of the right map shown at https://desktop.arcgis.com/en/arcmap/latest/map/projections/peirce-quincuncial.htm, but limited to the inner square of this diamond (which corresponds to the northern hemisphere). We lack the 4 triangles on left, top, right and bottom for the southern hemisphere. Furthermore, this formulation of peirce_q does not seem to have the quincuncial property of the square formulation (left images of the above ESRI doc), or the one at https://en.wikipedia.org/wiki/Peirce_quincuncial_projection ...
2020-05-09scripts/fix_typos.sh: fix URLs to dictionaries, and fix typos spottedEven Rouault
2020-04-21Typo fixes in code comments [ci skip]Even Rouault
2020-04-16Merge pull request #2030 from rouault/auto_sel_of_tmerc_algEven Rouault
tmerc/utm: add a +algo=auto/evenden_snyder/poder_engsager parameter
2020-04-16Implement an iterative inverse method for +proj=adams_ws2Even Rouault
2020-04-15Merge pull request #2148 from kbevers/add_adams_projectionsKristian Evers
Add square conformal projections from libproject
2020-04-15Add square conformal projections from libprojectKristian Evers
This commit adds five new projections to PROJ: adams_hemi: Adams Hemisphere in a Square adams_wsI: Adams World in a Square I adams_wsII: Adams World in a Square II guyou: Guyou peirce_q: Pierce Quincuncial The code originates from Gerry Evendens libproject and has been adapted to work with modern PROJ. To ensure that the modified code works as intended extensive test data has been created using libproject and sproj so that no errors occured when porting from libproject to PROJ. The test data is wrapped in a gie files. All test cases reproduce results from libproject at the mm level.
2020-04-15tmerc/utm: add a +algo=auto/evenden_snyder/poder_engsager parameterEven Rouault
The default remains +alg=poder_engsager. This default value can be changed in proj.ini +algo=auto will use Evenden Synder implementation if the error in doing so remains below 0.1 mm on Earth-sized ellipsoid
2020-04-14Robinson inverse projection: error on out of domain values (#2151)Martin Raspaud
2020-04-13Extended tmerc: speed-up forward path by ~5%Even Rouault
Saves a useless sqrt() call
2020-04-12sch: simplify codeEven Rouault
2020-04-12Remove old geocent.h/.cpp codeEven Rouault
Last user, apart from transform.cpp, was the SCH projection. Modify it to use cart instead. And move content of geocent.h and .cpp into transform.cpp directly, so that it can be later wiped up easily.
2020-04-06autoconf build: fix build on Alpine 3.11 where ↵Even Rouault
__attribute__((target_clones("fma","default"))) doesn't work for some reason
2020-04-06Move inline code for optimize mlfn from tmerc to mlfn.hpp to avoid code ↵Even Rouault
duplication
2020-03-29Merge pull request #2039 from rouault/speedup_snyder_tmercEven Rouault
Approximate tmerc (Snyder): speed optimizations
2020-03-29Merge pull request #2036 from rouault/speedup_poder_engsager_tmercEven Rouault
Extended tmerc (Poder/Engsager): speed optimizations
2020-03-10utm/ups: make sure to set errno to PJD_ERR_ELLIPSOID_USE_REQUIRED if es==0Even Rouault
ENOMEM was wrongly set after setting PJD_ERR_ELLIPSOID_USE_REQUIRED Note: it is a bit strange to forbid the pure spherical case whereas the maths would allow it. I presume this is due to the typical usage of those methods.
2020-03-09Approximate tmerc (Snyder): speed optimizationsEven Rouault
fwd: 7% faster on Core-i7@2.6GHz (with FMA triggered), 22% faster on GCE Xeon@2GHz (with FMA) inv: 31% faster on Core-i7@2.6GHz (with FMA triggered), 60% faster on GCE Xeon@2GHz (with FMA) The optimizations consists in different things: - optionaly use the FMA (Fused Multiply Addition) instruction set with gcc >= 6. Binaries are generated with the standard instruction set (SSE/SSE2), and with one variant with FMA, and the appropriate version is selected automatically at runtime. This gives a modest speedup, but measurable. The speedup is more obvious on lower clocked CPU. - inline mlfn and inv_mlfn - for inv_mlfn avoid recomputation of sin()/cos() at each iteration stage, by observing that the argument changes in modest way at each iteration, and using approximation of sin()/cos(). The differences due to that approximation are way below the 1e-11 tolerance threshold. Different in results are neglectable (only found in areas where the approximations of the Snyder formulas are already no longer valid) Before: $ echo 8e5 9e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx 799997.896522093331 8999999.520601103082 $ echo 8e5 5e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx 800000.000007762224 4999999.999971268699 $ echo 18e5 9e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx 1079182.990696100984 8661150.574729491025 $ echo 18e5 5e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx 1799997.510861013783 4999999.567328464240 After: $ echo 8e5 9e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx 799997.896522093331 8999999.520601103082 $ echo 8e5 5e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx 800000.000007762224 4999999.999971268699 $ echo 18e5 9e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx 1079182.990696124267 8661150.574729502201 $ echo 18e5 5e6 | src/proj -d 12 +proj=utm +zone=31 -I +approx | src/proj -d 12 +proj=utm +zone=31 +approx 1799997.510861013783 4999999.567328464240
2020-03-09Extended tmerc (Poder/Engsager): speed optimizationsEven Rouault
fwd: 52% faster on Core-i7@2.6GHz, 40% faster on GCE Xeon@2GHz inv: 24% faster on Core-i7@2.6GHz, 36% faster on GCE Xeon@2GHz Those speed-ups are obtained due to elimination of a number of transcendental functions (atan, sincos, cosh, sinh), through the use of usual trigonometric/hyperbolic formulas. The numeric results before/after seem identical at worse up to 14 decimal digits, which is way beyond the apparent accuracy of the computations On a point, far from central meridian, where round-tripping is not so great: Before: echo "81 1" | src/proj -d 18 +proj=utm +zone=31 | src/proj -d 18 -I +proj=utm +zone=31 80.999994286593448578 0.999987970918421620 After: $ echo "81 1" | src/proj -d 18 +proj=utm +zone=31 | src/proj -d 18 -I +proj=utm +zone=31 80.999994286593448578 0.999987970918422175 The benchmarking program used is: ``` #include "proj.h" #include <stdlib.h> #include <stdio.h> #include <string.h> int main(int argc, char* argv[]) { if( argc != 3 ) { fprintf(stderr, "Usage: bench quoted_proj_string fwd/inv\n"); exit(1); } PJ* p = proj_create(0, argv[1]); const int dir = strcmp(argv[2], "inv") == 0 ? PJ_INV : PJ_FWD; PJ_COORD coord; if( dir == PJ_FWD ) { coord.xy.x = 0.5; // rad coord.xy.y = 0.5; // rad } else { coord.xy.x = 450000; // m coord.xy.y = 5000000; // m } for(int i = 0; i < 40 * 1000* 1000; i++) proj_trans(p, dir, coord); proj_destroy(p); return 0; } ```
2020-03-08src/projections/: remove assignments in expression and multiple statements ↵Even Rouault
per line Should hopefully result in no change in results, and hopefully more readable code...
2020-03-02Fix bad copy&replace pattern on HEALPix and rHEALPix projection names. ↵Even Rouault
Affects output of 'proj -l'
2020-02-27Fix warnings of latest cppcheck masterEven Rouault
2020-02-08Add comments to vandg.cpp to tie implementation to Snyder (1987).Charles Karney
2020-02-08Merge pull request #1917 from rouault/fix_test_issues_on_i386Kristian Evers
Fix test issues on i386
2020-02-07Fix numerical precision issues in vandg and robinEven Rouault
Refs #1906 Fix remaining issues of https://github.com/OSGeo/PROJ/issues/1906#issuecomment-583168348 as found with gcc 8.2.0 -m32 -O2
2020-02-07Fix test issues on i386Even Rouault
Fix a few issues of #1906 found when running the test suite on Ubuntu 16.04 with gcc 5.5 -m32. When applied on top of the fix of #1912, make check succeeds
2020-02-06Fix cppcheck warnings and make it work with latest cppcheck 1.90Even Rouault
2019-10-28Various fixes/workarounds to make cppcheck 1.72 (Ubuntu 16.04) and ↵Even Rouault
HEAD/1.90dev happy (fixes #1648)
2019-10-13Merge pull request #1653 from rouault/doc_ob_tranEven Rouault
ob_tran doc: fix/clarify semantics of o_lat_p/o_lon_p
2019-10-03aeqd: for spherical forward path, go to higher precision ellipsoidal case ↵Even Rouault
when the point coordinates are super close to the origin (fixes #1654)
2019-10-03ob_tran.cpp: add comment to link maths with Snyder's formulasEven Rouault
2019-10-02nsper: add a comment to relate it to EPSG Vertical PerspectiveEven Rouault
2019-10-01Add rotation support to the HEALPix projection (#1638)Simon Schneegans
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-12 03:56:42 +0000