| Age | Commit message (Collapse) | Author |
|---|
|
deformation models
Fixes #1001
Co-authored-by: Chris Crook <ccrook@linz.govt.nz>
|
|
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 ...
|
|
|
|
In that mode:
* All non-comment/decoration lines must start with a valid tag
* Commands split on several lines should be terminated with " \"
|
|
tmerc/utm: add a +algo=auto/evenden_snyder/poder_engsager parameter
|
|
|
|
Add square conformal projections from libproject
|
|
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.
|
|
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
|
|
|
|
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
|
|
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.
|
|
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
|
|
(fixes #1938)
And add testing of both little-endian and big-endian NTv2 files
|
|
Fix test issues on i386
|
|
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
|
|
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.
|
|
Fixes #1846
|
|
|
|
This commit is the result of the squashing of rfc4_dev branch in a single
commit. It implements mostly RFC 4 related work.
* Grid handling:
- remove obsolete and presumably unfinished implementation of grid catalog functionality
- all grid functionality is in grids.cpp/.hpp
- vertical and horizontal grid shift: rework to no longer load whole grid into memory
- remove hgrids and vgrids member from PJ structure, and store them in hgridshift/vgridshift/deformation structures
- build systems: add optional libtiff dependency. Must be explicitly disabled if not desired
- add support for horizontal and vertical grids in GeoTIFF, if libtiff is available
- add GenericShiftGridSet and GenericShiftGrid classes, relying on TIFF grids, that can be used for generic purpose grid-based adjustment
- add a +proj=xyzgridshift method to perform geocentric translation by grid. Used for French NTF to RGF93 transformation using gr3df97a.tif grid
- deformation: add support for +grids= for GeoTIFF grids
- horizontal grid shift: fix failures on points slightly outside a subgrid (fixes #209)
* File management:
- add a filemanager.cpp/.hpp to deal with file related work
- test for legacy proj_api.h fileapi
- proj.h: add proj_context_set_fileapi() and proj_context_set_sqlite3_vfs_name() (fixes #866)
- add capability to read resource files from the user writable directory
* Network access:
- build systems: add optional curl dependency
- add a curl-based default implementation for network related functionality
- proj.h: add C API to control network functionality, and optionaly provide network callbacks
- add data/proj.ini with default settings
- add a SQLite3 local cache of downloaded chunks
- add proj_is_download_needed() and proj_download_file()
* Use Win32 Unicode APIs and expect all strings to be UTF-8 (fixes #1765)
For backward compatibility, if PROJ_LIB content is found to be not UTF-8 or
pointing to a non existing directory, then an attempt at interpretating it
in the ANSI page encoding is done.
proj_context_set_search_paths() now assumes strings to be in UTF-8, and
functions returning paths will also return values in UTF-8.
|
|
Should fix the issue reported in https://lists.osgeo.org/pipermail/proj/2020-January/009188.html
Some extra north-american grids present in data/ can affect the results of
some tests, so create a data/for_tests/ subdirectory in which we copy only
select grids.
|
|
Inspired from syntax of https://github.com/OSGeo/PROJ/pull/453/files
but 'rebased' on top of previous commit that cleans up the pipeline implementation
Different situations:
- +omit_fwd:
the step when followed in the forward path will be omitted
the step when followed in the reverse path will be executed
- +omit_fwd +inv:
the step when followed in the forward path will be omitted
the step when followed in the reverse path will be executed (with the inv method)
- +omit_inv:
the step when followed in the forward path will be executed
the step when followed in the reverse path will be omitted
- +omit_inv +inv:
the step when followed in the forward path will be executed (with the inv method)
the step when followed in the reverse path will be omitted
This will be used in the next commit to optimize constructs like
+step +proj=hgridshift +grids=foo
+step +proj=vgridshift +grids=bar
+step +inv +proj=hgridshift +grids=foo
Such steps are used for CRS to CRS transformations where applying the vertical grid
requires to do a transformation to an interpolating CRS. One can notice that
in the last step will just restore the horizontal coordinates before the first step, so
doing an inverse hgridshift is overkill.
So that could be optimized as:
+step +proj=push +v_1 +v_2
+step +proj=hgridshift +grids=foo +omit_inv
+step +proj=vgridshift +grids=bar
+step +inv +proj=hgridshift +grids=foo +omit_fwd
+step +proj=pop +v_1 +v_2
In the forward path, this will be equivalent to:
+step +proj=push +v_1 +v_2
+step +proj=hgridshift +grids=foo
+step +proj=vgridshift +grids=bar
+step +prop=pop +v_1 +v_2
And similarly in the reverse path, this will be quivalent to:
+step +proj=push +v_1 +v_2
+step +proj=hgridshift +grids=foo
+step +inv +proj=vgridshift +grids=bar
+step +proj=pop +v_1 +v_2
|
|
|
|
when the point coordinates are super close to the origin (fixes #1654)
|
|
|
|
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16130
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17190
|
|
|
|
Change all occurrences with the command below.
git grep -l http://download.osgeo.org/ | xargs sed -i 's,http://download.osgeo.org/,https://download.osgeo.org/,g'
Fixes: https://github.com/OSGeo/PROJ/issues/1521
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14602
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14477
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14421
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14410
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14384
Credit to OSS Fuzz
|
|
In that case, for a non-spherical ellipsoid, a phi = 180deg was returned,
which caused a division by zero in the foward path of moll.cpp
Fixup the latitude to be 0 when that happens.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14348
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14342
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14286
Credit to OSS Fuzz
|
|
vgridshift: handle longitude wrap-around for grids with 360deg longitude extent
|
|
Like egm96_15.gtx
Fixes #1415
Technically, a similar fix could be done for horizontal grids, but world
extent is less common for them.
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14279
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14250
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14211
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14138
Credit to OSS Fuzz
|
|
Partially revert e3346bb39c860883ed9a8ada0657139118e21ef0 (#195)
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14136
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14135
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14062
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14061
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14058
Credit to OSS Fuzz
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14044
Credit to OSS Fuzz
|
