| Age | Commit message (Collapse) | Author |
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17923. master only
|
|
createOperations(): fix double vertical unit conversion from CompoundCRS to other CRS when the horizontal part of the projected CRS uses non-metre unit
|
|
|
|
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
|
|
|
|
return null.
It is true for datum(), but does not apply to coordinateSystem().
|
|
ob_tran doc: fix/clarify semantics of o_lat_p/o_lon_p
|
|
rouault/fix_custom_compound_crs_with_NAD83_2011_and_geoidgrid_to_WGS84_G1762
proj_create_crs_to_crs(): remove elimination of Ballpark operations that caused transformation failures in some cases
|
|
verticalCRS to a 2D CRS
|
|
caused transformation failures in some cases
|
|
Add a proj_crs_demote_to_2D(). Useful if forced to export a 3D CRS to a best approximate as WKT1 that doesn't support it
|
|
aeqd: for spherical forward path, go to higher precision ellipsoidal case when the point coordinates are super close to the origin (fixes #1654)
|
|
approximate as WKT1 that doesn't support it
|
|
|
|
when the point coordinates are super close to the origin (fixes #1654)
|
|
string
|
|
|
|
Relates to https://github.com/OSGeo/gdal/issues/1856
|
|
|
|
|
|
|
|
Improve vertical transformation support
|
|
PROJ string CRS ingester: recognize more unit-less parameters, and general handling of +key=string_value parameters
|
|
|
|
handling of +key=string_value parameters
|
|
When we had a transformation between a compoundCRS and a target geographicCRS,
we did not take into account that in the vertical->other_geog_CRS transformation
we used, the other_geog_CRS was an implicit interpolation CRS. Thus before
doing vertical adjustment, we must go to this interpolation CRS.
The workflow is thus:
source CRS -> interpolation CRS + vertical adjustment + interplation CRS -> target CRS
|
|
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.
|
|
Patch proj-6.2.0-isea.gpatch by Eric Dechaux
|
|
Patches proj-6.2.0-hanato.gpatch and proj-6.2.0-mbtfpp.gpatch from Eric Dechaux
|
|
Rename CS template argument, to avoid conflict with macro in Solaris system headers.
Similar to 2f8bd934860b135044c5122e3272f7cc41ba81e7
|
|
pipelines at end
|
|
createOperations(), and test it (fixes #1623)
|
|
|
|
* Allow arbitrarily complex polygons in geod_polygon_*. In the case
of self-intersecting polygons the area is accumulated
"algebraically", e.g., the areas of the 2 loops in a figure-8
polygon will partially cancel.
* Simplify code by using C99 functions remainder and remquo.
* More test coverage.
Fixes to associated files:
* src/pipeline.cpp invoke geod_init with f = es / (1 + sqrt(1 - es))
instead of (the less accurate) f = 1 - sqrt(1 - es)
* src/apps/geod_set.cpp remove "#undef f" (a dangling relic?).
|
|
cmake and autoconf now stipulate C99
change c89 to c99 in travis jobs
remove HAVE_C99_MATH checks
(unrelated) relax Visual Studio compatibility check in
cmake/project-config-version.cmake.in (VS 2019 can use a VS 2015 library
but not vice versa).
|
|
Remove unneeded C99 compatibility functions from math.cpp and proj_math.h
I'll do the clean up of the -std=c89 flags etc. as a separate pull request.
|
|
needs <limits.h>. Update scripts/reference_exported_symbols.txt and
src/proj_symbol_rename.h.
|
|
just includes math.h and limits.h) since it's included in a score of
places.
|
|
eliminate most of math.cpp. All that is left is the handling of
isnan (and I've this because math.cpp notes that gie.c uses pj_isnan).
geodesic.c now handles supplying C99 math functions internally and this
can go away once C99 support is mandated.
|
|
|
|
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16130
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16106
|
|
NaN being propagated. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15336
|
|
coordinates and ellipsoid values. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15148&
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15009
|
|
coordinates and ellipsoid values. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14766
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14666
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17190
|
|
|