aboutsummaryrefslogtreecommitdiff
path: root/test/unit/test_crs.cpp
AgeCommit message (Collapse)Author
2021-04-12CRS::normalizeForVisualization(): propagate domains/extent of original CRS ↵Even Rouault
(fixes #2603)
2021-03-03Reformat code with clang-format-10 from ubuntu 20.04Even Rouault
2021-02-09Database: update to EPSG v10.013Even Rouault
2020-11-29Merge pull request #2450 from rouault/setAllowEllipsoidalHeightAsVerticalCRSEven Rouault
Add option to allow export of Geographic/Projected 3D CRS in WKT1_GDAL
2020-11-27PRIMEM WKT handling: fixes on import for 'sexagesimal DMS' or from ↵Even Rouault
WKT1:GDAL/ESRI when GEOGCS UNIT != Degree; morph to ESRI the PRIMEM name on export
2020-11-24Add option to allow export of Geographic/Projected 3D CRS in WKT1_GDALEven Rouault
as CompoundCRS with a VerticalCRS being an ellipsoidal height, which is not conformant. But needed for LAS 1.4 that only supports WKT1
2020-11-23GeographicCRS::_isEquivalentTo(EQUIVALENT_EXCEPT_AXIS_ORDER_GEOGCRS): make ↵Even Rouault
it work when comparing easting,northing,up and northing,easting,up
2020-11-21Make GeographicCRS/GeodeticCRS::isEquivalentTo() work properly when ↵Even Rouault
comparing to a DerivedGeographicCRS/DerivedGeodeticCRS
2020-11-04createBoundCRSToWGS84IfPossible(): make it return same result with a CRS ↵Even Rouault
built from EPSG code or WKT1 Related to https://github.com/OSGeo/gdal/issues/3144
2020-10-20VerticalCRS: morph CRS and datum name using ESRI aliases on import from / ↵Even Rouault
export to WKT1:ESRI
2020-10-20Improve identification of compound CRS from ESRI WKT1, and for compound CRS ↵Even Rouault
whose result is not in the DB but whose horiz and vertical parts are known
2020-10-08Make CRS identification work with CRS with DatumEnsembleEven Rouault
2020-10-05proj_crs_create_bound_crs_to_WGS84(): make it work on ↵Even Rouault
verticalCRS/compoundCRS such as EPSG:4326+5773 and EPSG:4326+3855
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-08-07ProjectedCRS::identify(): fix to be able to identify EPSG:2154 as a ↵Even Rouault
candidate for 'RGF93_Lambert_93' (contributes to fixes https://github.com/qgis/QGIS/issues/32255) (#2315)
2020-06-03normalizeForVisualization(): make it switch axis for EPSG:5482 (RSRGD2000 / ↵Even Rouault
RSPS2000) Fixes #2254
2020-05-25Fix identification of (one of the) ESRI WKT formulations of EPSG:3035Even Rouault
Fixes https://github.com/qgis/QGIS/issues/36111
2020-05-15Make projinfo --3d --boundcrs-to-wgs84 better work (fixes #2202)Even Rouault
2020-05-13ProjectedCRS::identify(): fix identification of EPSG:3059 from ↵Even Rouault
'LKS92_Latvia_TM' name, and other cleanups/improvements (fixes #2214)
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-14ProjectedCRS identification: deal with switched 1st/2nd std parallels for ↵Even Rouault
LCC_2SP (#2150) As switching the 2 standard parallels for Lambert Conformal Conic 2 standard parallels result in a equivalently numerical projection definition, take that into account when querying the database.
2020-04-03Make sure that importing a Projected 3D CRS from WKT:2019 keeps the base ↵Even Rouault
geographic CRS as 3D (fixes #2122)
2020-03-30ESRI_WKT ingestion: make sure to identify to non-deprecated EPSG entry when ↵Even Rouault
possible (fixes #2116)
2020-03-27Fix identification of projected CRS whose name is close but not strictly ↵Even Rouault
equal to a ESRI alias (fixes #2099)
2020-03-25EngineeringCRS: when exporting to WKT1_GDAL, output unit and axis (fixes ↵Even Rouault
https://github.com/OSGeo/gdal/issues/2347)
2020-03-24ESRI WKT import / identification: special case for ↵Even Rouault
NAD_1983_HARN_StatePlane_Colorado_North_FIPS_0501 with Foot_US unit (fixes #2086)
2020-03-11ProjectedCRS::identify(): tune it to better work with ESRI WKT ↵Even Rouault
representation of EPSG:2193 Adresses https://github.com/OSGeo/gdal/issues/2303 by raising the identification confidence from 25% to 90% (90% means equivalent for all purposes, but name not strictly the EPSG official one)
2020-03-06WKT import/export: add support for WKT1_ESRI VERTCS syntaxEven Rouault
2020-02-25CompoundCRS::create(): reject combinations of components not allowed by ISO ↵Even Rouault
19111
2020-02-06Merge pull request #1915 from rouault/fix_1911Even Rouault
Fix identification of ESRI-style datum names starting with D_ but without alias
2020-02-05Fix identification of ESRI-style datum names starting with D_ but without aliasEven Rouault
Fixes #1911
2020-02-05Fix performance issue, affecting projinfo EPSG:7842Even Rouault
Fixes #1913 AuthorityFactory::createBetweenGeodeticCRSWithDatumBasedIntermediates() issued a complex SQL query that pushes the SQLite3 query plan optimizer to its limits. Was working reasonably with sqlite 3.11, but not with later versions. So put less constraints in the main query and do post-processing checks and auxiliary requests to avoid such issues. For some unknown reason, this slightly slows down a bit execution time of the whole test_cpp_api binary (~ 10%), but couldn't come with something better, despite trying many variations of the main SQL query. It seems that in the general case the non-filter LEFT JOIN on the supersession table helped, except on this EPSG:7842 case.
2020-01-21ProjectedCRS::identify(): fix wrong identification of some ESRI WKT linked ↵Even Rouault
to units Fixes bug reported in https://lists.osgeo.org/pipermail/gdal-dev/2020-January/051481.html
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-10CompoundCRS::identify(): avoid exception when horiz/vertical part is a BoundCRSEven Rouault
The exception only affects C++ users. It was caught by the C layer.
2019-12-16identify(): take into datum name aliases (fixes #1800)Even Rouault
2019-12-16BoundCRS::identify(): improvements to discard CRS that aren't relevant ↵Even Rouault
(fixes #1801) Fix for ``` projinfo --identify "+proj=utm +zone=48 +a=6377276.345 +b=6356075.41314024 +towgs84=198,881,317,0,0,0,0 +units=m +no_defs +type=crs" ``` to only return BoundCRS of EPSG:3148: 70 % Previously it also returned EPSG:23948 and EPSG:24048 whose projected CRS-only parts where likely matches, but those 2 CRSs don't have a +towgs84=198,881,317,0,0,0,0, so discard them.
2019-12-13normalizeForVisualization(): address EPSG:32661 "WGS 84 / UPS North (N,E)" ↵Even Rouault
and EPSG:32761 "WGS 84 / UPS South (N,E)" Fixes https://github.com/qgis/QGIS/issues/33077
2019-12-09CRS identification: use case insensitive comparison for authority name ↵Even Rouault
(fixes #1779)
2019-11-25normalizeForVisualization() and other methods applying on a ProjectedCRS: do ↵Even Rouault
not mess the derivingConversion object of the original object (fixes #1736) normalizeForVisualization(), promoteTo3D(), demoteTo2D(), alterGeodeticCRS(), alterCSLinearUnit() and alterParametersLinearUnit() all used the object returned by derivingConversionRef() to create a new ProjectedCRS. While doing so, this caused the derivingConversion of the original object to have its targetCRS set to the object returned by normalizeForVisualization() and similar. If that object died, then the weak pointer would be reset, and the original ProjectedCRS() has now its derivingConversionRef()->targetCRS() nullptr So bottom line is use derivingConversion() for anything that is not pure reading !!! This is confirmed to be the fix for the QGIS scenario in https://github.com/qgis/QGIS/issues/30569#issuecomment-540060919 In QGIS use case, the issue arised when using a projected CRS with a non-GIS friendly axis (that is where normalizeForVisualization() created a new projectedCRS)
2019-10-04Add a proj_crs_demote_to_2D(). Useful if forced to export a 3D CRS to a best ↵Even Rouault
approximate as WKT1 that doesn't support it
2019-10-03DerivedGeographicCRS: allow exporting +proj=ob_tran +o_proj=longlat to PROJ ↵Even Rouault
string
2019-09-11API: add CRS::promoteTo3D(), proj_crs_promote_to_3D() and ↵Even Rouault
proj_crs_create_projected_3D_crs_from_2D() (fixes #1587) Also add a --3d switch to projinfo
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-05-13identify(): take into account the authority passed in (fixes #1465)Even Rouault
When identifying an object that has already a code with authority A but the authority of interest passed was B, then it was not checking that A != B, and did not try to search in the objects of B.
2019-05-12Fix identification of GeodeticCRS expressed by PROJ string for EPSG authorityEven Rouault
2019-03-25WKT2_2018: always export ID in base crs node, even if there is one on upper nodeEven Rouault
This is a particular logic allowed by paragraph 7.3.3 Identifier of OGC 18-010r6
2019-03-25WKT2_2018: export ID in base crs node, when there is none on top of upper nodeEven Rouault
This is the standard logic, that is now possible since ID is allowed in BASEGEOGCRS and similar node
2019-03-25test: test exporting ENSEMBLE with ID in MEMBEREven Rouault