aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
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-06proj_internal.h: fix typo in macro name due to bad copy&paste. (No ↵Even Rouault
functional impact)
2020-03-06Typo fixes identified by scripts/fix_typos.shEven Rouault
2020-03-06WKT import/export: add support for WKT1_ESRI VERTCS syntaxEven Rouault
2020-03-04Add capability to force a fixed value for a non-specified CRS componentNyall Dawson
while mapping ESRI projections, and map the Behrman projection to cae with lat_ts=30, lon_0=0
2020-03-03createUnitOfMeasure(): use full double resolution for the conversion factor ↵Even Rouault
(#2011) Fixes https://github.com/OSGeo/gdal/issues/2290 where it was found that PROJ returned value for conversion factor of US Survey Foot unit wasn't at the maximum resolution, but only accurate to 15 significant digits.
2020-03-02Fix bad copy&replace pattern on HEALPix and rHEALPix projection names. ↵Even Rouault
Affects output of 'proj -l'
2020-03-01Bump version numbers in preparation for 7.1.0Kristian Evers
2020-02-29createOperations(): fix wrong pipeline generation with CRS that has ↵Even Rouault
+nadgrids= and +pm= (#1998) Fixes issue reported at https://lists.osgeo.org/pipermail/gdal-dev/2020-February/051749.html The generated pipeline assumes that the input coordinates for the grid transformation were related to the non-Greenwich based datum, so we must compensate for that and add logic to go back to Greenwich.
2020-02-28Avoid crash when running against SQLite3 binary built with ↵Even Rouault
-DSQLITE_OMIT_AUTOINIT (fixes #1932) (#1997)
2020-02-27Fix warnings of latest cppcheck masterEven Rouault
2020-02-27proj_create_crs_to_crs(): avoid potential reprojection failures when ↵Even Rouault
reprojecting area of use to source and target CRS Was found with https://github.com/OSGeo/PROJ/pull/1989 when using cs2cs EPSG:4937 EPSG:31258+5778 - We do not need to do vertical transformation in that context. This failed here because the Austrian grids have nodata value outside of the shape of Austria, so the edges of the grids are mostly nodata values. - And we should avoid grid-based transformations too.
2020-02-27Merge pull request #1989 from rouault/register_austrian_height_gridsEven Rouault
Database: register 4 height Austrian grids from https://github.com/OSGeo/PROJ-data/pull/13 + handle 'Vertical Offset by Grid Interpolation (BEV AT)' method
2020-02-26Database: register 4 height Austrian grids from ↵Even Rouault
https://github.com/OSGeo/PROJ-data/pull/13 + handle 'Vertical Offset by Grid Interpolation (BEV AT)' method
2020-02-26Support conversion of Flat_Polar_Quartic projection methodNyall Dawson
2020-02-25createOperations(): be robust to a GeographicCRS having a wrong ID attached ↵Even Rouault
to it (fixes #1982)
2020-02-25CompoundCRS::create(): reject combinations of components not allowed by ISO ↵Even Rouault
19111
2020-02-24createOperations(): keep height/z value in Helmert transform between 3D CRSEven Rouault
This is the consequence of a private email thread between me, Joel Haasdyk and Roger Lott. I initially raised that the GDA2020 technical manual advertized the Helmert transformation between GDA94 to GDA2020 to be a 3D one, with example of a test point where ellipsoidal heights where modified. It appears this was intended. The corresponding record in EPSG uses the EPSG:9607 "Coordinate Frame rotation (geog2D domain)" method between the 2D geographic CRS of GDA94 and GDA2020. From the email exchange, it appears that there's a lot of legacy explaining that Helmert transformations are registered only between 2D CRS, which doesn't mean that when applied to the corresponding 3D CRS, the change in ellipsoidal height should be discarded. Related to that, the EPSG database, while it has methods flagged "(geog3D domain)" never uses them. So... this changeset slightly ammends PROJ behaviour to ignore the "(geog2D domain)" flag, but only consider the dimensionality of the source & target CRS. However, for a EPSG transformation, those are always 2D CRS, hence introduce the use3DHelmert_ hack when we know that ultimately the 'real' source & target CRS are 3D. I wouldn't be surprised if in more complex pipeline the above logic would be lacking. But it fixes at least simple transformations.
2020-02-24pj_hgrid_apply(): change error code when no grid match to PJD_ERR_GRID_AREA ↵Even Rouault
(refs #1973)
2020-02-24Fix mapping of Vertical_Near_Side_Perspective (fixes #1965)Nyall Dawson
2020-02-24Expose proj_context_is_network_enabled() in C APIEven Rouault
2020-02-22Merge pull request #1962 from mwtoews/sharedMike Taves
CMake: rename BUILD_LIBPROJ_SHARED to BUILD_SHARED_LIBS
2020-02-21Add support for creating coordinates operations using Compact Miller,Nyall Dawson
Times and Vertical Near Side Perspective projections
2020-02-21Add support for creating coordinates operations using Natural Earth/Natural ↵Nyall Dawson
Earth 2 projection
2020-02-21Add support for creating coordinates operations using ESRI:53079 (patterson) CRSNyall Dawson
2020-02-21Switch build configuration logic from DISABLE_TIFF to ENABLE_TIFFMike Taves
* Autotools interface should be the same, but different ./configure --help * For CMake, the option should be -DENABLE_TIFF=NO (default is YES) * Use TIFF_ENABLED and CURL_ENABLED variables, based on option and outcome * Reword some messages and add hints * Move -DTIFF_ENABLED and -DCURL_ENABLED from global add_definitions() to target_compile_definitions(), which is recommended practice * Minor spelling and style consistency around SQLITE_VERSION check
2020-02-21CMake: rename BUILD_LIBPROJ_SHARED to BUILD_SHARED_LIBSMike Taves
* Deprecate BUILD_LIBPROJ_SHARED, but still use it as an alias for now * Rename BUILD_LIBPROJ_SHARED_DEFAULT to BUILD_SHARED_LIBS_DEFAULT * Keep previous defaults (UNIX as shared and Windows as static) * Remove PROJ_LIBRARY_TYPE, since add_library() uses BUILD_SHARED_LIBS
2020-02-20Fix wrong byte-swapping for NTv2 grids affecting master after RFC4 work ↵Even Rouault
(fixes #1938) And add testing of both little-endian and big-endian NTv2 files
2020-02-20CMake: rename ENABLE_LTO to ENABLE_IPOMike Taves
* Deprecate ENABLE_LTO, but still use it as an alias for now * Plan to remove ENABLE_LTO by PROJ 8.0 * Use CMake 3.9 logic to check feature and set property
2020-02-19validateParameters(): fix false-positive warning on Equidistant CylindricalEven Rouault
We required the 'Latitude of natural origin' parameter to be present, but it is only a GDAL/PROJ specific thing, not a EPSG one.
2020-02-19DatabaseContext::lookForGridInfo(): use also old_proj_grid_name for lookups ↵Even Rouault
(fixes #1942)
2020-02-18Don't assume $HOME to be writable.Bas Couwenberg
The read_grid_from_user_writable_directory test fails otherwise. Fixes: #1933
2020-02-17Update ABI version numbers for 7.0.0 releaseKristian Evers
2020-02-12Merge pull request #1923 from mwtoews/cmake-outputKristian Evers
CMake: simplify message functions
2020-02-11Use relative directory to locate PROJ resource files.Even Rouault
Fixes #1490 This is an extension of the Window-specific logic added recently to Unix builds. This reuses parts of proposed past commit https://github.com/OSGeo/PROJ/pull/1517/commits/82a07e51c6e24ddb936d131ababe29f1ac36ef14 (credits to @abellgithub)
2020-02-11CMake: simplify message functionsMike Taves
* Remove colormsg(); just use message() * Rename boost_report_value() with print_variable()
2020-02-10PROJStringParser::Private::buildProjectedCRS(): avoid (harmless) division by ↵Even Rouault
zero in super odd case with corrupted PROJ string. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20624
2020-02-09read_vgrid_value(): avoid assertion on huge latitude. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20592. master only
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-07Merge pull request #1918 from rouault/update_travis_csaEven Rouault
Travis: update CLang Static Analyzer to CLang 9
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
2020-02-06Travis: update CLang Static Analyzer to CLang 9Even Rouault
Enable optional checkers Fix two false positives
2020-02-06cart: Avoid discontinuity at poles in the inverse caseKristian Evers
This should avoid issues with numerical stability as uncovered in https://github.com/OSGeo/PROJ/issues/1906. Practically speaking this change isn't going to affect real life scenarios since the position of the center of the Earth is rarely expressed in geodetic coordinates.
2020-02-06Merge pull request #1915 from rouault/fix_1911Even Rouault
Fix identification of ESRI-style datum names starting with D_ but without alias
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-01 02:40:21 +0000