| 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)
|
|
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
|
|
verticalCRS to a 2D CRS
|
|
handling of +key=string_value parameters
|
|
Backport #1633 to 6.2
|
|
pipelines at end
|
|
Rename CS template argument, to avoid conflict with macro in Solaris system headers.
Similar to 2f8bd934860b135044c5122e3272f7cc41ba81e7
|
|
[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)
|
|
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.
|
|
|
|
with longitudes outside of [-180,180]
|
|
|
|
+datum=NAD27 and +over, where the datum was just replaced by its ellipsoid
|
|
|
|
lowercase. This showed in MapServer use cases
|
|
database (fixes #1565)
|
|
Add CRS JSON export (refs #1545)
|
|
to exported PROJJSON strings
|
|
|
|
ParametricCRS and TemporalCRS
|
|
Dynamic[Geodetic|Vertical]ReferenceFrame
|
|
|
|
Transformation and ConcatenatedOperation
|
|
|
|
|
|
Closes #1519
|
|
|
|
|
|
proj_concatoperation_get_step()
|
|
- Import scope and remarks for coordinate operations of the EPSG dataset.
Database size goes from 5.2 MB to 5.55 MB
- Add proj_get_scope() and proj_get_remarks()
|
|
Fix compilation error with gcc 4.9.3 (fixes #1512)
|
|
|
|
|
|
WKT1 importer: do case insensitive comparison for axis direction
|