| Age | Commit message (Collapse) | Author |
|
createOperations(): fix missing deg<-->rad conversion when transforming with a CRS that has a fallback-to-PROJ4-string behaviour and is a BoundCRS of a GeographicCRS (fixes #2804)
|
|
createOperations(): fix SourceTargetCRSExtentUse::NONE mode
|
|
|
|
CompoundCRS are involved (fixes #2720)
|
|
|
|
Non-trivial updates:
- some vertical CRS are now encoded as DerivedVerticalCRS. e.g EPSG:8228
"NAVD88 height (ft)", with base EPSG:5703 "NAVD88 height". As we don't
have support in our PROJ db model for DerivedVerticalCRS, modify the
import script to 'resolve' the derivation up to the original datum.
- Method EPSG:1069 'Change of Vertical Unit' is no longer used. It is
replaced by a generic-purpose EPSG:1104 method that doesn't take any
conversion factor. And generic conversions EPSG:7812 and EPSG:7813 are
now used in concatenated operations, which require code changes as
well.
|
|
regression)
|
|
createBetweenGeodeticCRSWithDatumBasedIntermediates() reachable...
... and optimize its execution time by rewriting it completely.
This code path was no longer triggered in tests since EPSG got a direct
transformation for GDA94 to WGS 84 (G1762).
|
|
Issue spotted by GDAL autotest suite.
|
|
(fixes #2588)
when the source and target CRS share the same geog CRS, but the interpolation
CRS of the vertical transformation isn't the same, and a Helmert
transformation exists between them...
For example, for "CH1903+ + EGM96" to CH1903+ 3D where the interpolation
CRS is WGS84.
|
|
|
|
RGF93 and CH1903+ (fixes #2541)
|
|
|
|
|
|
Database: update to EPSG v10.011
|
|
|
|
|
|
|
|
ellipsoidal height
|
|
from BoundCRS of projected CRS based on NTF Paris to BoundCRS of geog CRS NTF Paris. Fixes https://github.com/OSGeo/gdal/issues/3273
|
|
|