Failure to geolocate MAPINFO .TIF files calibrated by .TAB files

[davesgrandad]

Where historical maps are calibrated within Mapinfo, these are usually output in the form of .TIF files accompanied by a .TAB file giving the georeferencing data. An example of such maps is the 1880s First Series 1:2500 scale county Ordnance Survey maps for Suffolk. At this scale it takes a large number of tiles to cover a whole county. In a sample dozen of such maps around Bury St Edmunds, only four were correctly located by GDAL called from within QGIS. The rest disappear from view. Two sample tiles are attached, which are adjacent to each other. One will be correctly located, while the other will not. It seems that GDAL will not properly locate the tile if the control points do not represent a clean affine transformation for the image. It falls back to returning them as ground control points which QGIS cannot utilize directly. This is likely to be a problem for all local authorities using old historic maps who would like to convert to QGIS. Can GDAL be tweaked to transform such tiles where the error is only slight?

[Jukka Rahkonen]

I consider that this in not an issue in GDAL but you should rather file a feature request for making QGIS capable to do on-the-fly warping by ground control points. Nothing prevents to do that with GDAL which I try to prove with the screen capture of your images opened into very old OpenEV from FWTools 2.0.6.

[Jukka Rahkonen]

I do understand your wish, though, because I do play a bit with scanned historical maps as well. So far I have just converted tiffs with GCPs into north-up maps with gdalwarp. But perhaps some Python guru could write a script that writes a best fitting world file (.tfw) according to GCPs. Or an aux.xml file which GDAL is perhaps calling as PAM. However, I do not know if there is a mechanism to tell to the GDAL based viewer to utilize .tfw instead of the internal georeferencing of GeoTIFF. I know that MapServer can do it and there is also an open GDAL ticket about that.

[Even Rouault]

trunk r28311 "GDALLoadTabFile: add TAB_APPROX_GEOTRANSFORM=YES/NO configuration option to decide if an approximate geotransform is OK (#5809)"

trunk r28312 "GTiff: document TAB_APPROX_GEOTRANSFORM=YES/NO configuration option (#5809)"

Also documented in http://trac.osgeo.org/gdal/wiki/ConfigOptions

As all coordinates in the .tab file are integer we could probably relax the current error threshold, or use a more clever heuristics to figure out that the got geotransform is the best we can get with integer coordinates, but sounds overkill...

[Even Rouault]

Milestone renamed