aboutsummaryrefslogtreecommitdiff
path: root/src/iso19111/operation
AgeCommit message (Collapse)Author
2022-03-18createOperations(): fix transformation involving CompoundCRS, ToWGS84 and ↵Even Rouault
PROJ4_GRIDS Fix issue reported in https://lists.osgeo.org/pipermail/gdal-dev/2022-March/055587.html
2022-03-16Transformation: no longer do vertical trasnformation when doing compound CRS ↵Even Rouault
to 2D CRS / add --3d to cs2cs Previously, when computing transformation between a compound CRS and a geographic/projected 2D CRS, the behaviour was similar to implicitly promoting the 2D CRS to 3D CRS in the pipeline computation logic, hence a geoid model could be applied. But note that when doing a geographic 3D to geographic/projected 2D CRS transformation, we *did* not do this implicit promotion and if a Helmert transformation existed between the datums, it was done only in 2D. So this is a bit inconsistent and triggered the comment in https://github.com/OSGeo/PROJ/issues/2318#issuecomment-1068924513 With this commit, we no longer do any vertical transformation when doing compound CRS to the 2D CRS, but just take the transformation of the horizontal part of the compound CRS to the 2D CRS. Said otherwise, NAD83+NAVD88 to NAD83 will no longer lead to the application of the geoid model. Unless you explicitly ask for the promotion NAD83 to 3D. Also related, in https://github.com/OSGeo/PROJ/issues/1563 that went to 6.3.0, I changed cs2cs to automatically promote to 3D the CRS as soon as one of them was compound, for the sake of being consistent with the past behaviour. But it then becomes difficult to predict PROJ behaviour depending on which level of it you consider... This commit undoes that and adds an explicit --3d switch to cs2cs, similarly to projinfo, to ask for promotion. Other bug fix found in the process, when using legacy syntax, +init=epsg:4979, (WGS 84 3D), the resulting CRS was 2D and not 3D.
2022-03-09PROJBasedOperation PROJJSON export: issues an empty 'parameters' array if ↵Even Rouault
needed (refs #3076)
2022-03-09Fix import of WKT of concatenated operation with inverse conversion of a ↵Even Rouault
compound CRS of a projected CRS (fixes #3076)
2022-02-22geog3DToVertTryThroughGeog2D(): avoid potential nullptr deref (CID 383355)Even Rouault
2022-02-14Better deal with importing strings like '+init=epsg:XXXX +over' (refs ↵Even Rouault
MapServer/MapServer#6478)
2022-02-09createOperations(): fix transformations from/to a BoundCRS of a ↵Even Rouault
DerivedGeographicCRS coming from WKT
2022-01-12Conversion::_exportToPROJString(): fix potential crash introduced in recent ↵Even Rouault
commit. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43546
2022-01-12Merge pull request #3010 from rouault/fix_2739Even Rouault
Implement Geographic3D to Depth/Geog2D+Depth as used by ETRS89 to CD Norway depth
2022-01-07Map peirce_q to pseudo WKT2 and ESRI WKTEven Rouault
2022-01-06Implement Geographic3D to Depth/Geog2D+Depth as used by ETRS89 to CD Norway ↵Even Rouault
depth Fixes #2739 Verified with example from IOGP Guidance Note 7-2 (ver 62, Dec 2021) page 169, with 38 = h_obs - D_obs = 50 - 12. $ echo 60.0015 4.9960 38 | PROJ_LIB=data PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:4937 EPSG:9883 60.0015 4.9960 5.8827 $ echo 60.0015 4.9960 38 | PROJ_LIB=data PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:4937 EPSG:4258+9672 60.0015 4.9960 5.8827 $ echo 60.0015 4.9960 5.8827 | PROJ_LIB=data PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:9883 EPSG:4937 60.0015 4.9960 38.0000 $ echo 60.0015 4.9960 5.8827 | PROJ_LIB=data PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:4258+9672 EPSG:4937 60.0015 4.9960 38.0000
2022-01-04Handle EPSG:1111 'Transverse Mercator (3D)' method (used in EPSG:10.044 by ↵Even Rouault
Projected 3D CRS EPSG:9895 'Luxembourg TM (3D)'
2022-01-04Fix doc generation with Doxygen 1.9.3Even Rouault
Since the update to Doxygen 1.9.3, doc generation was broken. With bisection of doxygen, it was found this was due to commit https://github.com/doxygen/doxygen/commit/ee8f3fb7a2ed74ee30ae3202707617e97f6641ff which makes Doxygen honour nested @cond . This revealed bad pairing of @cond / @endcond in our code, fixed by this commit.
2021-12-16WKT1 import: correctly deal with missing rectified_grid_angle parameterEven Rouault
by setting its value from the azimuth angle. and on export to PROJ.4 string do not emit a erroneous +gamma=0 when the parameter it is missing. Fixes https://lists.osgeo.org/pipermail/proj/2021-December/010475.html
2021-12-08createOperations(): improvement for "NAD83(CSRS) + CGVD28 height" to ↵Even Rouault
"NAD83(CSRS) + CGVD2013(CGG2013) height" That transformation involves doing CGVD28 height to CGVD2013(CGG2013) height by doing: - CGVD28 height to NAD83(CSRS): EPSG registered operation - NAD83(CSRS) to CGVD2013(CGG2013) height by doing: * NAD83(CSRS) to NAD83(CSRS)v6: ballpark * NAD83(CSRS)v6 to CGVD2013(CGG2013): EPSG registered operation
2021-11-15createOperationsGeogToGeog(): avoid potential harmless floating-point ↵Even Rouault
division by zero. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41045
2021-11-14Merge pull request #2938 from rouault/fix_ossfuzz_40955Even Rouault
createOperationsCompoundToCompound(): fix null pointer dereference when connection to proj.db doesn't exist.
2021-11-12createOperationsCompoundToCompound(): fix null pointer dereference when ↵Even Rouault
connection to proj.db doesn't exist. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40955
2021-11-11createOperations(): do not stop at the first operation in the PROJ namespace ↵Even Rouault
for vertical transformations In particular helps with transformation between "NAD83 + NAVD88 height" and WGS 84 that have regressed in 8.2.0 Fixes #2936
2021-11-09Reformatting fixesEven Rouault
2021-11-04Database: update to EPSG v10.039Even Rouault
2021-10-17exportToPROJStringGeneric(): avoid harmless floating-point division by zero ↵Even Rouault
if conversion factor is 0. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40050
2021-10-16createOperations(): avoid harmless floating-point division by zero if ↵Even Rouault
conversion factor of target unit is 0. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39969
2021-10-08WKT1 parser: recognize Lambert_Conformal_Conic as projection name for LCC ↵Even Rouault
1SP or 2SP (fixes #2892)
2021-10-08WKT concatenated operation parsing: fix when a axis order reversal ↵Even Rouault
conversion is the first or last operation (fixes #2890)
2021-09-20Conversion::inverse(): avoid harmless division by zero. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39033
2021-09-18Optimize pipelines of planetary CRS (geocentric latitude, west-positive ↵Even Rouault
longitude)
2021-09-15Database: update to EPSG v10.035Even Rouault
This seriously impacts French CRS users with the introduction of new datums, geodetic CRS and projected CRS based on "RGF 93 v2" and "RGF 93 v2b", and the previous single "RGF 93" being renamed as "RGF 93 v1". To be noted too, the addition of a null transformation between NAD83(2011) and WGS 84, which impacts a number of tests in the test suite.
2021-09-08createOperations(): use an explicit conversion operation for geodetic <--> ↵Even Rouault
geocentric latitude
2021-09-08createConversion(): avoid nullptr dereference on a method without parametersEven Rouault
2021-09-08createOperations(): deal with spherical planetocentric geodetic CRSEven Rouault
This also fixes conversion between geocentric latlong and geodetic latlong with cs2cs. This was dealt with in PR 1093, but in the wrong direction (the geocentric latitude must be <= in absolute value to the geodetic one) The issue here was linked to the semantics of the +geoc specifier, which affects the semantics of the input coordinates in the forward direction (+geoc means that the input coordinate is is a geocentric latitude), which defeats the logic of doing A to B by using the inverse path of A and the forward path of B.
2021-09-04Conversion::createAxisOrderReversal(): workaround cppcheck false positiveEven Rouault
2021-09-02Add proj_create_conversion_pole_rotation_netcdf_cf_convention() to address ↵Even Rouault
netCDF datasets using a pole rotation method
2021-08-27ESRI WKT: add support for import/export of (non interrupted) Goode HomolosineEven Rouault
Issue found during https://github.com/OSGeo/gdal/pull/4355 when it was found that a WKT with Goode_Homolosine projection parsed as ESRI WKT was mapped wrongly to Interrupted Goode Homolosine
2021-08-20ConcatenatedOperation::fixStepsDirection(): fix bad chaining of steps when ↵Even Rouault
inverse map projection is involved in non-final step (fixes #2817)
2021-08-16createOperations(): fix missing deg<-->rad conversion when transforming with ↵Even Rouault
a CRS that has a fallback-to-PROJ4-string behaviour and is a BoundCRS of a GeographicCRS (fixes #2804)
2021-08-10Conversion::createUTM(): avoid integer overflow. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36751
2021-07-20createOperations(): fix SourceTargetCRSExtentUse::NONE modeEven Rouault
Fix issue reported in https://lists.osgeo.org/pipermail/proj/2021-July/010318.html
2021-07-20Formatting fix [ci skip]Even Rouault
2021-07-13Add S2 projection (#2749)marcus-elia
2021-07-07createOperations(): make sure to associate an extent to the transform of a ↵Even Rouault
CRS with a GEOIDMODEL using a PROJ grid, so that it is later used instead of a ballpark operation (fixes #2768)
2021-05-27ConcatenatedOperation::fixStepsDirection(): remove recently introdued hack ↵Even Rouault
specific to EPSG:9731 now that is is deprecated
2021-05-16Database: update to EPSG v10.022Even Rouault
2021-05-12Fix export of transformation to PROJ string in a particular situation where ↵Even Rouault
CompoundCRS are involved (fixes #2720)
2021-05-04DOC: configure and add spelling wordlist; fix typos, apply Sphinx syntax (#2705)Mike Taves
2021-04-23Database: update to EPSG v10.019Even Rouault
Non-trivial updates: - some vertical CRS are now encoded as DerivedVerticalCRS. e.g EPSG:8228 "NAVD88 height (ft)", with base EPSG:5703 "NAVD88 height". As we don't have support in our PROJ db model for DerivedVerticalCRS, modify the import script to 'resolve' the derivation up to the original datum. - Method EPSG:1069 'Change of Vertical Unit' is no longer used. It is replaced by a generic-purpose EPSG:1104 method that doesn't take any conversion factor. And generic conversions EPSG:7812 and EPSG:7813 are now used in concatenated operations, which require code changes as well.
2021-04-22ConcatenatedOperation::fixStepsDirection(): fix potential nullptr dereferenceEven Rouault
2021-04-05createOperations(): make ↵Even Rouault
createBetweenGeodeticCRSWithDatumBasedIntermediates() reachable... ... and optimize its execution time by rewriting it completely. This code path was no longer triggered in tests since EPSG got a direct transformation for GDA94 to WGS 84 (G1762).
2021-04-03Add mapping between EPSG method 'Hyperbolic Cassini-Soldner' and +proj=cass ↵Even Rouault
+hyperbolic
2021-04-01Database: update to EPSG 10.017Even Rouault
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-30 13:31:37 +0000