[Gdal-dev] Use of individual drivers

Kor de Jong k.dejong at geo.uu.nl
Fri Nov 11 04:26:33 EST 2005


Dear list,

I am developing a library for the input and output of multi dimensional data. 
Currently supported dimensions are:
- scenarios
- (Monte Carlo) samples
- cumulative probabilities
- time
- space
The goal of the library is to relieve the user from the details of how the 
data is stored (table, raster, file, memory, dbms, ...) and what conventions 
each format uses to store the data in each dimension.

My question relates ofcourse to the raster data which is stored in files and 
for which I use GDAL to do the input and output. Currently the GDAL 
functionality with all its own drivers, is layered in one driver in my 
library, which enables me to do this:

// Let gdal find out the format of dem.map.
GDALRasterDriver* driver = new GDALRasterDriver();
Raster* raster = driver->open("dem.map");

This works, but I am looking for a way to use each GDAL driver individually. 
Each driver should correspond to one file format, like this:

int driverId = ...; // GDAL file format driver id, could also be the name.
GDALRasterDriver* driver = new GDALRasterDriver(driverId);
Raster* raster = driver->open("dem.map");

This way I can maintain a mapping of rasters and drivers used to read or write 
the data. Also GDAL doesn't need to search through its list of drivers each 
time new data is read. (As a hack I could store the id of the GDAL driver 
used to read the data the first time it is tried, but this conflicts with the 
overall design of my library in which GDALRasterDriver is just one of the 
drivers.)

My first idea was to copy the few lines of code in the GDALOpen function in 
gdaldataset.cpp and use the GDAL drivers directly instead of calling GDALOpen 
for example. This could work if the procted poDriver member of GDALDataset 
was public or if my function, like GDALOpen, was declared a friend of 
GDALDataset. I guess for good reasons both will not happen so I wonder what 
my alternatives are.

In short, is it possible to get around the high level GDAL functions and use 
the individual GDAL drivers directly? If not, does the design of GDAL allow 
it to be changed to allow such use?

Thanks for any suggestions you might have.

Best regards,
Kor

-- 
Kor de Jong, k.dejong at geo.uu.nl
Fysische Geografie, Geowetenschappen, Universiteit Utrecht





More information about the Gdal-dev mailing list