aboutsummaryrefslogtreecommitdiff
path: root/src/iso19111/crs.cpp
AgeCommit message (Collapse)Author
2021-04-12CRS::normalizeForVisualization(): propagate domains/extent of original CRS ↵Even Rouault
(fixes #2603)
2021-03-19CRS::promoteTo3D(): propagate the extent from the 2D CRS (fixes #2587)Even Rouault
This will help getting more consistent results between the 2D and 3D cases, as identified in https://github.com/OSGeo/PROJ/issues/2587#issue-836061171
2021-03-03Reformat code with clang-format-10 from ubuntu 20.04Even Rouault
2021-02-10Fix handling of +proj=ob_tran +o_proj=longlat combined with +over (fixes #2510)Even Rouault
2020-12-14createOperations(): fix inconsistent chaining exception when transforming ↵Even Rouault
from BoundCRS of projected CRS based on NTF Paris to BoundCRS of geog CRS NTF Paris. Fixes https://github.com/OSGeo/gdal/issues/3273
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-23WKT1_ESRI export: try to export Geographic3D and Projected3D CRS when we can ↵Even Rouault
find a corresponding ellipsoidal vertical datum
2020-10-23WKT1_ESRI export: generate VERTCS[...,DATUM[...,SPHEROID[]] syntax when ↵Even Rouault
ellipsoidal height is found
2020-10-22WKT1_ESRI export: export CompoundCRS as PROJCS[...],VERTCS[...] or ↵Even Rouault
GEOGCS[...],VERTCS[...]
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-17CompoundCRS with ellipsoidal height: make sure the vertical axis has ↵Even Rouault
'ellipsoid height' as name and 'h' as abbreviation
2020-10-16Merge pull request #2370 from rouault/epsg10Even Rouault
Update to EPSG 10.003 and make code base robust to dealing with WKT CRS with DatumEnsemble
2020-10-08promoteTo3D(): add a remark with the original CRS identifier (fixes #2368)Even Rouault
``` $ projinfo EPSG:32631 --3d WKT2:2019 string: PROJCRS["WGS 84 / UTM zone 31N", [ ...snip ] REMARK["Promoted to 3D from EPSG:32631"]] ```
2020-10-08Make GeographicCRS::is2DPartOf3D() work with DatumEnsembleEven Rouault
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-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-19WKT1 ingestion: fix ingestion of COMPD_CS with ellipsoidal vertical datum ↵Even Rouault
and non metre units (contributes to fixes #2232)
2020-05-16Adjustments to deal with non-conformant WKT1 LAS COMPD_CS[] (refs #2171)Even Rouault
2020-05-16Allow importing WKT1 COMPD_CS with a VERT_DATUM[Ellipsoid,2002], and ↵Even Rouault
exporting it back as such (on the same object) (fixes #2228)
2020-05-15Merge pull request #2224 from rouault/fix_2202Even Rouault
Make projinfo --3d --boundcrs-to-wgs84 better work (fixes #2202)
2020-05-15Make projinfo --3d --boundcrs-to-wgs84 better work (fixes #2202)Even Rouault
2020-05-14BoundCRS::create(): simplifyEven 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-23io.hpp: avoid dependency to proj_json_streaming_writer.hpp (fixes #2182) (#2183)Even Rouault
2020-04-21Add limited support for non-conformant WKT1 LAS COMPD_CS[] (#2171)Even Rouault
* Allow importing EPSG:{horizontal_code}+{geographic_code} and turn it into valid Geographic 3D or Projected 3D CRS internally * Allow importing WKT1 COMPD_CS[] with above structure * On an object imported that way, allow exporting to WKT1_GDAL, with this non-standard structure of a horizontal CRS + geographic CRS
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-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-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-25CompoundCRS::create(): reject combinations of components not allowed by ISO ↵Even Rouault
19111
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-10createOperations(): fix dealing with projected 3D CRS whose Z units != metreEven Rouault
2020-01-10Doc of CRS::identify(): make it clear that this is a best-effort attempt onlyEven Rouault
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-13Fix compilation breakage of previous commit with some compilersEven Rouault
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-11-25Merge pull request #1737 from rouault/proj_create_derived_geographic_crsKristian Evers
Add proj_create_derived_geographic_crs() and proj_create_conversion_pole_rotation_grib_convention() to address GRIB datasets using a pole rotation method
2019-11-25Doc: change 7.0 references to 6.3Even Rouault
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-11-22Add proj_create_derived_geographic_crs() and ↵Even Rouault
proj_create_conversion_pole_rotation_grib_convention() to address GRIB datasets using a pole rotation method
2019-11-14import/export PROJJSON: support a interpolation_crs key to geoid_model for ↵Even Rouault
faithful serialization of the geoid_geog_crs parameter of proj_create_vertical_crs_ex()
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-16 08:11:30 +0000