[gdal-dev] Any hope of getting TAB-support on GDAL?

[Petri J. Riipinen]

Frank,

>You are welcome to. Just send me the patches.

Ok, I will do it.

>Currently the GeoTIFF information takes precidence though I am not sure that
>is the best approach.

Well, here I see one problem already. The coordinates in the TIFF-file (as 
shown by gdalinfo) are 0,0,4000,4000 for my files. Of course those are not 
geographically correct, the correct coordinates are in the .tab-file.

gdalinfo says:
--------------
Driver: GTiff/GeoTIFF
Size is 4000, 4000
Coordinate System is `'
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 4000.0)
Upper Right ( 4000.0, 0.0)
Lower Right ( 4000.0, 4000.0)
Center ( 2000.0, 2000.0)
Band 1 Block=4000x2 Type=Byte, ColorInterp=Palette
Min=0.000/0, Max=255.000/0
Color Table (RGB with 256 entries)
0: 0,0,0,255
<and more colors...>
-----

And tab-says
(3180000,6640000) (0,0) Label "Pt 1",
(3260000,6640000) (3999,1) Label "Pt 2",
(3260000,6560000) (3999,3999) Label "Pt 3",
(3180000,6560000) (0,3999) Label "Pt 4"
---------------

So, if I were to convert those coordinates from the tab-file into tfw (as 
you suggested earlier), GDAL would still use the dummy 0,0,4000,4000 
coordinates? Or does it understand that those are not really georeferenced 
coordinates?

>so it is hard to give good advice. Are you saying that you are doing 150
>RasterIO()s to fill your area on 150 different files? There will be a
>non-trivial performance hit in this!

Nope, I have about 150 files in total, each covering an 80x80 km (4000x4000 
pixels) square of Finland. As my view is roughly 800x550 pixels, I will be 
using at most data from 4 blocks (consider the view showing the corners of 
4 adjacent blocks).

Currently I'm doing so that I use rasterIO to fetch always exactly a 
800x550 pixel block from 1...4 files (depending on the "seam" between the 
blocks being in the view).

So, the if the user really rallies around Finland, he might be able to 
cover all blocks, but most probably he will (at any one given driving 
session) be touching at most 16-25 blocks (4x4 blocks would already cover 
320x320 km).

So, I guess that to get some performance improvement should really read 
data into memory one file at a time and keep it there as long as needed and 
then just update the screen by copying blocks from the memory object into 
screen.

Fortunately FLTK-widget kit offers a nice Fl_RGB_Image-widget that can act 
as a container for an RGB-image and then it has a nice draw-method that 
takes x,y,w,h on screen and then xOffset, yOffset of the memory buffer. 
That is probably the best solution for quick screen updating. Caching will 
also be nicely handled, I can just subclass the widget and perhaps update a 
timestamp whenever the widget is drawn and then use some least-recent-used 
mechanism to get rid of the widgets that haven't been used for a while.

- Petri
<><><><><><><><>
Petri J. Riipinen
petri.riipinen at n...
<><><><><><><><>