aboutsummaryrefslogtreecommitdiff
path: root/test
AgeCommit message (Collapse)Author
2019-11-25normalizeForVisualization() and other methods applying on a ProjectedCRS: do ↵Even Rouault
not mess the derivingConversion object of the original object (fixes #1736) normalizeForVisualization(), promoteTo3D(), demoteTo2D(), alterGeodeticCRS(), alterCSLinearUnit() and alterParametersLinearUnit() all used the object returned by derivingConversionRef() to create a new ProjectedCRS. While doing so, this caused the derivingConversion of the original object to have its targetCRS set to the object returned by normalizeForVisualization() and similar. If that object died, then the weak pointer would be reset, and the original ProjectedCRS() has now its derivingConversionRef()->targetCRS() nullptr So bottom line is use derivingConversion() for anything that is not pure reading !!! This is confirmed to be the fix for the QGIS scenario in https://github.com/qgis/QGIS/issues/30569#issuecomment-540060919 In QGIS use case, the issue arised when using a projected CRS with a non-GIS friendly axis (that is where normalizeForVisualization() created a new projectedCRS)
2019-11-03createOperations(): in some circumstances we wrongly promoted a Helmert ↵Even Rouault
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
2019-10-30createFromWkt(): be tolerant to missing scale_factor parameter (fixes #1700)Even Rouault
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.
2019-10-25importFromWkt(): fix axis orientation for non-standard ESRI WKT (fixes #1690)Even Rouault
2019-10-18createOperations(): fix double vertical unit conversion from CompoundCRS to ↵Even Rouault
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
2019-10-12createOperations(): allow transforming from a compoundCRS of a bound ↵Even Rouault
verticalCRS to a 2D CRS
2019-10-03aeqd: for spherical forward path, go to higher precision ellipsoidal case ↵Even Rouault
when the point coordinates are super close to the origin (fixes #1654)
2019-09-28Merge pull request #1636 from OSGeo/backport-1633-to-6.2Even Rouault
Backport #1633 to 6.2
2019-09-28Database: update to EPSG 9.8.2Even Rouault
With limitation of https://github.com/OSGeo/PROJ/issues/1632 regarding concatenated operations with more than 3 steps.
2019-09-26proj_create_crs_to_crs(): fix when there are only transformations with ↵Even Rouault
ballpark steps Currently we would discard all operations, resulting in a PJ object with zero candidates. Better use those operations if nothing better is available. Was seen on transforming from ETRS89 / UTM zone 31N + EGM96 height to WGS 84 (G1762). The horizontal transformation from ETRS89 to WGS 84 (G1762) is a ballpark one.
2019-09-17ell_set.cpp: avoid division by zero in R_lat_a case. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16130
2019-09-17standard_fuzzer.cpp: tweak to be able to compile it against libproj.soEven Rouault
2019-09-17eqdc: avoid potential division by zero. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17190
2019-09-10Fix gie test after applying fix to bertin1953Kristian Evers
2019-09-16[6.2 backport] cs2cs: autopromote CRS to 3D when there's a mix… (#1615)Kristian Evers
[6.2 backport] cs2cs: autopromote CRS to 3D when there's a mix of 2D and 3D (fixes #1563)
2019-09-15cs2cs: autopromote CRS to 3D when there's a mix of 2D and 3D (fixes #1563)Even Rouault
2019-09-15API: add CRS::promoteTo3D(), proj_crs_promote_to_3D() and ↵Even Rouault
proj_crs_create_projected_3D_crs_from_2D() (fixes #1587) (projinfo changes adding --3d from master removed)
2019-09-15createFromPROJString(): ignore +no_defs when instanciating a ↵Even Rouault
'+init=epsg:xxxx +no_defs' string (related to #1597)
2019-09-15Ingestion of +proj=somerc +type=crs: avoid adding twice alpha, gamma, lon_0 ↵Even Rouault
(related to #1597)
2019-09-15[Backport 6.2] Improve vertical transforms (#1613)Kristian Evers
[Backport 6.2] Improve vertical transforms
2019-09-13createOperations(): when tranforming from a compoundCRS whose vertical ↵Even Rouault
component is a BoundCRS, do not apply the horizontal transformation twice
2019-09-13createOperations(): use more candidates when transforming between a ↵Even Rouault
geographic and vertical CRS For example when transforming from NAD83+NAVD88 height to WGS84, there is no transformation between NAVD88 height to WGS84. In that case, use all potential transformations from NAVD88 height to another geographic CRS for the vertical part.
2019-09-13createOperations(): make sure sorting function is transitive (a < b and b < ↵Even Rouault
c --> a < c), to get consistent results
2019-09-13Fix support for +proj=ob_tran +o_proj=lonlat/latlong/latlon (only ↵Even Rouault
+o_proj=longlat worked) (fixes #1601)
2019-09-12Merge pull request #1607 from OSGeo/backport-1604-to-6.2Even Rouault
[Backport 6.2] proj_trans_generic(): properly set coordinate time to HUGE_VAL when no value is passed to the function
2019-09-12proj_trans_generic(): properly set coordinate time to HUGE_VAL when no value ↵Even Rouault
is passed to the function
2019-09-11createOperations(): fix conversion from/to PROJ.4 CRS strings with ↵Even Rouault
non-ISO-cosher options and towgs84/nadgrids This actually fixes a regression introduced in PROJ 6.2.0 per 78302efb70eb4b49610cda6a60bf9ce39b82264f that made a conversion like EPSG:4326 to "+proj=something +towgs84/+nadgrids +over +type=crs" apply the towgs84/nadgrids operation twice.
2019-08-26Fix 6.0 regression regarding +init=epsg:4326 +over +to +init=epsg:3857 +over ↵Even Rouault
with longitudes outside of [-180,180]
2019-08-26createOperations(): follow-up of previous commit for +datum=NAD83 caseEven Rouault
2019-08-26createOperations(): fix pipeline generation when a CRS has terms like ↵Even Rouault
+datum=NAD27 and +over, where the datum was just replaced by its ellipsoid
2019-08-25Import WebMercator from PROJ string: make sure the WGS84 datum is setEven Rouault
2019-08-23Add proj_create_crs_to_crs_from_pj()Even Rouault
I've been frustrated a number of times with proj_create_crs_to_crs() not accepting a PJ* object for the source and target CRS. And thus constraining to go back to WKT2 in a artificial way.
2019-08-20C API: add proj_context_set_autoclose_database() to automatically close ↵Even Rouault
database (fixes #1565)
2019-08-20Merge pull request #1547 from rouault/json_exportEven Rouault
Add CRS JSON export (refs #1545)
2019-08-17PROJJSON: rename file as projjson.schema.json, and add versionning to it and ↵Even Rouault
to exported PROJJSON strings
2019-08-12PROJJSON: add support for importing 'ids'Even Rouault
2019-08-10PROJJSON: a few fixes, and add import of DerivedCRS, EngineeringCRS, ↵Even Rouault
ParametricCRS and TemporalCRS
2019-08-10PROJJSON: add support for DatumEnsemble and ↵Even Rouault
Dynamic[Geodetic|Vertical]ReferenceFrame
2019-08-09C API: add proj_as_projjson()Even Rouault
2019-08-09PROJSJON: add import/export of VerticalCRS, CompoundCRS, BoundCRS, ↵Even Rouault
Transformation and ConcatenatedOperation
2019-08-09createFromUserInput(): add capability to import PROJJSONEven Rouault
2019-08-09PROJJSON export: use more compact formEven Rouault
2019-08-09projinfo: rename JSON to PROJJSONEven Rouault
2019-07-25Database: update to EPSG 9.7.0Even Rouault
2019-07-19Add set discard superseded method to api (#1534)Matt Littlemore
Closes #1519
2019-07-08CRS JSON: export GeographicCRS and Projected CRSEven Rouault
2019-07-06Proof-of-concept of JSON export limited to PrimeMeridian (refs #1545)Even Rouault
2019-07-06Formatting fixEven Rouault
2019-07-01C API: add proj_concatoperation_get_step_count() and ↵Even Rouault
proj_concatoperation_get_step()
2019-06-30Database: import scope/remarks for coordinate operation and add C APIEven Rouault
- Import scope and remarks for coordinate operations of the EPSG dataset. Database size goes from 5.2 MB to 5.55 MB - Add proj_get_scope() and proj_get_remarks()
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-29 06:29:41 +0000