aboutsummaryrefslogtreecommitdiff
path: root/src
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-12Fix proj_assign_context()/pj_set_ctx() with pipelines and alternative coord ↵Even Rouault
operations Fixes https://github.com/OSGeo/gdal/issues/1989 pj_set_ctx() only changes the context to the main object. It should also recurse down to the steps of the pipeline and the alternative coordinate operations hold in alternativeCoordinateOperations In the GDAL use case with multithreaded reprojection, and objects being transferred between thread, this would cause a failed coordinate transformation to affect an unrelated transformation of another thread...
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-11-03createOperations(): in some circumstances we wrongly promoted a Helmert ↵Even Rouault
geog2D transformation to a geog3D Fixes for example EPSG:4979 to EPSG:2189, as raised in https://github.com/OSGeo/gdal/issues/1972#issuecomment-548814354
2019-10-30createFromWkt(): be tolerant to missing scale_factor parameter (fixes #1700)Even Rouault
This is invalid WKT, but GDAL 2.4 used to accept it and make a reasonable use of it... Currently we default it to 0 which is non sensical. Better use 1 as GDAL 2.4 did, and emit a warning. Other fix: proj_create_from_wkt() was documented to operate by default in non-strict validation mode, but it was actually in strict mode. So do as documented.
2019-10-28Update version numbers for 6.2.16.2.1Kristian Evers
2019-10-28Update ABI version numbers for 6.2.1 releaseKristian Evers
2019-10-25importFromWkt(): fix axis orientation for non-standard ESRI WKT (fixes #1690)Even Rouault
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-10-18[Backport 6.2] Fix segfaults in case of out-of-memory situations (#1684) ↵backporting[bot]
(fixes #1678)
2019-10-03ob_tran.cpp: add comment to link maths with Snyder's formulasEven Rouault
2019-10-12createOperations(): allow transforming from a compoundCRS of a bound ↵Even Rouault
verticalCRS to a 2D CRS
2019-10-03aeqd: for spherical forward path, go to higher precision ellipsoidal case ↵Even Rouault
when the point coordinates are super close to the origin (fixes #1654)
2019-09-28PROJ string CRS ingester: recognize more unit-less parameters, and general ↵Even Rouault
handling of +key=string_value parameters
2019-09-28Merge pull request #1636 from OSGeo/backport-1633-to-6.2Even Rouault
Backport #1633 to 6.2
2019-09-28createOperations() sorting: sort operations that cannot be exported as PROJ ↵Even Rouault
pipelines at end
2019-09-26proj_create_crs_to_crs(): fix when there are only transformations with ↵Even Rouault
ballpark steps Currently we would discard all operations, resulting in a PJ object with zero candidates. Better use those operations if nothing better is available. Was seen on transforming from ETRS89 / UTM zone 31N + EGM96 height to WGS 84 (G1762). The horizontal transformation from ETRS89 to WGS 84 (G1762) is a ballpark one.
2019-09-25isea: avoid shadowing warning on 'quad' on SolarisEven Rouault
Patch proj-6.2.0-isea.gpatch by Eric Dechaux
2019-09-25hatano/mbtfpp: do not use CS to fix Solaris build issueEven Rouault
Patches proj-6.2.0-hanato.gpatch and proj-6.2.0-mbtfpp.gpatch from Eric Dechaux
2019-09-24io.cpp: fix build on SolarisEven Rouault
Rename CS template argument, to avoid conflict with macro in Solaris system headers. Similar to 2f8bd934860b135044c5122e3272f7cc41ba81e7
2019-09-17ell_set.cpp: avoid division by zero in R_lat_a case. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16130
2019-09-17helmert: validate scale parameter to avoid later division by zero. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16106
2019-09-17aea_e_inverse(): avoid calling asin() with invalid argument which results in ↵Even Rouault
NaN being propagated. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15336
2019-09-17pj_Convert_Geocentric_To_Geodetic(): avoid division by zero on weird input ↵Even Rouault
coordinates and ellipsoid values. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15148&
2019-09-17isea: avoid undefined behaviour on left shift of negative value. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15009
2019-09-17pj_Convert_Geocentric_To_Geodetic(): avoid division by zero on weird input ↵Even Rouault
coordinates and ellipsoid values. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14766
2019-09-17geos: avoid division by zero. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14666
2019-09-17eqdc: avoid potential division by zero. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17190
2019-09-03Debug Bertin1953R. Schmunk
Northern hemisphere "warp" implemented incorrectly. See #1579
2019-09-16[6.2 backport] cs2cs: autopromote CRS to 3D when there's a mix… (#1615)Kristian Evers
[6.2 backport] cs2cs: autopromote CRS to 3D when there's a mix of 2D and 3D (fixes #1563)
2019-09-15cs2cs: autopromote CRS to 3D when there's a mix of 2D and 3D (fixes #1563)Even Rouault
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-09-15DatabaseContext::lookForGridInfo(): avoid setting PROJ context errno. Fixes ↵Even Rouault
issue with test/gigs/5208.gie with previous commit when ntf_r93.gsb grid is not available
2019-09-15createFromPROJString(): ignore +no_defs when instanciating a ↵Even Rouault
'+init=epsg:xxxx +no_defs' string (related to #1597)
2019-09-15Ingestion of +proj=somerc +type=crs: avoid adding twice alpha, gamma, lon_0 ↵Even Rouault
(related to #1597)
2019-09-15[Backport 6.2] Improve vertical transforms (#1613)Kristian Evers
[Backport 6.2] Improve vertical transforms
2019-09-13createOperations(): when tranforming from a compoundCRS whose vertical ↵Even Rouault
component is a BoundCRS, do not apply the horizontal transformation twice
2019-09-13createOperations(): use more candidates when transforming between a ↵Even Rouault
geographic and vertical CRS For example when transforming from NAD83+NAVD88 height to WGS84, there is no transformation between NAVD88 height to WGS84. In that case, use all potential transformations from NAVD88 height to another geographic CRS for the vertical part.
2019-09-13createOperations(): make sure sorting function is transitive (a < b and b < ↵Even Rouault
c --> a < c), to get consistent results
2019-09-13Fix support for +proj=ob_tran +o_proj=lonlat/latlong/latlon (only ↵Even Rouault
+o_proj=longlat worked) (fixes #1601)
2019-09-12Merge pull request #1607 from OSGeo/backport-1604-to-6.2Even Rouault
[Backport 6.2] proj_trans_generic(): properly set coordinate time to HUGE_VAL when no value is passed to the function
2019-09-12proj_trans_generic(): properly set coordinate time to HUGE_VAL when no value ↵Even Rouault
is passed to the function
2019-09-11createOperations(): fix conversion from/to PROJ.4 CRS strings with ↵Even Rouault
non-ISO-cosher options and towgs84/nadgrids This actually fixes a regression introduced in PROJ 6.2.0 per 78302efb70eb4b49610cda6a60bf9ce39b82264f that made a conversion like EPSG:4326 to "+proj=something +towgs84/+nadgrids +over +type=crs" apply the towgs84/nadgrids operation twice.
2019-09-06Merge pull request #1594 from OSGeo/backport-1589-to-6.2Even Rouault
[Backport 6.2] PROJStringParser::createFromPROJString(): avoid potential infinite recursion (fixes #1574)
2019-09-06BUG: add SANITIZE_CTX for coordoperation is_instantiable and ↵snowman2
has_ballpark_transformation
2019-09-05PROJStringParser::createFromPROJString(): avoid potential infinite recursion ↵Even Rouault
(fixes #1574) The exact circumstances are a bit difficult to explain, but they involve using a non-default context, enabling proj_context_use_proj4_init_rules() on it, using proj_create(ctxt, "+init=epsg:XXXX +type=crs"), whereas PROJ_LIB is defined to a directory that has a 'epsg' file in it.
2019-09-04proj_create_crs_to_crs_from_pj(): make the PJ* arguments const PJ*Even Rouault
This will make the life of C++ users using the C API slightly easier. There's no ABI or API backward compatibility issue in doing that change as constness of arguments is not retained in the C ABI, and any non-const object passed as argument is implicitly converted as a const object if that is what is mentionned in the argument list.
2019-09-04proj_experimental.h: fix wrong comment forPJ_ELLIPSOIDAL_CS_2D_TYPE enumEven Rouault
2019-08-27Doc: add link to final WKT2:2019 documentEven Rouault
2019-08-30Fix spelling of potsdam datumKai Pastor