| Age | Commit message (Collapse) | Author |
|---|
|
Fix datum names when importing from PROJ4 crs strings (affects some transformations using geoidgrids)
|
|
transformations using geoidgrids)
When importing from a PROJ4 string with +towgs84, +nadgrids or
+geoidgrids terms, the datum name was just set to 'unknown'. So for
example the datums of '+proj=longlat +ellps=GRS80 +towgs84=1,2,3' and
'+proj=longlat +ellps=GRS80 +towgs84=4,5,6' were considered identical,
because they had the same name 'unknown' and used the same ellipsoid.
This affected the transformation of such CRS when they had an
additional +geoidgrids term, which resulted in an erroneous +proj=push
+v_1 +v_2 step to be added to preserve the horizontal coordinates.
|
|
createOperations(): fix transformation involving CompoundCRS, ToWGS84 and PROJ4_GRIDS
|
|
PROJ4_GRIDS
Fix issue reported in https://lists.osgeo.org/pipermail/gdal-dev/2022-March/055587.html
|
|
fdf5111a9a790926aacec75a07d30508a8ed9c91 changes
|
|
Transformation: no longer do vertical trasnformation when doing compound CRS to 2D CRS / add --3d to cs2cs
|
|
Fix comparison of GeodeticRefrenceFrame vs DynamicGeodeticReferenceFrame
|
|
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.
|
|
If comparing a DynamicGeodeticReferenceFrame object and its export to
WKT1, which is a simple DATUM object, currently in non-strict comparison
mode, we'd consider the datum to be equivalent to the dynamic datum, but
not the reverse, which breaks the symmetric property of the
isEquivalentTo() operation. So fix this, to consider both equivalent
whatever the operand order.
(in strict mode, the objects will be considered different of course)
Spotted in the GDAL GeoTIFF CRS reader code:
https://github.com/OSGeo/gdal/blob/f9d48bdcc8c90df20e53b5af5785f1e5d78910db/frmts/gtiff/gt_wkt_srs.cpp#L832
Do same change for vertical datum vs dynamic vertical datum.
|
|
unitconvert: round to nearest date when converting to yyyymmdd.
|
|
DOC: Add missing lat_0 parameter to gnomonic documentation.
|
|
|
|
|
|
DOCS: add missing functions from filemanager.cpp
|
|
Add doxygen entries for:
- proj_context_set_file_finder
- proj_context_set_ca_bundle_path
Fixes #2540
|
|
This resolves an issue where converting from a low-precision decimalyear
to yyyymmdd gave the wrong result, due to mjd_to_yyyymmdd() truncating
away the fractional time component.
This commit changes the behaviour of mjd_to_yyyymmdd() to round to the
nearest date, instead of truncating.
Refs #1483
|
|
createOperations(): fix issue in transformation northing,easting projected CRS -> +proj=longlat +lon_wrap (fixes #3095)
|
|
CMake: fix installation of proj.pc on Windows (fixes #3078)
|
|
CRS -> +proj=longlat +lon_wrap (fixes #3095)
|
|
nkg.gie: update results due to https://github.com/OSGeo/PROJ-data/pull/79
|
|
|
|
|
|
Fix issues with WKT of concatenated operations (#3076)
|
|
Database: update to EPSG v10.055
|
|
|
|
needed (refs #3076)
|
|
compound CRS of a projected CRS (fixes #3076)
|
|
Fix issue when transforming from/to BoundCRS of 3D CRS with non-Green…
|
|
|
|
prime meridian, created from WKT (fixes OSGeo/gdal#5408)
|
|
|
|
CMake: handle potentially undefined value in list function
|
|
|
|
|
|
Fix wrong results with SQLite 3.38.0 (fixes #3077)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Bas Couwenberg <sebastic@xs4all.nl>
|
|
|
|
Fix various issues found by Coverity scan
|
|
|
|
383362)
|
|
deref (CID 383356)
|
|
383358)
|
