[gdal-dev] Coordinate transformation failing

[Stefan Moebius]

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.rouault at gmail.com> 
Sent: Friday, March 22, 2019 12:05
To: Stefan Moebius <Stefan.Moebius at amdocs.com>
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Coordinate transformation failing

 

Stefan,

 

Le ven. 22 mars 2019 à 10:44, Stefan Moebius <Stefan.Moebius at amdocs.com <mailto: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/94812424/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2526 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190322/94812424/attachment-0001.bin>
-------------- next part --------------
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190322/94812424/attachment-0003.html>