| Age | Commit message (Collapse) | Author |
|
conversion is the first or last operation (fixes #2890)
|
|
Non-trivial updates:
- some vertical CRS are now encoded as DerivedVerticalCRS. e.g EPSG:8228
"NAVD88 height (ft)", with base EPSG:5703 "NAVD88 height". As we don't
have support in our PROJ db model for DerivedVerticalCRS, modify the
import script to 'resolve' the derivation up to the original datum.
- Method EPSG:1069 'Change of Vertical Unit' is no longer used. It is
replaced by a generic-purpose EPSG:1104 method that doesn't take any
conversion factor. And generic conversions EPSG:7812 and EPSG:7813 are
now used in concatenated operations, which require code changes as
well.
|
|
+hyperbolic
|
|
|
|
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
```
|
|
|
|
|
|
|
|
|
|
Add +proj=topocentric geocentric->topocentric conversion (fixes #500)
|
|
GEOIDMODEL[]
|
|
|
|
of a DerivedGeographicCRS (+proj=ob_tran +o_proj=lonlat +towgs84=....)
|
|
transformations
|
|
|
|
help for NAD83->WGS84->NAD83(2011) hops
|
|
greater 'version numbers' are prefered over other ones, when all other comparison criteria are equal. Helps with Amersfoort RD New to EPSG:4326
|
|
2007 to WGS84 issues) (fixes #2356)
- We make createBoundCRSToWGS84IfPossible() more restrictive. If there are more
than one Helmert transformation from the CRS to WGS 84 covering the area of
use of the CRS, we do not create a BoundCRS / +towgs84
- In createOperations() filtering, we are less aggressive in discarding operations
that have the same area of use but worse accuracy. We do it only if they involve
more transformation steps.
We now get:
```
$ projinfo EPSG:5340 -o PROJ
PROJ.4 string:
+proj=longlat +ellps=GRS80 +no_defs +type=crs
$ projinfo -s EPSG:5340 -t EPSG:4326 --spatial-test intersects --summary
Candidate operations found: 2
EPSG:9264, POSGAR 2007 to WGS 84 (2), 0.5 m, Argentina
EPSG:5351, POSGAR 2007 to WGS 84 (1), 1.0 m, Argentina
```
|
|
cases where false_easting and false_northing are 0
|
|
Projected3D CRS and not a compound CRS with a unknown datum (fixes #2287) (#2288)
|
|
|
|
records as we do with the more common 'Geographic3D to GravityRelatedHeight'
|
|
registered transformations between compoundCRS and something else
|
|
Geog2D+GravityRelatedHeight (US .gtx)' method used by Slovakian geoids correctly deal with axis order and unit conversion, to be used as 'standalone'. Also improves when using directly 'Geographic3D to GravityRelatedHeight' method
|
|
BoundCRS in the general case let to 0 result (contributes to fixes #2232)
|
|
vertical unit change
|
|
case of transformation between Compound of BoundVerticalCRS to GeographicCRS (contributes to fixes #2232)
|
|
a BoundCRS to a GeographicCRS (contributes to fixes #2232)
|
|
of a datum and the same datum (relates to #2232)
|
|
Inconsistent chainging of CRS (fixes #2232)
|
|
|
|
use discard change of ellipsoidal height if a Helmert transformation is involved (fixes #2225)
|
|
|
|
same vertical datum
|
|
|
|
and PROJ4_GRIDS for vertical (refs #2217)
|
|
component when vertical CRS has non metre unit (fixes #2217)
|
|
|
|
and handle +czech correctly (fixes #2199) (#2200)
* createFromProjString(): handle default parameters of '+krovak +type=crs', and handle +czech correctly (fixes #2199)
* Doc: add default values for Krovak
|
|
Adams Square II: map ESRI WKT to PROJ string, and implement iterative inverse method
|
|
|
|
grid based operations, even if they cover the whole area of use (fixes #2143)
|
|
(fixes #2115)
|
|
compoundCRS (fixes #2108)
|
|
|
|
+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.
|
|
https://github.com/OSGeo/PROJ-data/pull/13 + handle 'Vertical Offset by Grid Interpolation (BEV AT)' method
|
|
|
|
to it (fixes #1982)
|
|
19111
|