| Age | Commit message (Collapse) | Author |
|
result through ITRF2008. Was broken in master by the addition of the 'WGS84 -> WGS 84 (Gxxx)' null operations in the PROJ authority
|
|
alternatives, to select the operation with best accuracy
|
|
intermediate CRS if we found direct transformation(s) but had to eliminate them due to other criteria
|
|
distinguish null transform from ballpark transform
|
|
This was introduced in 63857c92b271bbcd10df0a032304982011acb2a9. Due to
the fix done in the previous commit, we can mostly revert the above commit.
We just keep the added tests and the custom WGS 84<-->WGS 84 (Gxxxx) null
transformations.
|
|
operations that belong to different authorities. Should make the concept of geodetic_datum_preferred_hub introduced some time ago obsolete
|
|
|
|
|
|
correctly the geographic coordinates of the input coord when the CRS is not Greenwich based
|
|
faithful serialization of the geoid_geog_crs parameter of proj_create_vertical_crs_ex()
|
|
+geoidgrids and +vunits != m
|
|
|
|
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
|
|
|
|
in CRS name
|
|
Better filtering based on extent and performance improvements
|
|
a proj_create_vertical_crs_ex()
|
|
|
|
|
|
rouault/improve_transformation_with_alternative_vertical_unit_and_direction
Improve transformations with alternative vertical unit and direction
|
|
are missing, especially for compound CRS. Helps having shorter/more relevant results
|
|
functional changes
|
|
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.
|
|
Height Depth Reversal and use it in createOperations()
|
|
'NAVD88 (ftUS)' to X, where we now consider the available transformations from 'NAVD88' to X that might exist in the database
|
|
functional change expected
|
|
transformations
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18587
|
|
|
|
HEAD/1.90dev happy (fixes #1648)
|
|
arbitrary number of steps (fixes #1632)
EPSG:9103 (NAD27 to ITRF2014 (1)) is now handled.
Note:EPSG:9104 (NAD27 to ITRF2014 (2)) is not currently, since it uses
for step EPSG:8861 (NAD83(HARN) to NAD83(FBN) (1))
an unsupported transformation method (NADCON5 (3D), EPSG:1075).
|
|
|
|
In recent commits, we added a generalize_proj_crs_create_bound_vertical_crs_to_WGS84()
function, but there are situations where more accurate results can be obtained, if
instead of specifying WGS84 as the hub CRS, the user can specify the exact hub CRS.
For example the GEOID2018 grid is against NAD83(2011).
So replace this function with proj_crs_create_bound_vertical_crs()
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17923. master only
|
|
createOperations(): fix double vertical unit conversion from CompoundCRS to other CRS when the horizontal part of the projected CRS uses non-metre unit
|
|
|
|
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
|
|
|
|
return null.
It is true for datum(), but does not apply to coordinateSystem().
|
|
ob_tran doc: fix/clarify semantics of o_lat_p/o_lon_p
|
|
rouault/fix_custom_compound_crs_with_NAD83_2011_and_geoidgrid_to_WGS84_G1762
proj_create_crs_to_crs(): remove elimination of Ballpark operations that caused transformation failures in some cases
|
|
verticalCRS to a 2D CRS
|
|
caused transformation failures in some cases
|
|
Add a proj_crs_demote_to_2D(). Useful if forced to export a 3D CRS to a best approximate as WKT1 that doesn't support it
|
|
aeqd: for spherical forward path, go to higher precision ellipsoidal case when the point coordinates are super close to the origin (fixes #1654)
|
|
approximate as WKT1 that doesn't support it
|