| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
PROJ4_GRIDS
Fix issue reported in https://lists.osgeo.org/pipermail/gdal-dev/2022-March/055587.html
|
|
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.
|
|
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
|
|
CRS -> +proj=longlat +lon_wrap (fixes #3095)
|
|
nkg.gie: update results due to https://github.com/OSGeo/PROJ-data/pull/79
|
|
|
|
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)
|
|
|
|
|
|
seems available (fixes #3060)
|
|
They are no longer needed, as there were only used by autoconf builds.
For CMake, we either use external googletest, or use CMake download capabilities.
|
|
square or diamond. Follow-up of #3014. Fixes #3056. master only
|
|
MapServer/MapServer#6478)
|
|
Cf thread https://lists.osgeo.org/pipermail/gdal-dev/2022-February/thread.html#55391
|
|
DerivedGeographicCRS coming from WKT
|
|
When pkg-config is called with --static, it will recursively collect
all Libs and Libs.private which are discovered via Requires and
Requires.private. So these libs must be available for linking even
when acutally only lib proj uses static linkage.
Libs and pkg-config must be provided for the target triplet.
|
|
If proj_create() catches a ParsingException, and the error code hasn't
otherwise been set internally, set the error code to
PROJ_ERR_INVALID_OP_WRONG_SYNTAX instead of allowing it to default to
the generic PROJ_ERR_OTHER.
Ref #2529
|
|
|
|
|
|
|
|
Fixes https://github.com/qgis/QGIS/issues/45470
That is, if the file for the old PROJ name is not found, but the file
for the new PROJ name is found, then use the later for fullFilename and
gridAvailable.
|
|
|
|
Implement Geographic3D to Depth/Geog2D+Depth as used by ETRS89 to CD Norway depth
|
|
inversion method
|
|
|
|
(fixes #3011)
|
|
proj_get_crs_info_list_from_database(): report PJ_TYPE_GEODETIC_CRS for IAU_2015 -ocentric geodetic CRS (fixes #3012)
|
|
IAU_2015 -ocentric geodetic CRS (fixes #3012)
|
|
depth
Fixes #2739
Verified with example from IOGP Guidance Note 7-2 (ver 62, Dec 2021) page 169, with
38 = h_obs - D_obs = 50 - 12.
$ echo 60.0015 4.9960 38 | PROJ_LIB=data PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:4937 EPSG:9883
60.0015 4.9960 5.8827
$ echo 60.0015 4.9960 38 | PROJ_LIB=data PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:4937 EPSG:4258+9672
60.0015 4.9960 5.8827
$ echo 60.0015 4.9960 5.8827 | PROJ_LIB=data PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:9883 EPSG:4937
60.0015 4.9960 38.0000
$ echo 60.0015 4.9960 5.8827 | PROJ_LIB=data PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:4258+9672 EPSG:4937
60.0015 4.9960 38.0000
|
|
EPSG 10.044 which adds a direct transformation between WGS84 and JGD2011
|
|
This fixes the current forward implementation of Peirce Quincuncial proj to correctly flip/reflect out the southern hemisphere to four triangles, and rotate entire result to a square or diamond. (It there resolves the issues identified with pull request https://github.com/OSGeo/PROJ/pull/2230 , where southern hemisphere was wrongly projected over northern, and reverses the restriction to northern hemisphere introduced there). It also adds additional lateral projection of the hemispheres.
- This PR adds an optional parameter `+type` which allows selection of projection. The `+type=square` and `+type=diamond` types match in principle ESRI's twin implementations of square and diamond PQ projs. The **default** if not specified is `+type=diamond`.
- The previous behaviour restricted to the northern hemisphere can be reproduced using the `+type=nhemisphere`, though this is an edge case only.
- An additional `+type=horizontal` and `+type=vertical` rectangular lateral versions have been added that place each hemisphere side-by-side. This is primarily to allow creation of projections such as Greiger Triptychial, which also require the additional optional params `scrollx` or `scrolly` in order to shift parts of the projection from one side of the map to the other.
- Additional documentation has been added to proj description, including quoting the usual meridian used in common usage of projection, and images showing the different types.
|
|
CMake: fix warning with external googletest
|
|
by setting its value from the azimuth angle.
and on export to PROJ.4 string do not emit a erroneous +gamma=0 when the
parameter it is missing.
Fixes https://lists.osgeo.org/pipermail/proj/2021-December/010475.html
|
|
Recent CMake versions throw the following warning when building
googletest 1.8.1. Bumping to 1.11.0 that has a minimum version of 2.8.12
fixes that
```
CMake Deprecation Warning at build/googletest-src/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.
```
|
|
createOperations(): improvement for "NAD83(CSRS) + CGVD28 height" to "NAD83(CSRS) + CGVD2013(CGG2013) height"
|
|
"NAD83(CSRS) + CGVD2013(CGG2013) height"
That transformation involves doing CGVD28 height to CGVD2013(CGG2013)
height by doing:
- CGVD28 height to NAD83(CSRS): EPSG registered operation
- NAD83(CSRS) to CGVD2013(CGG2013) height by doing:
* NAD83(CSRS) to NAD83(CSRS)v6: ballpark
* NAD83(CSRS)v6 to CGVD2013(CGG2013): EPSG registered operation
|
|
|
|
performance pattern on hostile pipelines
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41290
|
|
|
|
createOperations(): do not stop at the first operation in the PROJ namespace for vertical transformations
|
|
transformation operations (#2914)
Fixes #2512
|
|
for vertical transformations
In particular helps with transformation between "NAD83 + NAVD88 height" and WGS 84 that
have regressed in 8.2.0
Fixes #2936
|
|
The test made an assumption of being able to open 1024 - 50 files. On
some platforms, like older Darwin, the default limit is only 256. To
avoid the issue entirely we retrieve the current limit for the process.
We decrease the OPEN_MAX limit if it's too high. On some platforms fopen
returned nullptrs before reaching the limit (-50) and this doesn't
happen if we decrease the limit to 1024.
|
|
|
