PROJ/src/iso19111, branch 7.0.0

createOperations(): be robust to a GeographicCRS having a wrong ID attached to it (fixes #1982)

2020-02-25T15:29:38+00:00

CompoundCRS::create(): reject combinations of components not allowed by ISO 19111

2020-02-24T23:19:51+00:00

createOperations(): keep height/z value in Helmert transform between 3D CRS

2020-02-24T19:38:20+00:00

Expose proj_context_is_network_enabled() in C API

2020-02-24T09:32:55+00:00

validateParameters(): fix false-positive warning on Equidistant Cylindrical

2020-02-19T17:13:40+00:00

DatabaseContext::lookForGridInfo(): use also old_proj_grid_name for lookups (fixes #1942)

2020-02-19T17:12:37+00:00

PROJStringParser::Private::buildProjectedCRS(): avoid (harmless) division by zero in super odd case with corrupted PROJ string. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20624

2020-02-10T15:19:53+00:00

Merge pull request #1915 from rouault/fix_1911

2020-02-06T12:44:13+00:00

Fix identification of ESRI-style datum names starting with D_ but without alias

Fix identification of ESRI-style datum names starting with D_ but without alias

2020-02-05T18:59:00+00:00

Fixes #1911

Fix performance issue, affecting projinfo EPSG:7842

2020-02-05T17:54:04+00:00

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.