aboutsummaryrefslogtreecommitdiff
path: root/test/unit
AgeCommit message (Collapse)Author
2022-03-19Fix datum names when importing from PROJ4 crs strings (affects some ↵Even Rouault
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.
2022-03-18createOperations(): fix transformation involving CompoundCRS, ToWGS84 and ↵Even Rouault
PROJ4_GRIDS Fix issue reported in https://lists.osgeo.org/pipermail/gdal-dev/2022-March/055587.html
2022-03-17Merge pull request #3119 from rouault/compound_to_2D_crsEven Rouault
Transformation: no longer do vertical trasnformation when doing compound CRS to 2D CRS / add --3d to cs2cs
2022-03-16Merge pull request #3118 from rouault/dynamic_datum_isequivalenttoEven Rouault
Fix comparison of GeodeticRefrenceFrame vs DynamicGeodeticReferenceFrame
2022-03-16Transformation: no longer do vertical trasnformation when doing compound CRS ↵Even Rouault
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.
2022-03-16Fix comparison of GeodeticRefrenceFrame vs DynamicGeodeticReferenceFrameEven Rouault
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.
2022-03-11unitconvert: round to nearest date when converting to yyyymmdd.Brendan Jurd
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
2022-03-09createOperations(): fix issue in transformation northing,easting projected ↵Even Rouault
CRS -> +proj=longlat +lon_wrap (fixes #3095)
2022-03-09Fix import of WKT of concatenated operation with inverse conversion of a ↵Even Rouault
compound CRS of a projected CRS (fixes #3076)
2022-03-08Fix issue when transforming from/to BoundCRS of 3D CRS with non-Greenwhich ↵Even Rouault
prime meridian, created from WKT (fixes OSGeo/gdal#5408)
2022-02-14Fix importing CRS definition with +proj=peirce_q and +shape different from ↵Even Rouault
square or diamond. Follow-up of #3014. Fixes #3056. master only
2022-02-14Better deal with importing strings like '+init=epsg:XXXX +over' (refs ↵Even Rouault
MapServer/MapServer#6478)
2022-02-12proj.ini: add a 'ca_bundle_path' variableEven Rouault
Cf thread https://lists.osgeo.org/pipermail/gdal-dev/2022-February/thread.html#55391
2022-02-09createOperations(): fix transformations from/to a BoundCRS of a ↵Even Rouault
DerivedGeographicCRS coming from WKT
2022-02-01Use external gtest by default when detectedEven Rouault
2022-01-31Drop autotools; move remaining useful m4 macros (#3027)Mike Taves
2022-01-20lookForGridInfo(): make it work properly when passed the old PROJ nameEven Rouault
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.
2022-01-12Merge pull request #3010 from rouault/fix_2739Even Rouault
Implement Geographic3D to Depth/Geog2D+Depth as used by ETRS89 to CD Norway depth
2022-01-07Map peirce_q to pseudo WKT2 and ESRI WKTEven Rouault
2022-01-07Merge pull request #3013 from rouault/fix_3012Even Rouault
proj_get_crs_info_list_from_database(): report PJ_TYPE_GEODETIC_CRS for IAU_2015 -ocentric geodetic CRS (fixes #3012)
2022-01-06proj_get_crs_info_list_from_database(): report PJ_TYPE_GEODETIC_CRS for ↵Even Rouault
IAU_2015 -ocentric geodetic CRS (fixes #3012)
2022-01-06Implement Geographic3D to Depth/Geog2D+Depth as used by ETRS89 to CD Norway ↵Even Rouault
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
2022-01-04test proj_create_operations_with_pivot(): change CRSs used in preparation of ↵Even Rouault
EPSG 10.044 which adds a direct transformation between WGS84 and JGD2011
2021-12-16WKT1 import: correctly deal with missing rectified_grid_angle parameterEven Rouault
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
2021-12-08createOperations(): improvement for "NAD83(CSRS) + CGVD28 height" to ↵Even Rouault
"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
2021-11-15Code reformatEven Rouault
2021-11-14Merge pull request #2937 from rouault/fix_2936Even Rouault
createOperations(): do not stop at the first operation in the PROJ namespace for vertical transformations
2021-11-12Add new option to proj_create_crs_to_crs_from_pj method to force +over on ↵Peter Townsend
transformation operations (#2914) Fixes #2512
2021-11-11createOperations(): do not stop at the first operation in the PROJ namespace ↵Even Rouault
for vertical transformations In particular helps with transformation between "NAD83 + NAVD88 height" and WGS 84 that have regressed in 8.2.0 Fixes #2936
2021-11-10test: Make CApi test cross-platformtoonn
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.
2021-11-04Remove useless PROJ_DLL uses in .cpp files (#2920)Momtchil Momtchev
2021-11-03BoundCRS WKT import: fix setting of nameEven Rouault
Name was erroneously set (since 8.2.0) to SOURCECRS. Raised in https://lists.osgeo.org/pipermail/gdal-dev/2021-November/054944.html
2021-10-23CMake: revise how we deal with symbol export and static buildsEven Rouault
- 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.
2021-10-21Add fallback_strategy to tinshift transformJohannes Schauer Marin Rodrigues
- 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
2021-10-15Merge pull request #2889 from jjimenezshaw/mx_inegi_ggm10Even Rouault
Add transformations for GGM10, Mexican geoid model
2021-10-12Geographic 3D CRS: allow to export to WKT1:ESRI if only the GEOGCS is known ↵Even Rouault
(and thus extrapolating a VERTCS) (fixes #2757)
2021-10-12Fix export to WKT1:ESRI of CRS, datum, ellipsoids name that don't have a ↵Even Rouault
EPSG equivalent and have parentheses in their name
2021-10-08WKT1 parser: recognize Lambert_Conformal_Conic as projection name for LCC ↵Even Rouault
1SP or 2SP (fixes #2892)
2021-10-08WKT concatenated operation parsing: fix when a axis order reversal ↵Even Rouault
conversion is the first or last operation (fixes #2890)
2021-10-07extend unit test to find GGM10 for vcrs EPSG:5703Javier Jimenez Shaw
2021-10-06CRS::_isEquivalentTo(): be tolerant to different order of PROJ step options ↵Even Rouault
(fixes #2886)
2021-10-06ProjectedCRS::_isEquivalentTo(): ignore base CRS axis order even in ↵Even Rouault
EQUIVALENT mode if one of them is lacking an explicit CS order (refs #2886)
2021-10-06proj_create_crs_to_crs() + proj_trans(): fix when non-Greenwich prime ↵Even Rouault
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
2021-10-06test_c_api.cpp: reformatEven Rouault
2021-10-05Add proj_trans_bounds to compute the image of a input bounding box through a ↵Alan D. Snow
transformation (#2882) Fixes #2779
2021-10-05Merge pull request #2876 from rouault/iauEven Rouault
Add IAU_2015 CRS definitions
2021-10-05Merge pull request #2868 from rouault/proj_factors_with_projected_crsEven Rouault
proj_factors(): accept P to be a projected CRS (fixes #2854)
2021-09-30proj_factors(): accept P to be a projected CRS (fixes #2854)Even Rouault
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).
2021-09-29CRS::identify(): fix ignoring CS order when identifying a geodetic CRS by a ↵Even Rouault
PROJ string with just the ellipsoid
2021-09-28CRS::extractGeodeticCRS(): implement for DerivedProjectedCRS (related to ↵Even Rouault
refs OSGeo/gdal#3927)
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-15 10:59:51 +0000