| Age | Commit message (Collapse) | Author |
|
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)
|
|
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...
|
|
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.
|
|
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
|
|
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.
|
|
|
|
|
|
|
|
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
|
|
(fixes #1678)
|
|
|
|
verticalCRS to a 2D CRS
|
|
when the point coordinates are super close to the origin (fixes #1654)
|
|
handling of +key=string_value parameters
|
|
Backport #1633 to 6.2
|
|
pipelines at end
|
|
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.
|
|
Patch proj-6.2.0-isea.gpatch by Eric Dechaux
|
|
Patches proj-6.2.0-hanato.gpatch and proj-6.2.0-mbtfpp.gpatch from Eric Dechaux
|
|
Rename CS template argument, to avoid conflict with macro in Solaris system headers.
Similar to 2f8bd934860b135044c5122e3272f7cc41ba81e7
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16130
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16106
|
|
NaN being propagated. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15336
|
|
coordinates and ellipsoid values. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15148&
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15009
|
|
coordinates and ellipsoid values. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14766
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14666
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17190
|
|
Northern hemisphere "warp" implemented incorrectly. See #1579
|
|
[6.2 backport] cs2cs: autopromote CRS to 3D when there's a mix of 2D and 3D (fixes #1563)
|
|
|
|
proj_crs_create_projected_3D_crs_from_2D() (fixes #1587)
(projinfo changes adding --3d from master removed)
|
|
issue with test/gigs/5208.gie with previous commit when ntf_r93.gsb grid is not available
|
|
'+init=epsg:xxxx +no_defs' string (related to #1597)
|
|
(related to #1597)
|
|
[Backport 6.2] Improve vertical transforms
|
|
component is a BoundCRS, do not apply the horizontal transformation twice
|
|
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.
|
|
c --> a < c), to get consistent results
|
|
+o_proj=longlat worked) (fixes #1601)
|
|
[Backport 6.2] proj_trans_generic(): properly set coordinate time to HUGE_VAL when no value is passed to the function
|
|
is passed to the function
|
|
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.
|
|
[Backport 6.2] PROJStringParser::createFromPROJString(): avoid potential infinite recursion (fixes #1574)
|
|
has_ballpark_transformation
|
|
(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.
|
|
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.
|
|
|
|
|
|
|