aboutsummaryrefslogtreecommitdiff
path: root/test/unit/test_crs.cpp
AgeCommit message (Collapse)Author
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
2019-02-17Modify the default strategy of researching intermediate CRS to do it only if ↵Even Rouault
there is no direct transformation
2019-02-15Fix size_t comparisons in testsKai Pastor
2019-01-17Remove proj_create_from_proj_string() and proj_create_from_user_input(), and ↵Even Rouault
make proj_create() do more or less what proj_create_from_user_input() did before (fixes #1214)
2019-01-17import/export PROJ strings from ISO19111 code: require/output +type=crs for ↵Even Rouault
CRS objects (refs #1214)
2019-01-08Fix export of BoundCRS as with PROJ_5 conventionEven Rouault
2019-01-08ISO19111: remove PROJ.5 specific format for CRS (refs #1214)Even Rouault
As discussed in https://github.com/OSGeo/proj.4/issues/1214#issuecomment-452084720, the introduction of a new PROJ.5 format to export CRS using pipeline/unitconvert/axisswap as an attempt of improving the PROJ.4 format used by GDAL and other products is likely a dead-end since it is still lossy in many aspects and can cause confusion with coodinate operations. Consequently the PROJ_5 convention will be identical to PROJ_4 for CRS export. Note: on the import side, I've kept the code that could parse unitconvert and axisswap when building a CRS definition from a pipeline. It is there as a hidden feature as it was kind of a tear to remove that code in case it might still be useful...
2019-01-04WKT export: no longer export Geographic 3D CRS in WKT1, unless strict mode ↵Even Rouault
is disabled
2018-12-22exportToWKT1 of projected CRS: do not output AXIS of base CRS even when ↵Even Rouault
OutputAxisRule::YES
2018-12-17Add WKT2 grammar validationEven Rouault
2018-12-15Add SingleOperation::validateParameters()Even Rouault
2018-12-06Speed-up createBoundCRSToWGS84IfPossible()Even Rouault
2018-12-06Add API to retrieve non-deprecated equivalent of an objectEven Rouault
2018-12-06Fix special handling of Azimuth parameter of KrovakEven Rouault
2018-12-06Fine tune axis denomination when exporting to WKT1_GDALEven Rouault
2018-12-06Coordinate operation search: add a authority_to_authority_preference table ↵Even Rouault
to restrict and prioritize searches
2018-12-04WKT1 export of LOCAL_CS: add UNIT if explicitly setEven Rouault
2018-12-04export to WKT1 of geocentric CRS: do not emit a TOWGS84 node if the datum is ↵Even Rouault
WGS84
2018-12-03Export to ESRI WKT: make it use verbatim WKT definition from the database ↵Even Rouault
when possible
2018-12-02identify: improve GeographicCRS identification when the CRS name has no matchEven Rouault
2018-12-02improve identify() for projected and bound CRSEven Rouault
2018-11-29C API extensions and renamingEven Rouault
- proj_obj_create_projected_XXXXX() are renamed to proj_obj_create_conversion_snake_case() and just instanciate a Conversion object - Advanced manipulation functions are moved to a dedicated section at bottom of proj.h - New C API needed for GDAL OGRSpatialReference
2018-11-29exportToWKT WKT1_GDAL: export axis by default for GeocentricCRSEven Rouault
2018-11-20Database: use official IGNF.xml registry to create content from the IGNF ↵Even Rouault
authority Up to now, we re-processed the data/IGNF PROJ.4 definition to ingest it into proj.db, but this file originally come from a processing of IGNF.xml ( http://librairies.ign.fr/geoportail/resources/IGNF.xml ) The end result is not strictly equivalent, as data/IGNF has some 'magic' to create towgs84 / nadgrids, since IGNF.xml doesn't necessary contain all transformations from its geodetic systems to WGS84. I've tried to re-add some of those missing transforms (null Helmert transforms), so it can be used for pivoting, but that might be incomplete.
2018-11-19Assorted set of fixes for PROJString to ISO19111 model:Even Rouault
- createFromPROJString(): take into account axisswap step for Krovak and Transverse Mercator (South Orientated) - Geocentric export to PROJ4: use datum when possible, and add explicit units=m - ESRI WKT parser: make it case insensitive to parameter and projection names, and more tolerant about possible parameter name aliases - import from WKT1 for Polar_Stereographic: don't be case sensitive - importFromPROJString: allow pm to override datum - Equidistant cylindrical: add support for non-standard latitude of natural origin, used in a GDAL test case - tmerc export to PROJString: use 'k' instead of 'k_0' - pj_ellps: use official value from EPSG for reverse flattening of Airy ellipsoid - GDAL compatibility: add support for importing odd formulations of Mercator as WKT1, but rejecting them when exporting to PROJ - Add export of 'Geostationary Satellite (Sweep X)' to WKT1_GDAL via EXTENSION.PROJ4 node - importFromPROJString: add support for +f - WKT1 / PROJ4: add support for EXTENSION.PROJ4 nodes and +wktext - exportToWKT: change way we deal with AXIS by default for WKT1_GDAL - Improve etmerc handling - Fix WKT import of peg_point_heading for Spherical_Cross_Track_Height - International Map of the World Polyconic: change parameter mapping - exportToPROJ: add alpha parameter - Hotine_Oblique_Mercator_Two_Point_Natural_Origin: GDAL_WKT1 related fix - GDAL compatibility improvements in import from PROJ4 / WKT1 for polar stereographic - Add support for +towgs84 when importing a +proj=geocent - import from WKT1: add support for an odd Mercator_1SP formulation handled by GDAL - export to proj4 strings: add +units=m to projected CRS for better GDAL compatibility - export to proj4 strings: add +no_defs to CRS for better GDAL compatibility
2018-11-14Implement RFC 2: Initial integration of "GDAL SRS barn" workEven Rouault
This work mostly consists of: - a C++ implementation of the ISO-19111:2018 / OGC Topic 2 "Referencing by coordinates" classes to represent Datums, Coordinate systems, CRSs (Coordinate Reference Systems) and Coordinate Operations. - methods to convert between this C++ modeling and WKT1, WKT2 and PROJ string representations of those objects - management and query of a SQLite3 database of CRS and Coordinate Operation definition - a C API binding part of those capabilities This is all-in-one squashed commit of the work of https://github.com/OSGeo/proj.4/pull/1040
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-27 15:08:21 +0000