[Gdal-dev] Raster data test suite

[Ray Gardener]

It would be good to build a comprehensive data sheet on the drivers. 
There is some info on the website, but each driver is described in its 
own way. I've been making a spreadsheet to catalog their attributes and 
would be happy to share that.


>> What do you mean as automated fashion?

Say I built GDAL and wanted a script that would exercise all the 
drivers. Given a standard set of data files, the test program emits 
certain things (attribute lists, images, dems) that can then be compared 
(again by machine) against a reference set. For the Lev and Terragen 
drivers, for example, I'm going to add sample data, along with a small 
console app (or maybe use an existing GDAL util) and the reference 
transformed data, and then a (windows) test script could add these lines 
to itself:

testapp -lev frmts/leveller/sample.ter -gtiff out.tif
fc /b out.tif frmts/leveller/out.tif
testapp -gtiff sample.tif -lev out.ter
fc /b out.ter frmts/leveller/out.ter

As an app developer just enabling the data formats to increase the I/O 
possibilities for end users, it's off-domain for me to get intimately 
familiar with the formats (which would also defeat the abstraction 
concept of the library). So an automated test suite is vital. This will 
only become more so as more drivers are added. It's especially useful if 
making changes to code shared by multiple drivers; one could catch side 
effects that a simpler test would miss. By hooking CPLMalloc/Free the 
test might also detect memleaks, and it could do benchmarking.

The above example requires a standard "sample.tif" GeoTIFF file, and 
exercises only a one-to-many driver relationship, but if more standard 
samples are added, you can get a many-to-many test working.

Basically, driver authors would be told, on top of the driver, you need 
to run a test using the standard data, and include your driver's 
conversion of it.

Ray