aboutsummaryrefslogtreecommitdiff
path: root/src/projections
AgeCommit message (Collapse)Author
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
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.
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-15 19:41:45 +0000