gdal warp/translate/info problems with Ferro Coordinate System 4805

[mj10777]

When creating georeferenced images for Ferro

• incorrect results are created

If I remember correctly, I ran into this problem many years ago

• switching to 4314, which uses Greenwich, resolved this

Now I am goreferencing original Austrian maps which use 4805, MGI (Ferro)

• and this problem has again risen

---

I have created a project, with all the needed files, that can be downloaded with

wget ​http://www.mj10777.de/rasterlite2/gdal/20151106.gdal_problem.ferro.tar.bz2

• 119 MB

---

With gdal_translate a gcp list is created

• this files is then warped

gdalinfo shows

• correct Coordinate System and Corner Coordinates
  • but the Wsg84 values also show the Ferro values

Upper Left ( 28.5000000, 44.5000000) ( 28d30' 0.00"E, 44d30' 0.00"N)

Lower Left ( 28.5000000, 43.5000000) ( 28d30' 0.00"E, 43d30' 0.00"N)

Upper Right ( 29.5000000, 44.5000000) ( 29d30' 0.00"E, 44d30' 0.00"N)

Lower Right ( 29.5000000, 43.5000000) ( 29d30' 0.00"E, 43d30' 0.00"N)

Center ( 29.0000000, 44.0000000) ( 29d 0' 0.00"E, 44d 0' 0.00"N)

Spatialite and proj4 commands return the correct x values

• 10.82921461168763
• 11.82907661424254
• 11.32914545356946

In the archive (in gdal_commands.txt)

• all used commands, with results) can be seen

• 1905.29_44_Florenz.200000.tif
  • is the original file
• 1905.29_44_Florenz.200000.gcp.tif
  • is the result of gdal_translate
• 1905.29_44_Florenz.200000.4805.map.tif
  • is the result of gdalwarp
• 1905.29_44_Florenz.200000.4805.map.tif.info.txt
  • is the result of gdalinfo

---

I noticed this problem while working on one last problem in RasterLite2 which needs to be completed before Sandro resumes work on RasterLite2

• once this patch is compleated, I will get back to
  • ​https://trac.osgeo.org/gdal/ticket/5582
    • where I hope to offer suggestion more to your liking

There to, the Wsg84 values were in Ferro

• so while importing the geotiff with the native geotiff lib
  • somehow the Ferro values were lost

Also exporting, using libgeotiff

• the results were incorrect
  • MGI (Ferro) was recognized
    • but there was no WKT text as shown with gdalinfo

GEOGCS["MGI (Ferro)",

DATUM["Militar_Geographische_Institut_Ferro",

SPHEROID["Bessel 1841",6377397.155,299.1528128000033,

AUTHORITY["EPSG","7004"]],

TOWGS84[682,-203,480,0,0,0,0], AUTHORITY["EPSG","6805"]],

PRIMEM["Ferro",-17.66666666666667], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4805"]]

at this point I looked closer to the gdalinfo results

• and noticed the invalid Wsg84 values

---

I also attempted (not part of the project)

• replacing -t_srs epsg:4805
  • with both the WKT and the proj4 string
    • same results (invalid Wsg84 values)

---

Since the commands for

• Spatialite
  • SELECT ST_Transform(MakePoint(28.5000000,44.5000000,4805),4326);
• proj4
  • echo 44.5000000 28.5000000 | cs2cs -rsf '%.14f' +init=epsg:4805 +to +init=epsg:4326

bring the correct results

• I assume that my configuration is correct

---

All of this was done with a gdal version 2.1.0

• created a day after you announced the 'warning free' version

But if my recollections are correct

• this is a much older problem

[Even Rouault]

I'm a bit confused by this ticket. I believe the issue raised is that gdalinfo reports things like "Upper Left ( 28.5000000, 44.5000000) ( 28d30' 0.00"E, 44d30' 0.00"N) " where the values in the second tuple would be assumed to be in WGS84. This is not what gdalinfo does: gdalinfo does not do datum transformation for that, only from projected to geographic in the same geographic SRS, so if the SRS is a geographic one, then the values in the second tuple will be the same as in the first one.

[mj10777]

Well, it that is the intended purpose, then it is not an error.

• I had always assumed that this should be wsg84
  • and could be used to check if an obviously value was returned