| Age | Commit message (Collapse) | Author |
|
Equivalent to proj_angular_input() and proj_angular_output() but
checking for degree units instead. proj_create_crs_to_crs() rarely, if
ever, returns pipelines that has radians as input or output so using
proj_angular_*() is not a useful check for io units of pipelines.
These two new functions should make life a bit easier for users that
generally store there angular coordinates in radians.
Closes #2027
|
|
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.
|
|
Saves 2 sincos() and 1 atan2() calls.
With the following bench
```
#include "proj.h"
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main(int argc, char* argv[])
{
if( argc != 2 ) {
fprintf(stderr, "Usage: bench_inv_cart fwd/inv\n");
exit(1);
}
PJ* p = proj_create(0, "+proj=cart");
const int dir = strcmp(argv[1], "inv") == 0 ? PJ_INV : PJ_FWD;
PJ_COORD coord;
if( dir == PJ_FWD )
{
coord.xyz.x = 3.14159/2;
coord.xyz.y = 3.14159/2;
coord.xyz.z = 100;
}
else
{
coord.xyz.x = 3e6;
coord.xyz.y = 3e6;
coord.xyz.z = 3e6;
}
for(int i = 0; i < 10* 1024 * 1024; i++ )
{
proj_trans(p, dir, coord);
}
proj_destroy(p);
return 0;
}
```
On Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
Time before: 2.37s
Time after: 1.57s
|
|
|
|
(refs https://github.com/OSGeo/gdal/issues/2392)
|
|
|
|
|
|
__attribute__((target_clones("fma","default"))) doesn't work for some reason
|
|
duplication
|
|
projinfo: add a --hide-ballpark option
|
|
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.
|
|
(fixes #2115)
|
|
|
|
e.g. 'WGS 84 + EGM96 height'
|
|
geographic CRS as 3D (fixes #2122)
|
|
possible (fixes #2116)
|
|
pj_phi2(): speed-up computation (and thus inverse ellipsoidal Mercator and LCC)
|
|
compoundCRS (fixes #2108)
|
|
Approximate tmerc (Snyder): speed optimizations
|
|
Extended tmerc (Poder/Engsager): speed optimizations
|
|
* 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)
|
|
equal to a ESRI alias (fixes #2099)
|
|
https://github.com/OSGeo/gdal/issues/2347)
|
|
NAD_1983_HARN_StatePlane_Colorado_North_FIPS_0501 with Foot_US unit (fixes #2086)
|
|
proj_create_crs_to_crs_from_pj()
|
|
area of use
|
|
(fixes #2012)
|
|
https://github.com/OSGeo/PROJ/pull/2065
|
|
|
|
Add proj_get_units_from_database() (fixes #2004)
|
|
|
|
|
|
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.
|
|
|
|
|
|
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)
|
|
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.
|
|
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.
|
|
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;
}
```
|
|
per line
Should hopefully result in no change in results, and hopefully more
readable code...
|
|
functional impact)
|
|
|
|
|
|
while mapping ESRI projections, and map the Behrman projection to
cae with lat_ts=30, lon_0=0
|
|
(#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.
|
|
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)
|