| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
Docker Hub builds; update version of grid archives
|
|
[Backport 6.3] fixes for #1906 (test failures on i386)
|
|
Refs #1906
Fix remaining issues of https://github.com/OSGeo/PROJ/issues/1906#issuecomment-583168348
as found with gcc 8.2.0 -m32 -O2
|
|
Fix a few issues of #1906 found when running the test suite
on Ubuntu 16.04 with gcc 5.5 -m32. When applied on top of
the fix of #1912, make check succeeds
|
|
This should avoid issues with numerical stability as uncovered in
https://github.com/OSGeo/PROJ/issues/1906.
Practically speaking this change isn't going to affect real life
scenarios since the position of the center of the Earth is rarely
expressed in geodetic coordinates.
|
|
[Backport 6.3] PR #1884 #1914 #1915
|
|
Fixes #1911
|
|
Fixes #1913
AuthorityFactory::createBetweenGeodeticCRSWithDatumBasedIntermediates() issued
a complex SQL query that pushes the SQLite3 query plan optimizer to its limits.
Was working reasonably with sqlite 3.11, but not with later versions.
So put less constraints in the main query and do post-processing checks and
auxiliary requests to avoid such issues.
For some unknown reason, this slightly slows down a bit execution time of the
whole test_cpp_api binary (~ 10%), but couldn't come with something better,
despite trying many variations of the main SQL query. It seems that in the
general case the non-filter LEFT JOIN on the supersession table helped,
except on this EPSG:7842 case.
|
|
Fixes #1881
Digging into the implementation of proj=cea, it appears that
k_0 and lat_ts are intended to be exclusive ways of specifying the
same concept. EPSG only models the variant using lat_s.
So if k_0 is found and lat_ts is absent, compute the equivalent
value of lat_ts from k_0.
Note: k_0 should normally be in the [0,1] range. In case creative users
would use something outside, we raise an exception, even if the cea
implementation could potentially deal with any k_0 value. Hopefully
this is a (reasonable) limitation that will address nominal use cases.
|
|
tests: force use of bash for proj_add_test_script_sh
|
|
|
|
in `docs/src/development/bindings.rst`
|
|
[Backport 6.3] Doc: advertize FOSS4G 2020
|
|
|
|
rouault/backport_fix_wrong_use_of_derivingConversion
[6.3 backport] Fix wrong use of derivingConversionRef() that caused GDAL bug
|
|
[6.3 backport] Database: update to EPSG v9.8.6
|
|
Hopefully final cut at solving the same class of bug that the one
that affected QGIS in December.
This time, this hit GDAL in the situation of
https://lists.osgeo.org/pipermail/gdal-dev/2020-January/051500.html
The bug fix for that particular issue is in
PROJStringParser::createFromPROJString()
But grepping more in the code base, I could find other potential smelly
situations (might not be issues, but better be safe than sorry),
so let's fix them too.
Bottom line is:
derivingConversionRef() should *only* be used for consultation, and
never to create a new ProjectedCRS()
|
|
grid_alternatives, fix related entries and simplify/robustify logic to deal with EPSG 'Geographic3D to GravityRelatedHeight' methods
|
|
Fixes #1867
|
|
|
|
|
|
closes #1511
|
|
Document need for quotes when a pipeline grid path contains spaces
|
|
to units
Fixes bug reported in https://lists.osgeo.org/pipermail/gdal-dev/2020-January/051481.html
|
|
|
|
|
|
|
|
|
|
Not certain whether this is appropriate when you are dealing with lists of grids, but it definitely helps for a single grid.
|
|
Explain why sweep axis affects geolocation
|
|
In the note on the sweep angle, add a line explaining why the sweep angle ultimately affects the geolocation, as it is not immediately or trivially obvious to see why it should matter what the outer or inner gimbal is. To this end, link to a post on Mathematics Stack Exchange that explains this very well.
|
|
|
|
|
|
Adds links to git repositories and adjusts deprecation warnings to
reflect that PROJ 6 has been released.
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20072
|
|
#1835)
|
|
|
|
The exception only affects C++ users. It was caught by the C layer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|