| Age | Commit message (Collapse) | Author |
|
|
|
the Bertin 1953 projection
|
|
|
|
NTv1 grid shift: fix file offset for reading of shift values in ntv1_can.dat
|
|
|
|
When investigating the format of NTv1 and comparing PROJ code with the actual
header of ntv1_can.dat, I discovered that the longitude & latitude shift values
started at offset 192, whereas PROJ assumed that the header was 176 bytes only.
This caused PROJ to use the wrong offsets values (shift of one grid sample by
longitude). So the effect was moderately visible, especially on the latitude,
but when comparing with NTv2, one can see that the longitude value after the
fix seems to closer to NTv2.
old:
echo "60.5 -100.5 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
60.50022624 -100.50040292 0.00000000 inf
new:
echo "60.5 -100.5 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
60.50022403 -100.50041841 0.00000000 inf
echo "60.5 -100.5 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=$HOME/proj/proj-datumgrid/north-america/ntv2_0.gsb +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
60.50022348 -100.50041978 0.00000000 inf
old:
$ echo "80.1 -70.9 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
80.10096789 -70.89746834 0.00000000 inf
new:
$ echo "80.1 -70.9 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
80.10096858 -70.89749190 0.00000000 inf
$ echo "80.1 -70.9 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=$HOME/proj/proj-datumgrid/north-america/ntv2_0.gsb +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
80.10096782 -70.89749276 0.00000000 inf
|
|
of it (fixes #535)
|
|
The Geographic offsets transformation adds an offset to the geographic longitude,
latitude coordinates, and an offset to the ellipsoidal height.
This method is normally only used when low accuracy is tolerated. It is documented
as coordinate operation method code 9619 (for geographic 2D) and 9660 (for
geographic 3D) in the EPSG dataset.
It can also be used to implement the method Geographic2D with Height Offsets
(code 9618) by noting that the input vertical component is a gravity-related
height and the output vertical component is the ellispoid height (dh being
the geoid undulation).
It can also be used to implement the method Vertical offset (code 9616)
It is used for example to transform:
- from the old Greek geographic 2D CRS to the newer GGRS87 CRS
- from Tokyo + JSLD69 height to WGS 84
- from Baltic 1977 height to Black Sea height
It is also useful to document the implicit zero-offset transformation
we do in pipelines such as
+proj=pipeline +step +inv +proj=longlat +ellps=A
+step +proj=longlat +ellps=B
that can be explicited as
+proj=pipeline +step +inv +proj=longlat +ellps=A
+step +proj=geogoffset [+dlon=0 +dlat=0 +dh=0]
+step +proj=longlat +ellps=B
|
|
- classification
- tests
- coding style
|
|
|
|
|
|
|
|
|
|
Modifications for Intel compilers
|
|
|
|
Don't install test executables.
|
|
|
|
|
|
This worked for cs2cs / pj_transform(), but not the new API
|
|
Complements f2b3604
|
|
Assorted fixes related to +geoc flag handing
|
|
[BREAKING] Helmert: add +convention=position_vector/coordinate_frame, forbids +transpose (fixes #1091)
|
|
|
|
forbids +transpose (fixes #1091)
As identified in #1091, Helmert implementation in PROJ 5.0 and 5.1 is confusing.
It happens that by default it used the coordinate_frame convention, contrary to
the position_vector convention used traditionaly for +towgs84. The documentation
of Helmert was also wrongly specifying that the default convention was
position_vector.
This commit:
- bans the confusing +transpose parameter
- removes the concept of a default convention, since in practice both are
equally found, and requires +convention as soon as a rotational term parameter
is present.
For translation only, convention is ignored and optional, as having no effect.
- fixes all the identified uses of proj=helmert in code, doc and tests
This is obviously a breaking change:
- users will have to adapt their pipeline expressions
- in particular, init files that would use helmert must be adapted
However, as designed, the break will be explicit, and not silent.
|
|
There is a regression in PROJ 5 regarding the handling of the +geoc flag,
specific to the case of +proj=longlat, and the inverse transformation,
which makes it a no-op:
echo "12 55 0 " | src/cct +proj=pipeline +step +proj=longlat +ellps=GRS80 +geoc +inv
12.0000000000 55.0000000000 0.0000 inf
With this fix, we now get:
echo "12 55 0 " | src/cct +proj=pipeline +step +proj=longlat +ellps=GRS80 +geoc +inv
12.0000000000 54.8189733083 0.0000 inf
The fix consists in making inv_prepare() do symetrically as fwd_finalize(), ie
skip a number of transforms when left and right units are angular,
and in inv_finalize() apply the (OUTPUT_UNITS==PJ_IO_UNITS_ANGULAR) processing
even if INPUT_UNITS == PJ_IO_UNITS_ANGULAR
|
|
Implement the Equal Earth projection (closes #1085)
|
|
DHDN_ETRS89 autoconf test
|
|
(we should have a way to state that some grids must be present) (refs #872)
|
|
Add test coordinates for webmerc
|
|
|
|
As mentionned in #1071, it is often unclear how the offset of a vertical grid
is applied.
|
|
|
|
Courtesy of Michael Stumpf <mi12st34@gmail.com>
|
|
Make +proj=geocent and +proj=cart take into account +to_meter (relates to #1053)
|
|
|
|
|
|
that it supports numeric factors (refs #1053)
|
|
|
|
Nigrated from:
schwehr/gdal-autotest2:cpp/third_party/proj/pj_phi2_test.cc@master
License intentionally changed from Apache 2 to match PROJ.
|
|
|
|
|
|
Refines #1034
|
|
For CMake builds, latest googletest 1.8.0 is downloaded.
Following officially recommended integration for CMake-enabled projects
https://github.com/google/googletest/blob/master/googletest/README.md
"Use CMake to download GoogleTest as part of the build's configure step.
This is just a little more complex, but doesn't have the limitations
of the other methods."
Since, our copy of test/googletest
- is a very minimalist copy of googletest
- does not include any official CMake scripts
- would require copying parts of googletest CMakeLists.txt, compilater/linker flags (e.g. -lpthreads)
for reliable multi-platform builds, it is reasoanable to rely on download
All pros and cons advantages are discussed in teh README.md linked above.
Closes #1033
|
|
builds only (CMake integration to be done)
|
|
The previous commits were added way to prematurely. The code was not
properly tested and it turned out to do more bad than good. This commit
hopefully fixes that. And this time it is backed up by tests!
DMS style coordinates should now be fully functional in gie. Finger
crossed.
|
|
|
|
|
|
|
|
|
|
|