Thanks, Even. Is there a way to automatically detect and solve this when reading a file? Detection is obviously possible by checking for the failing transformation, but how about the solution? It seems that the towgs84 parameters aren’t strictly necessary – is simply removing them a reasonable (and generic) workaround?
-- Stefan From: Even Rouault <even.roua...@gmail.com> Sent: Friday, March 22, 2019 12:05 To: Stefan Moebius <stefan.moeb...@amdocs.com> Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Coordinate transformation failing Stefan, Le ven. 22 mars 2019 à 10:44, Stefan Moebius <stefan.moeb...@amdocs.com <mailto: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
smime.p7s
Description: S/MIME cryptographic signature
This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service <https://www.amdocs.com/about/email-terms-of-service>
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
