aboutsummaryrefslogtreecommitdiff
path: root/src/projections
AgeCommit message (Collapse)Author
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
2019-09-25isea: avoid shadowing warning on 'quad' on SolarisEven Rouault
Patch proj-6.2.0-isea.gpatch by Eric Dechaux
2019-09-25hatano/mbtfpp: do not use CS to fix Solaris build issueEven Rouault
Patches proj-6.2.0-hanato.gpatch and proj-6.2.0-mbtfpp.gpatch from Eric Dechaux
2019-09-19Merge pull request #1618 from cffk/c99-math-updateCharles Karney
Remove unneeded C99 compatibility functions from math.cpp and proj_math.h I'll do the clean up of the -std=c89 flags etc. as a separate pull request.
2019-09-18Delete proj_math.h. Replace includes by <math.h>; we'll see if anyoneCharles Karney
needs <limits.h>. Update scripts/reference_exported_symbols.txt and src/proj_symbol_rename.h.
2019-09-17aea_e_inverse(): avoid calling asin() with invalid argument which results in ↵Even Rouault
NaN being propagated. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15336
2019-09-17isea: avoid undefined behaviour on left shift of negative value. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15009
2019-09-17geos: avoid division by zero. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14666
2019-09-17eqdc: avoid potential division by zero. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17190
2019-09-03Debug Bertin1953R. Schmunk
Northern hemisphere "warp" implemented incorrectly. See #1579
2019-06-25geos.cpp: Update pdf_cgms_03.pdf location (Fixes #1532)Kurt Schwehr
2019-06-22+proj=ob_tran +o_proj=longlat: set right unit to PJ_IO_UNITS_WHATEVER so as ↵Even Rouault
to be able to chain with unitconvert (fixes #1525)
2019-05-05geos: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14602 Credit to OSS Fuzz
2019-05-02lagrng: avoid division by zero when latitude is very close to 90Even Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14477 Credit to OSS Fuzz
2019-04-26Prefix inverse and forward functions by their projection namesEven Rouault
This is mostly to have better OSSFuzz report. Currently a lot of bug summaries are like `proj4/standard_fuzzer: Divide-by-zero in s_inverse` By prefixing the projection name, we will get better reports, like `Divide-by-zero in airy_s_inverse` This also makes it slightly easier to set a breakpoint by function name.
2019-04-26aitof: fix division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14447 Credit to OSS Fuzz
2019-04-26aitoff.cpp: fix indentationEven Rouault
2019-04-25gs50 and other mod_ster projections: avoid divison by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14421 Credit to OSS Fuzz
2019-04-22airy: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14410 Credit to OSS Fuzz
2019-04-20omerc: validate lat_1 and lat_2 to avoid divison by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14384 Credit to OSS Fuzz
2019-04-18tpers: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14342 Credit to OSS Fuzz
2019-04-18isea: avoid invalid integer shiftEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14286 Credit to OSS Fuzz
2019-04-16omerc: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14279 Credit to OSS Fuzz
2019-04-14lcc: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14250 Credit to OSS Fuzz
2019-04-14imw_p: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14248 Credit to OSS Fuzz
2019-04-12Validate lat_0 range in general case, lat_1 and lat_2 for lcc and eqdcEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14211 Credit to OSS Fuzz
2019-04-11omerc: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14138 Credit to OSS Fuzz
2019-04-11omerc: avoid division by zero when |lat_0|=90Even Rouault
Partially revert e3346bb39c860883ed9a8ada0657139118e21ef0 (#195) Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14136 Credit to OSS Fuzz
2019-04-10lsat: avoid division by zero in inverseEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14135 Credit to OSS Fuzz
2019-04-05imw_p: avoid division by zero in inverseEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14062 Credit to OSS Fuzz
2019-04-05krovak: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14061 Credit to OSS Fuzz
2019-04-05lcc: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14058 Credit to OSS Fuzz