aboutsummaryrefslogtreecommitdiff
path: root/include/proj/crs.hpp
AgeCommit message (Collapse)Author
2019-12-16identify(): take into datum name aliases (fixes #1800)Even 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-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-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-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-08-09PROJSJON: add import/export of VerticalCRS, CompoundCRS, BoundCRS, ↵Even Rouault
Transformation and ConcatenatedOperation
2019-07-08CRS JSON: export GeographicCRS and Projected CRSEven Rouault
2019-03-29Add proj_normalize_for_visualization()Even Rouault
Fixes #1301 This function takes the output PJ from proj_create_crs_to_crs(), and add (or undo) the needed axis swap operations so that the object returned by proj_normalize_for_visualization() has the usual GIS axis order. In this implementation, this does something only if the coordinate system of the source or target CRS, geographic or projected, has NORTH, EAST ordering. CompoundCRS wrapping those objects are also handled.
2019-03-25crs.cpp: remove non-intented (harmless here) pass by reference of a pointerEven Rouault
2019-03-16Run scripts/reformat_cpp.shEven Rouault
2019-03-01Doc: rename to ISO-19111:2019Even Rouault
And publish link to corresponding promoted and public OGC doc: http://docs.opengeospatial.org/as/18-005r4/18-005r4.html
2019-02-17Modify the default strategy of researching intermediate CRS to do it only if ↵Even Rouault
there is no direct transformation
2019-01-22proj_create_crs_to_crs(): defer selection of actual coordinate operation ↵Even Rouault
until proj_trans() is called (fixes #1229)
2019-01-17Remove wrong use of PROJ_CONST_DECL and replace it with PROJ_PURE_DECL ↵Even Rouault
(fixes #1224)
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-02Typo fixesEven Rouault
2018-12-14Advanced C API: add proj_obj_alter_id()Even Rouault
2018-12-06Speed-up createBoundCRSToWGS84IfPossible()Even Rouault
2018-12-06Add API to retrieve non-deprecated equivalent of an objectEven 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-29cs2cs: upgrade to use proj_create_crs_to_crs()Even Rouault
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 2026-01-03 07:49:19 +0000