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

[Frank Warmerdam]

Riipinen Petri wrote:

>>Also, I am not sure I will want to take the time to implement this all in
>>the near future.
>>
> 
> Would you mind if I would add support for parsing the tab-file the same
> way as the tfw is parsed? I haven't looked at the GDAL TIFF/GeoTIFF-driver
> yet, but I'm guessing that it first checks whether a file with the same
> name as the TIFF-file but with .tfw-extension exists and then reads the
> coordinates from the .tfw-file. So, I guess that the processing of the
> .tab-file would be quite analugous, except for the parsing part. I guess I
> could just forget about the coordsys-clause.



Petri,

You are welcome to. Just send me the patches.

The .tfw handling is done by a subroutine (GDALReadWorldFile()) found in
gdal/core/gdal_misc.cpp. I would suggest you implement a static function
GDALReadTabFile() within gdal/frmts/gtiff/geotiff.cpp that does something
similar for mapinfo tab files. You can search geotiff.cpp for the existing
calls to GDALReadWorldFile() to see where the tab call could be inserted.



Once you are happy with the code, send me the patches and I will commit them
to CVS.


> By the way, if the coordinates in the GeoTIFF-file and .tfw-file mismatch,
> which ones are used?


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



> Ok, that's handled. Then I have another question. When I do rasterIO, does
> GDAL always read the raster from the physical file or does it cache the
> raster information once I do rasterIO the first time on a particular file?
> Can I ask GDAL to cache a certain file, if I know that I will be reading
> it again pretty soon, but a slighly different block? What if I copy
> the file into ramdisk and open it from there, would that speed up the
> rasterIO-operation?


GDAL does caching for most formats on a GDALRasterBlock basis. The maximum
amount of memory that will be used for caching raster data is 5MB by
default, and may be altered by calling GDALSetCacheMax() or setting the
GDAL_MAX environment variable.

Note whether caching is used at all for a given format is controlled by the
format, not by the application. Some formats (those that implement RasterIO()
directly) do not cache. These are generally "bridge" mechanisms to other
libraries which are presumed to do some caching.


> By the way, my read region size and output region size are always 1:1, so
> there will be no need for scaling.
> 
> Or maybe I'd be better off by reading the complete block at once with
> rasterIO and handling the drawing of the image myself from the raster
> blocks, this way I would need to use rasterIO only when reading a
> completely new file, i.e. when user moves off the current map block.


Accessing on block boundaries with RasterIO() is generally faster than
accessing on non-block boundaries since it reduces the complexity of the
copy (just a memcpy()). Fetch blocks directly is even more efficient
since there is no overhead to copy from the block to the memory buffer.

However, these sort of performance differences are generally very small.
The most important issues are to ensure suitable cache memory (ie. as
much as you can spare without it impacting other aspects of your application).


> My issue with performance is that as GPS gives a new coordinates and
> it's time to move the map one pixel on the screen, I need to redraw the
> map and currently I do it by reading the whole visible area (800x550
> pixels are shown, the complete map consists of 4000x4000 pixel block, over
> 100 files, with total of over 150 megs) with rasterIO. Or would it be more
> beneficial to just blit the bitmap with some fast operation and use
> rasterIO for reading just the new strip (1 pixel wide) on the edge of the
> screen? Actually, on pixel on the map is 20 meters in real world, so one
> can imagine that a car (thats where the system will be running) moves
> quickly that distance, hence causing the update to the map.


Hmm. Well, I don't quite understand the structure of your application

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!

If you tend to do alot of "little" moves, I would be tempted to keep a backing
store image that is significantly larger than the view window. That way
small moves of the view can be just recreated from the backing store image.
When the view moves off the edge of the backing store image you can re-create
the backing store image through GDAL, recentered on the current view area.

It sounds like a cool application!

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at p...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent