| Age | Commit message (Collapse) | Author |
|
Fix datum names when importing from PROJ4 crs strings (affects some transformations using geoidgrids)
|
|
createOperations(): fix transformation involving CompoundCRS, ToWGS84 and PROJ4_GRIDS
|
|
Fix comparison of GeodeticRefrenceFrame vs DynamicGeodeticReferenceFrame
|
|
[Backport 9.0] createOperations(): fix issue in transformation northing,easting projected CRS -> +proj=longlat +lon_wrap (fixes #3095)
|
|
unitconvert: round to nearest date when converting to yyyymmdd.
|
|
createOperations(): fix issue in transformation northing,easting projected CRS -> +proj=longlat +lon_wrap (fixes #3095)
|
|
Fix issues with WKT of concatenated operations (#3076)
|
|
Fix issue when transforming from/to BoundCRS of 3D CRS with non-Green…
|
|
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
|
|
|
|
|
|
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
|
|
|
|
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
|
|
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
|
|
"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
|
|
|
|
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.
|
|
|
|
Name was erroneously set (since 8.2.0) to SOURCECRS.
Raised in https://lists.osgeo.org/pipermail/gdal-dev/2021-November/054944.html
|
|
- Remove the explicit PROJ_MSVC_DLL_IMPORT symbol used for importing
symbols from a MSVC .dll: by default on MSVC, we use
now __declspec(dllimport), unless PROJ_MSVC_DLL_EXPORT is defined
by PROJ at build time. This makes it easier for users: they
don't have to define anything special. This simplifies in particular
the build of our binaries
- For static builds, export -DPROJ_DLL= as public, so that users
that import PROJ through CMake mechanism don't have to do it
manually.
|
|
- this bumps format_version of tinshift JSON to 1.1 for the new field
fallback_strategy
- the default behaviour without that field is retained
- if fallback_strategy is set to "nearest_side", then points that do not fall
into any of the triangles will be transformed according to the nearest
triangle
- if fallback_centroid is set to "nearest_side", then points that do not fall
into any of the triangles will be transformed according to the triangle
with the nearest centroid
|
|
Add transformations for GGM10, Mexican geoid model
|
|
(and thus extrapolating a VERTCS) (fixes #2757)
|
|
EPSG equivalent and have parentheses in their name
|
|
1SP or 2SP (fixes #2892)
|
|
conversion is the first or last operation (fixes #2890)
|
|
|
|
(fixes #2886)
|
|
EQUIVALENT mode if one of them is lacking an explicit CS order (refs #2886)
|
|
meridian is involved
This fixes a regression introduced in 7af1d5741da08d9546b907e0da2c21c54c61b27 / PROJ 7.2.0
where reprojection of area of use was broken when the source/target CRS
did not use Greenwich as prime meridian.
Fixes https://lists.osgeo.org/pipermail/gdal-dev/2021-October/054764.html
Now with the fix:
- using grid:
$ echo 286415 431434 | PROJ_NETWORK=ON src/cs2cs -d 4 EPSG:20790 EPSG:3763
86412.4262 131434.1706 0.0000
- not using it:
$ echo 286415 431434 | src/cs2cs -d 4 EPSG:20790 EPSG:3763
86412.5265 131433.8561 0.0000
|
|
|
|
transformation (#2882)
Fixes #2779
|
|
Add IAU_2015 CRS definitions
|
|
proj_factors(): accept P to be a projected CRS (fixes #2854)
|
|
Updated doc:
Starting with PROJ 8.2, the P object can be a projected CRS, for example
instantiated from a EPSG CRS code. The factors computed will be those of the
map projection implied by the transformation from the base geographic CRS of
the projected CRS to the projected CRS.
The input geodetic coordinate lp should be such that lp.lam is the longitude
in radian, and lp.phi the latitude in radian (thus independently of the
definition of the base CRS, if P is a projected CRS).
|
|
PROJ string with just the ellipsoid
|
|
refs OSGeo/gdal#3927)
|
|
|
|
pipelines
|