[gdal-dev] Coordinate transformation failing
Even Rouault
even.rouault at gmail.com
Fri Mar 22 04:04:38 PDT 2019
Stefan,
Le ven. 22 mars 2019 à 10:44, Stefan Moebius <Stefan.Moebius at amdocs.com> a
écrit :
> Hi again,
>
> We recently encountered an issue with failing coordinate transformations.
> The scenario is that a current (Java-based) software using GDAL 2.4.0/PROJ
> 5.2.0 reads HFA files generated a long time ago by another software using
> GDAL 1.11.1/PROJ 4.8.0. The HFA files happen to come in a DHDN projection
> system. The current software then transforms the files into a UTM
> projection
> system and fails.
>
> Investigating this further, we've come up with the following minimal test
> showing the issue:
>
> The current version of gdalinfo returns this coordinate system:
> PROJCS["DHDN_VfD2_Germany_zone_3",
> GEOGCS["GCS_DHDN",
> DATUM["Deutsche_Hauptdreiecksnetz",
> SPHEROID["Bessel_1841",6377397.16,299.15281],
> TOWGS84[583,68,399.5,-0,-0,578614.3160276701,11300000]],
>
--> OK, the TOWGS84 is wrong here. The rotation (4th,5th,6th) and scale
factor difference (7th) terms of the TOWGS84 are obviously nonsense.
They should be respectively in arc-seconds and in PPM.
>From what you mention, I believe this is due to
https://github.com/OSGeo/gdal/commit/e3d18d2070d8d73eef37ff3b844b7e441ffb5149
which is likely correct by itself.
The issue here is that as you mentionned the file was produced by GDAL
1.11.1 which incorrectly stored the values
of the rotation and sale factor difference as arc-seconds and PPM whereas
Erdas expected radians and unity-based scale factor difference.
Thus when reading this with GDAL >=2.2, the file is wrongly interpretated.
You should override the TOWGS84 values of this WKT with the corrected ones.
Even
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190322/0738d5db/attachment.html>
More information about the gdal-dev
mailing list