Stefan, Le ven. 22 mars 2019 à 10:44, Stefan Moebius <stefan.moeb...@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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
