| Age | Commit message (Collapse) | Author |
|
Related to https://lists.osgeo.org/pipermail/proj/2021-February/010040.html
Given test.wkt with
```
BOUNDCRS[
SOURCECRS[
GEOGCRS["unknown",
DATUM["Unknown based on GRS80 ellipsoid",
ELLIPSOID["GRS 1980",6378137,298.257222101,
LENGTHUNIT["metre",1],
ID["EPSG",7019]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8901]],
CS[ellipsoidal,2],
AXIS["longitude",east,
ORDER[1],
ANGLEUNIT["degree",0.0174532925199433,
ID["EPSG",9122]]],
AXIS["latitude",north,
ORDER[2],
ANGLEUNIT["degree",0.0174532925199433,
ID["EPSG",9122]]]]],
TARGETCRS[
GEOGCRS["WGS 84",
DATUM["World Geodetic System 1984",
ELLIPSOID["WGS 84",6378137,298.257223563,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
CS[ellipsoidal,2],
AXIS["latitude",north,
ORDER[1],
ANGLEUNIT["degree",0.0174532925199433]],
AXIS["longitude",east,
ORDER[2],
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4326]]],
ABRIDGEDTRANSFORMATION["Transformation from unknown to WGS84",
METHOD["PROJ-based operation method: +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=axisswap +order=2,1 +step +proj=cart +ellps=GRS80 +step +proj=helmert +convention=coordinate_frame +exact +step +inv +proj=cart +ellps=WGS84 +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=rad +xy_out=deg"]]]
```
``projinfo -s @test.wkt -t "WGS 84" -o PROJ -q``
outputs:
```
+proj=pipeline
+step +proj=unitconvert +xy_in=deg +xy_out=rad
+step +proj=axisswap +order=2,1
+step +proj=cart +ellps=GRS80
+step +proj=helmert +convention=coordinate_frame +exact
+step +inv +proj=cart +ellps=WGS84
+step +proj=axisswap +order=2,1
+step +proj=unitconvert +xy_in=rad +xy_out=deg
```
|
|
|
|
(G1762)
It is no longer needed for that particular case, since there's now a concatenated
operation for it. It could in theory be useful for other cases, but removing it
doesn't break existing tests, so...
|
|
CMake: remove old configuration option aliases
|
|
Add build time option to make PROJ_LIB env var tested last (fixes #2399)
|
|
Database: update to EPSG v10.011
|
|
|
|
|
|
|
|
ellipsoidal height
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
that it is automatically added
|
|
the error message
|
|
|
|
when it returns invalid coordinate
|
|
Fixes #2482
And also add proj_context_errno_string()
Revise gie 'expect failure errno XXXX' strings
|
|
|
|
|
|
from BoundCRS of projected CRS based on NTF Paris to BoundCRS of geog CRS NTF Paris. Fixes https://github.com/OSGeo/gdal/issues/3273
|
|
The big size of coordinateoperation.cpp could require significant amount
of RAM to build it with -O2 level, and cause compiler crashes in some
environments.
|
|
control where coordinate operations are looked for (fixes #2442)
|
|
If PROJ is built with the PROJ_LIB_ENV_VAR_TRIED_LAST CMake option /
--enable-proj-lib-env-var-tried-last configure switch, then the
hard-wired path ($prefix/share/proj) will be tried before looking at the
environment PROJ_LIB.
|
|
|
|
Add +proj=topocentric geocentric->topocentric conversion (fixes #500)
|
|
Database: add metadata with the version number of the database layout …
|
|
cs2cs: add --area and --bbox options to restrict candidate coordinate operations (fixes #2423)
|
|
Spherical tmerc forward: do not restrict to [-90,90] longitude range
|
|
check it in the code
This is aimed at detecting running a PROJ version against a proj.db that is not
meant to work with it. This happens sometimes in complex setups mixing PROJ
versions. Hopefully this will help spotting the issue earlier.
|
|
unused ones
|
|
|
|
The restriction was a copy&paste from the Evenden/Snyder approximate
ellipsoidal implementation, but the spherical one is exact, so this
restriction isn't needed.
Also tune a bit the handling of lat=0, |lon| > 90
|
|
Add option to allow export of Geographic/Projected 3D CRS in WKT1_GDAL
|
|
(fixes #2468)
Corrected formula given by @evanmiller
|
|
when attempting (non-sensical) EPSG:3855 to EPSG:4326
|
|
|
|
PROJ_SPATIAL_CRITERION_PARTIAL_INTERSECTION if area is specified
|
|
operations (fixes #2423)
|
|
output by cct (#2453)
Currently the output of the cct utility is different between radians
and degrees (as expected by cct), because of a bug in cct:
$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad
1.0000000000 2.0000000000 0.0000 0.0000
$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=deg
1.0000 2.0000 0.0000 0.0000
The arguments to the printf format string are as follows:
* radians: width 14, precision 10
* degrees: width 13, precision 4 (this is by mistake. bug!)
After the suggested fix has been applied, output will be the same for
both radians and degrees:
$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad
1.0000000000 2.0000000000 0.0000 0.0000
$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=deg
1.0000000000 2.0000000000 0.0000 0.0000
The cause of the bug is that cct does test if it "has radians to output",
but "neglects" to test if it "has degrees to output", resulting in using
different arguments to the printf format string in the latter case.
The fix makes cct test if it "has either radians or degrees to output".
|
|
32N' return only the exact match
|
|
PRIMEM WKT handling: fixes on import for 'sexagesimal DMS' or from WKT1:GDAL/ESRI when GEOGCS UNIT != Degree; morph to ESRI the PRIMEM name on export
|
|
|
|
WKT1:GDAL/ESRI when GEOGCS UNIT != Degree; morph to ESRI the PRIMEM name on export
|