aboutsummaryrefslogtreecommitdiff
path: root/test/unit/test_operation.cpp
AgeCommit message (Collapse)Author
2021-04-23Database: update to EPSG v10.019Even Rouault
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.
2021-04-03Add mapping between EPSG method 'Hyperbolic Cassini-Soldner' and +proj=cass ↵Even Rouault
+hyperbolic
2021-03-03Reformat code with clang-format-10 from ubuntu 20.04Even Rouault
2021-02-10Allow a BoundCRS to use a PROJ string transformationEven Rouault
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 ```
2021-02-10test_operation: use correct variable nameEven Rouault
2021-02-09Database: update to EPSG v10.013Even Rouault
2020-12-12Split test_operation.cpp in two partsEven Rouault
2020-12-11test_operation.cpp: remove debug messageEven Rouault
2020-12-02Merge pull request #2444 from rouault/topocentricEven Rouault
Add +proj=topocentric geocentric->topocentric conversion (fixes #500)
2020-11-24createOperation(): add a ballpark vertical transformation when dealing with ↵Even Rouault
GEOIDMODEL[]
2020-11-23Add +proj=topocentric geocentric->topocentric conversion (fixes #500)Even Rouault
2020-11-21createOperation(): make it work properly when one of the CRS is a BoundCRS ↵Even Rouault
of a DerivedGeographicCRS (+proj=ob_tran +o_proj=lonlat +towgs84=....)
2020-10-31Fill remarks for PROJ-based operation mixing horizontal and vertical ↵Even Rouault
transformations
2020-10-08Make createOperations() work with DatumEnsembleEven Rouault
2020-10-02createOperations(): avoid elimination of ballpark transformation that can ↵Even Rouault
help for NAD83->WGS84->NAD83(2011) hops
2020-09-17createOperations(): tune sorting of transformations so that the ones with ↵Even Rouault
greater 'version numbers' are prefered over other ones, when all other comparison criteria are equal. Helps with Amersfoort RD New to EPSG:4326
2020-09-17Adjust createBoundCRSToWGS84IfPossible() and operation filtering (for POSGAR ↵Even Rouault
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 ```
2020-07-09Transverse Mercator South Orientated: restrict export to PROJ string to ↵Even Rouault
cases where false_easting and false_northing are 0
2020-07-02Parse '+proj=something_not_latlong +vunits=' without +geoidgrids as a ↵Even Rouault
Projected3D CRS and not a compound CRS with a unknown datum (fixes #2287) (#2288)
2020-06-16createOperations(): fix transformations between BoundCRS and Geocentric CRSEven Rouault
2020-06-06Database: make sure we can deal with 'Geog3D to Geog2D+GravityRelatedHeight' ↵Even Rouault
records as we do with the more common 'Geographic3D to GravityRelatedHeight'
2020-06-06createOperations(): improve name of inverse transformation when there are ↵Even Rouault
registered transformations between compoundCRS and something else
2020-06-06createOperations(): changes so that EPSG:9635 'Geog3D to ↵Even Rouault
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
2020-05-19createOperations(): fix bug when transforming between CompoundCRS and ↵Even Rouault
BoundCRS in the general case let to 0 result (contributes to fixes #2232)
2020-05-19createOperations(): optimization in generated pipeline in a case involving ↵Even Rouault
vertical unit change
2020-05-19createOperations(): take correctly into account vertical unit change in a ↵Even Rouault
case of transformation between Compound of BoundVerticalCRS to GeographicCRS (contributes to fixes #2232)
2020-05-19createOperations(): fix wrong optimization in some instances of transforming ↵Even Rouault
a BoundCRS to a GeographicCRS (contributes to fixes #2232)
2020-05-19createOperations(): speed optimizations for transforming between a BoundCRS ↵Even Rouault
of a datum and the same datum (relates to #2232)
2020-05-19createOperations(): fix 'caching' bugs causing potential exception about ↵Even Rouault
Inconsistent chainging of CRS (fixes #2232)
2020-05-16test: improve formatting of expected resultEven Rouault
2020-05-16createOperations(): when converting CompoundCRS<-->Geographic3DCrs, do not ↵Even Rouault
use discard change of ellipsoidal height if a Helmert transformation is involved (fixes #2225)
2020-05-16createOperations(): be stricter when considering if an operation is a null oneEven Rouault
2020-05-14createOperations(): optimize BoundCRS to BoundCRS of vertical CRS using the ↵Even Rouault
same vertical datum
2020-05-14createOperations(): fix exceptions related to CompoundCRS and BoundCRSEven Rouault
2020-05-14WKT1 parsing: fix parsing of CompoundCRS that has a TOWGS84 for horizontal ↵Even Rouault
and PROJ4_GRIDS for vertical (refs #2217)
2020-05-14WKT/PROJJSON parsing: fix BoundCRS/PROJ4_GRIDS handling for vertical ↵Even Rouault
component when vertical CRS has non metre unit (fixes #2217)
2020-05-09scripts/fix_typos.sh: fix URLs to dictionaries, and fix typos spottedEven Rouault
2020-04-28createFromProjString(): handle default parameters of '+krovak +type=crs', ↵Even Rouault
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
2020-04-16Merge pull request #2157 from rouault/map_esri_54098Even Rouault
Adams Square II: map ESRI WKT to PROJ string, and implement iterative inverse method
2020-04-16Map ESRI WKT for Adams_Square_II to +proj=adams_ws2Even Rouault
2020-04-14createOperations(): do not remove ballpark transformation if there are only ↵Even Rouault
grid based operations, even if they cover the whole area of use (fixes #2143)
2020-04-04createOperations(): improve results of compoundCRS to compoundCRS case ↵Even Rouault
(fixes #2115)
2020-03-30Fix working of Helmert transform between the horizontal part of 2 ↵Even Rouault
compoundCRS (fixes #2108)
2020-03-06Typo fixes identified by scripts/fix_typos.shEven Rouault
2020-02-29createOperations(): fix wrong pipeline generation with CRS that has ↵Even Rouault
+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.
2020-02-26Database: register 4 height Austrian grids from ↵Even Rouault
https://github.com/OSGeo/PROJ-data/pull/13 + handle 'Vertical Offset by Grid Interpolation (BEV AT)' method
2020-02-26Database: update to EPSG v9.8.7Even Rouault
2020-02-25createOperations(): be robust to a GeographicCRS having a wrong ID attached ↵Even Rouault
to it (fixes #1982)
2020-02-25CompoundCRS::create(): reject combinations of components not allowed by ISO ↵Even Rouault
19111
2020-02-24createOperations(): keep height/z value in Helmert transform between 3D CRSEven Rouault
This is the consequence of a private email thread between me, Joel Haasdyk and Roger Lott. I initially raised that the GDA2020 technical manual advertized the Helmert transformation between GDA94 to GDA2020 to be a 3D one, with example of a test point where ellipsoidal heights where modified. It appears this was intended. The corresponding record in EPSG uses the EPSG:9607 "Coordinate Frame rotation (geog2D domain)" method between the 2D geographic CRS of GDA94 and GDA2020. From the email exchange, it appears that there's a lot of legacy explaining that Helmert transformations are registered only between 2D CRS, which doesn't mean that when applied to the corresponding 3D CRS, the change in ellipsoidal height should be discarded. Related to that, the EPSG database, while it has methods flagged "(geog3D domain)" never uses them. So... this changeset slightly ammends PROJ behaviour to ignore the "(geog2D domain)" flag, but only consider the dimensionality of the source & target CRS. However, for a EPSG transformation, those are always 2D CRS, hence introduce the use3DHelmert_ hack when we know that ultimately the 'real' source & target CRS are 3D. I wouldn't be surprised if in more complex pipeline the above logic would be lacking. But it fixes at least simple transformations.
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-29 03:25:32 +0000