aboutsummaryrefslogtreecommitdiff
path: root/src/iso19111/crs.cpp
AgeCommit message (Collapse)Author
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-09Doc: document oddity related to identification of CRS from ESRI WKTEven Rouault
Or more generally formulations that don't have an explicit axis order. Refs https://github.com/pyproj4/pyproj/issues/475 projinfo 'GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]' returns EPSG:4326 with 100% confidence. But its axis order is not the same as EPSG:4326. I've pondered about this, like decreasing the confidence of the match, but this would have downstream effects on GDAL (shapefiles with the above content in a .prj would no longer be identified as EPSG:4326). So for now, document that oddity.
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-09-15API: add CRS::promoteTo3D(), proj_crs_promote_to_3D() and ↵Even Rouault
proj_crs_create_projected_3D_crs_from_2D() (fixes #1587) (projinfo changes adding --3d from master removed)
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-08-10PROJJSON: a few fixes, and add import of DerivedCRS, EngineeringCRS, ↵Even Rouault
ParametricCRS and TemporalCRS
2019-08-10PROJJSON: add support for DatumEnsemble and ↵Even Rouault
Dynamic[Geodetic|Vertical]ReferenceFrame
2019-08-09PROJSJON: add import/export of VerticalCRS, CompoundCRS, BoundCRS, ↵Even Rouault
Transformation and ConcatenatedOperation
2019-08-09PROJJSON export: use more compact formEven Rouault
2019-07-08CRS JSON: export GeographicCRS and Projected CRSEven Rouault
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-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-26crs.cpp: make it clear to analyzer that buffer will not overflow. Coverity ↵Even Rouault
CID 193528 and 193540
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-25crs.cpp: remove non-intented (harmless here) pass by reference of a pointerEven Rouault
2019-03-17Fix some issues raised by latest cppcheckEven Rouault
- coordinateoperation_internal.hpp: missing 'explicit' keyword - proj.cpp: unused 'generic' member in enumeration - init.cpp: useless assignment to a_orig and es_orig, because done again a few lines below. - crs.cpp: unused variable - datum.cpp: inefficient use of find() function - io.cpp: * missing 'static' qualifier for method * useles ternary test (left and right have same value) - aeqd.cpp: useless assignment of inv and fwd, snice done again a few lines below - isea.cpp: useless assignment of resolution and aperture since done again a few lines below, and with default values when params are absent - mod_ster.cpp: useless assignment of lp.lam, overriden in below code paths. - stere.cpp: false positive, but better not modify another variable than the iterator in a for() loop.
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-20CoordinateOperation: add a hasBallparkTransformation() method that can be ↵Even Rouault
used to know if it includes a very approximative transformation term
2019-02-17Modify the default strategy of researching intermediate CRS to do it only if ↵Even Rouault
there is no direct transformation
2019-01-22Coordinate operation computation with CRS with extension string: replace ↵Even Rouault
datum by ellps
2019-01-22Coordinate operation computation with boundcrs / wktext: drop useless early ↵Even Rouault
bindins terms in generated pipeline (fixes #1232)
2019-01-18Merge pull request #1223 from rouault/unify_proj_createKristian Evers
Unify proj_create(), proj_create_from_user_input() and proj_create_from_proj_string() (fixes #1214)
2019-01-17Remove wrong use of PROJ_CONST_DECL and replace it with PROJ_PURE_DECL ↵Even Rouault
(fixes #1224)
2019-01-17import/export PROJ strings from ISO19111 code: require/output +type=crs for ↵Even Rouault
CRS objects (refs #1214)
2019-01-09createOperations(): fix a particular case of boundcrs to boundcrs ↵Even Rouault
transformation (fixes #1220)
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
2019-01-02Typo fixesEven Rouault
2018-12-26cpp conversion: move source files in apps/ iso19111/ conversions/ ↵Even Rouault
projections/ transformations/ tests/ subdirectories
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-31 06:21:24 +0000