aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2020-04-04Merge pull request #2127 from rouault/projinfo_hide_ballparkEven Rouault
projinfo: add a --hide-ballpark option
2020-04-04hgridshift/vgridshift: defer grid opening when grid has already been openedEven Rouault
Relates to #2115 With the fix of https://github.com/OSGeo/PROJ/pull/2128, transforming between EPSG:4326+3855 and EPSG:4269+5703 leads to many operations with many grids, and opening a file handle for each operation saturates the limit of 1024 file handles opened simunalteously. This fix defers grid opening when a transformation has already been instanciated with the same grid.
2020-04-04createOperations(): improve results of compoundCRS to compoundCRS case ↵Even Rouault
(fixes #2115)
2020-04-04projinfo: add a --hide-ballpark optionEven Rouault
2020-04-03createFromUserInput(): allow compound CRS with the 2 parts given by names, ↵Even Rouault
e.g. 'WGS 84 + EGM96 height'
2020-04-03Make sure that importing a Projected 3D CRS from WKT:2019 keeps the base ↵Even Rouault
geographic CRS as 3D (fixes #2122)
2020-03-30ESRI_WKT ingestion: make sure to identify to non-deprecated EPSG entry when ↵Even Rouault
possible (fixes #2116)
2020-03-30Merge pull request #2052 from rouault/speedup_phi2Even Rouault
pj_phi2(): speed-up computation (and thus inverse ellipsoidal Mercator and LCC)
2020-03-30Fix working of Helmert transform between the horizontal part of 2 ↵Even Rouault
compoundCRS (fixes #2108)
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-28CMake: prefer to use use PROJ_SOURCE_DIR and PROJ_BINARY_DIR (#2100)Mike Taves
* Use instead of CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR * Also PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR, which are similar * Set properties with a list variable rather than a long line * Correction to 'proj_test_set_properties' function, rename ENVIRONMENT: - PROJ_IGNORE_USER_WRITABLE_DIRECTORY (ignored) - PROJ_SKIP_READ_USER_WRITABLE_DIRECTORY (used by filemanager.cpp)
2020-03-27Fix identification of projected CRS whose name is close but not strictly ↵Even Rouault
equal to a ESRI alias (fixes #2099)
2020-03-25EngineeringCRS: when exporting to WKT1_GDAL, output unit and axis (fixes ↵Even Rouault
https://github.com/OSGeo/gdal/issues/2347)
2020-03-24ESRI WKT import / identification: special case for ↵Even Rouault
NAD_1983_HARN_StatePlane_Colorado_North_FIPS_0501 with Foot_US unit (fixes #2086)
2020-03-23proj_get_suggested_operation(): extra fix to behave similarly to ↵Even Rouault
proj_create_crs_to_crs_from_pj()
2020-03-19proj_get_suggested_operation(): fix when there are only operations without ↵Even Rouault
area of use
2020-03-18cs2cs: don't require +to for '{source_crs} {target_crs} filename...' syntax ↵Even Rouault
(fixes #2012)
2020-03-17Deprecate proj_list_angular_units(). Follow-up of ↵Even Rouault
https://github.com/OSGeo/PROJ/pull/2065
2020-03-16Merge branch 'master' into add_proj_get_suggested_operationEven Rouault
2020-03-16Merge pull request #2065 from rouault/add_proj_get_units_from_databaseEven Rouault
Add proj_get_units_from_database() (fixes #2004)
2020-03-15Fix build with libtiff master (libtiff > 4.1.0)Even Rouault
2020-03-13Tag proj_list_units() as deprecatedEven Rouault
2020-03-13Add proj_get_suggested_operation()Even Rouault
Return the index of the operation that would be the most appropriate to transform the specified coordinates. This operation may use resources that are not locally available, depending on the search criteria used by proj_create_operations(). This could be done by using proj_create_operations() with a punctual bounding box, but this function is faster when one needs to evaluate on many points with the same (source_crs, target_crs) tuple.
2020-03-12Add proj_get_units_from_database() (fixes #2004)Even Rouault
2020-03-12Fix build with gcc 4.8.5 (fixes #2062)Even Rouault
2020-03-11ProjectedCRS::identify(): tune it to better work with ESRI WKT ↵Even Rouault
representation of EPSG:2193 Adresses https://github.com/OSGeo/gdal/issues/2303 by raising the identification confidence from 25% to 90% (90% means equivalent for all purposes, but name not strictly the EPSG official one)
2020-03-11pj_phi2(): speed-up computation (and thus inverse ellipsoidal Mercator and LCC)Even Rouault
This does not change the numeric values returned by the method, as far as I could see on a few samplings. The tricks used save a call to sin() and atan() at each iteration. This directly affects speed of inverse Mercator and LCC (among others), in their ellipsoidal formulation. Timings on inverse Mercator show a 31% speed-up at mid-latitudes where pj_phi2() needs 5 iterations, and 24% at latitudes close to 0 or 90deg where it needs one iteration.
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)
generated by cgit v1.2.3 (git 2.25.1) at 2026-03-06 19:49:10 +0000