aboutsummaryrefslogtreecommitdiff
path: root/test/unit/test_operation.cpp
AgeCommit message (Collapse)Author
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.
2020-02-19validateParameters(): fix false-positive warning on Equidistant CylindricalEven Rouault
We required the 'Latitude of natural origin' parameter to be present, but it is only a GDAL/PROJ specific thing, not a EPSG one.
2020-01-29Add EPSG records for 'Geocentric translation by Grid Interpolation (IGN)' ↵Even Rouault
(gr3df97a.txt) and map them to new +proj=xyzgridshift
2020-01-25Implement RFC 5Even Rouault
2020-01-22Database: update to EPSG v9.8.6Even Rouault
Fixes #1867
2020-01-22Merge RFC4 (#1865)Even Rouault
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.
2020-01-11Merge pull request #1838 from rouault/limit_datum_name_massaging_wkt1Even Rouault
WKT1_GDAL export: limit datum name massaging to names matching EPSG (fixes #1835)
2020-01-11WKT1_GDAL export: limit datum name massaging to names matching EPSG (fixes ↵Even Rouault
#1835)
2020-01-10createOperations(): fix dealing with projected 3D CRS whose Z units != metreEven Rouault
2019-12-23test: add explict tests for New Zealand vertical <--> geog3D and vertical ↵Even Rouault
<--> vertical transformations
2019-12-20test: transformation_NZLVD_to_PROJ_string: attach database context to get ↵Even Rouault
filename substitution
2019-12-20Adding support for NZLVD vertical height transformationChris Crook
2019-12-16identify(): take into datum name aliases (fixes #1800)Even Rouault
2019-12-11createOperations(): make filtering out of 'uninteresting' operations less ↵Even Rouault
aggressive (refs #1787) 'EPSG:1304, Indian 1975 to WGS 84 (2), 5.0 m, Thailand - onshore and Gulf of Thailand' was removed because considered useless w.r.t first result 'EPSG:1812, Indian 1975 to WGS 84 (4), 3.0 m, Thailand - onshore' However the name of the area of use is not completely the same, so might be worth keeping it.
2019-11-28createOperations(): fix vertical to geographic when synthetizing an ↵Even Rouault
operation that involves a vertical axis reversal
2019-11-26createOperations(): fix an exception in transformations between Projected3D ↵Even Rouault
CRS and Projected CRS
2019-11-25createOperations(): optimize compoundCRS to geogCRS, when the geogCRS of the ↵Even Rouault
compoundCRS is the same as the target geogCRS
2019-11-21Fix typos in code commentsEven Rouault
2019-11-18createFromCRSCodesWithIntermediates(): do not consider intermediate CRS ↵Even Rouault
whose datum has a publication date older than the source and target datums
2019-11-18createOperations(): geocentric to geocentric operation synthetization: ↵Even Rouault
distinguish null transform from ballpark transform
2019-11-14createOperations(): fix transformation computation from/to a CRS with ↵Even Rouault
+geoidgrids and +vunits != m
2019-11-04Merge remote-tracking branch 'origin/master' into geoid_modelEven Rouault
2019-11-03createOperations(): in some circumstances we wrongly promoted a Helmert ↵Even Rouault
geog2D transformation to a geog3D Fixes for example EPSG:4979 to EPSG:2189, as raised in https://github.com/OSGeo/gdal/issues/1972#issuecomment-548814354
2019-11-02Database: add mapping between EPSG geoid and PROJ grid names for GEOID99, ↵Even Rouault
03, 06, 09 and 18. Related to https://github.com/OSGeo/proj-datumgrid/pull/60 that add those grids in proj-datumgrid-north-america
2019-11-02Add a geoid_model name in database, use GEOIDMODEL for transformations, add ↵Even Rouault
a proj_create_vertical_crs_ex()
2019-10-30createOperations(): try to recover extent of CRS from the database when they ↵Even Rouault
are missing, especially for compound CRS. Helps having shorter/more relevant results
2019-10-30Add a test to check we can use a VerticalCRS from its name only without the ↵Even Rouault
EPSG code
2019-10-30Rework importing of Vertical unit change from EPSG db, add support for ↵Even Rouault
Height Depth Reversal and use it in createOperations()
2019-10-29Vertical transformations: improve situations similar to transforming from ↵Even Rouault
'NAVD88 (ftUS)' to X, where we now consider the available transformations from 'NAVD88' to X that might exist in the database
2019-10-29Little tweaks in implicit 2D/3D geog conversions in compoundCRS to geogCRS ↵Even Rouault
transformations
2019-10-28createOperations(): avoid infinite recursion in a super weird case. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18587
2019-10-27Database: add an auxiliary concatenated_operation_step table to allow ↵Even Rouault
arbitrary number of steps (fixes #1632) EPSG:9103 (NAD27 to ITRF2014 (1)) is now handled. Note:EPSG:9104 (NAD27 to ITRF2014 (2)) is not currently, since it uses for step EPSG:8861 (NAD83(HARN) to NAD83(FBN) (1)) an unsupported transformation method (NADCON5 (3D), EPSG:1075).
2019-10-18createOperations(): fix double vertical unit conversion from CompoundCRS to ↵Even Rouault
other CRS when the horizontal part of the projected CRS uses non-metre unit Fix issue reported on https://lists.osgeo.org/pipermail/proj/2019-October/008939.html
2019-10-02Add API and WKT mapping for 'nsper' to EPSG Vertical Persepective methodEven Rouault
Relates to https://github.com/OSGeo/gdal/issues/1856
2019-09-26Improve vertical transformation supportEven Rouault
When we had a transformation between a compoundCRS and a target geographicCRS, we did not take into account that in the vertical->other_geog_CRS transformation we used, the other_geog_CRS was an implicit interpolation CRS. Thus before doing vertical adjustment, we must go to this interpolation CRS. The workflow is thus: source CRS -> interpolation CRS + vertical adjustment + interplation CRS -> target CRS
2019-09-23Database: update to EPSG 9.8.2Even Rouault
With limitation of https://github.com/OSGeo/PROJ/issues/1632 regarding concatenated operations with more than 3 steps.
2019-09-12createOperations(): when tranforming from a compoundCRS whose vertical ↵Even Rouault
component is a BoundCRS, do not apply the horizontal transformation twice
2019-09-12createOperations(): use more candidates when transforming between a ↵Even Rouault
geographic and vertical CRS For example when transforming from NAD83+NAVD88 height to WGS84, there is no transformation between NAVD88 height to WGS84. In that case, use all potential transformations from NAVD88 height to another geographic CRS for the vertical part.
2019-09-12Coordinate transformation: improve transformations from/to WGS84 (Gxxxx)Even Rouault
Currently very few transformations from/to WGS84 (Gxxxx) are registered in the EPSG database, and there isn't even transformations between WGS84 EPSG:4326 and those ones. Consequently transformations to those realizations often ended up as no-operation, whereas going through WGS84 EPSG:4326 will bring more meaningful results. So register those EPSG:4326<-->WGS 84 (Gxxx) null transformations, and when having WGS 84 (Gxxx) as source/target, consider EPSG:4326 as an intermediate. This change has no effect on the existing direct transformations from/to WGS 84 (Gxxx).
2019-09-12createOperations(): make sure sorting function is transitive (a < b and b < ↵Even Rouault
c --> a < c), to get consistent results
2019-09-12createOperations(): make it work when transforming between CompoundCRS and ↵Even Rouault
Geog3D when the DB has only VertCS to Geog2D This is needed to fix cases that would not work if using the promoteTo3D()/--3d functionnality just added per a6e1d72890615b42f54edad9b17acff8e7623844 In some cases, the EPSG database only contains a Geographic 2D CRS (like NAD83), without a 3D version. Consequently vertical transformations between that Geographic CRS and a Vertical CRS are only available with a 2D CRS code (kind of a bug in modelization by the way...). So when promoting the Geographic 2D CRS to a 3D one, we suddenly cannot find the available transformations any more. So in such situation, try to fallback to the 2D CRS to restore the capability to find the available transformations.
2019-09-11createOperations(): fix conversion from/to PROJ.4 CRS strings with ↵Even Rouault
non-ISO-cosher options and towgs84/nadgrids This actually fixes a regression introduced in PROJ 6.2.0 per 78302efb70eb4b49610cda6a60bf9ce39b82264f that made a conversion like EPSG:4326 to "+proj=something +towgs84/+nadgrids +over +type=crs" apply the towgs84/nadgrids operation twice.
2019-09-08Use in API and utilities WKT2_2019 instead of WKT2_2018 (fixes #1518)Even Rouault
- C API: PJ_GUESSED_WKT2_2019 is added, PJ_GUESSED_WKT2_2018 aliased to it - C API: PJ_WKT2_2019[_SIMPLIFIED] is added, PJ_WKT2_2018[_SIMPLIFIED] alias to it - C++ API: similarly for WKTFormatter::Convention::WKT2_2019[_SIMPLIFIED] Those above changes should be fully backward API and ABI compatible. projinfo changes: - accept WKT2_2019 as value for -o switch. WKT2_2018 is still accepted (undocumented) - output now uses 'WKT2_2019 string:', so might break scripts that would rely on that. Other internal code references to WKT2_2018 changes to WKT2_2019, included in tests.
2019-08-26createOperations(): follow-up of previous commit for +datum=NAD83 caseEven Rouault
2019-08-26createOperations(): fix pipeline generation when a CRS has terms like ↵Even Rouault
+datum=NAD27 and +over, where the datum was just replaced by its ellipsoid
2019-06-25grid_alternatives.sql: add the two Swisstopo grids (refs ↵Even Rouault
https://github.com/OSGeo/proj-datumgrid/pull/53)
2019-05-23createOperations(): fix GeogCRS to GeogCRS when there is a axis reversal and ↵Even Rouault
vertical unit change (relates to https://github.com/OSGeo/gdal/issues/1561)
2019-05-21createOperations(): avoid exception when transforming from NAD83 to ↵Even Rouault
projected CRS using NAD83(2011) (fixes #1474)
2019-05-06createOperations(): for 'Amersfoort / RD New + NAP height' (EPSG:7415) to ↵Even Rouault
ETRS89 (EPSG:4937), make sure that the vgridshift is applied first (ie on Amersfoort datum) before the hgridshift
2019-05-06createOperations(): fix case of ETRS89 3D to proj string with nadgrids and ↵Even Rouault
geoidgrids Fixes https://lists.osgeo.org/pipermail/proj/2019-May/008519.html
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-27 05:03:39 +0000