| Age | Commit message (Collapse) | Author |
|---|
|
https://github.com/OSGeo/PROJ/issues/2032 (#2037)
|
|
Map ESRI Transverse_Mercator_Complex to Transverse Mercator
|
|
According to https://gis.stackexchange.com/questions/226679/complex-utm-projection
it is highly likely that Transverse_Mercator_Complex corresponds to our
extended/enhanced/Poder-Engsager transverse mercator method (etmerc), or something
similarly precise. So we can map that to the standard Transverse Mercator
method, since etmerc is used for it.
|
|
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
|
|
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;
}
```
|
|
Updated appveyor to not copy DLL & update existing vcpkg
|
|
rouault/projections_remove_assignments_in_expressions
src/projections/: remove assignments in expression and multiple statements per line
|
|
|
|
per line
Should hopefully result in no change in results, and hopefully more
readable code...
|
|
functional impact)
|
|
|
|
|
|
WKT import/export: add support for WKT1_ESRI VERTCS syntax
|
|
|
|
Add some more missing methods and notes to esri projection mapping
|
|
|
|
Transverse_Cylindrical_Equal_Area projections (#2020)
* Add mapping of ESRI projection methods Mercator_Variant_A, Mercator_Variant_C
and Transverse_Cylindrical_Equal_Area
* Add a few notes about missing mappings
|
|
+no_defs and +datum has no effect on the behaviour of proj, so can be
left out in these examples in the docs. +no_defs in rare occasions would
have had an effect in older PROJ versions but not from PROJ 6 and
onwards. +datum has ever only been honoured by cs2cs and pj_transform().
Fixes #2017
|
|
Map the Behrman projection to cae when converting ESRI CRSes
|
|
|
|
while mapping ESRI projections, and map the Behrman projection to
cae with lat_ts=30, lon_0=0
|
|
|
|
Removes section about proj-datumgrid-* packages in favour for a section
about the PROJ-data package and the CDN.
|
|
(#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.
|
|
Follow PDAL's CMake RPATH strategy
|
|
|
|
|
|
|
|
Affects output of 'proj -l'
|
|
|
|
|
|
|
|
+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.
|
|
-DSQLITE_OMIT_AUTOINIT (fixes #1932) (#1997)
|
|
|
|
|
|
|
|
Fixes #1984
- Copy BETA2007.gsb, MD, alaska, conus, ntf_r93.gsb, ntv1_can.dat grids
from proj-datumgrid to data/tests.
- Replace a couple uses of nzgd2kgrid0005.gsb in tests by ntf_r93.gsb
- Add downsampled/subsetted versions of egm96_15.gtx as tests/egm96_15_downsampled.gtx
and ntv2_0.gsb as tests/ntv2_0_downsampled.gsb
This results in a few changes in expected results
- Simpify travis/install.sh due to less configurations to test
This results in a hopefully acceptable increase of the proj-X.Y.Z.tar.gz
from 2.9 to 5.3 MB
|
|
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.
|
|
Database: register 4 height Austrian grids from https://github.com/OSGeo/PROJ-data/pull/13 + handle 'Vertical Offset by Grid Interpolation (BEV AT)' method
|
|
Support conversion of Flat_Polar_Quartic projection method
|
|
https://github.com/OSGeo/PROJ-data/pull/13 + handle 'Vertical Offset by Grid Interpolation (BEV AT)' method
|
|
|
|
|
|
createOperations(): be robust to a GeographicCRS having a wrong ID attached to it (fixes #1982)
|
|
to it (fixes #1982)
|
|
19111
|
|
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.
|
|
(refs #1973)
|
|
|
