[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