[Gdal-dev] GDALDataset as a Base Class

[Mateusz Loskot]

Matt Hanson wrote:
> Mateusz wrote:
>> Does the 'transparent' mean you don't want to make user of your 
>> library to deal directly with GDAL? So, user needs only to pass 
>> filename/dataset location to your interface and GDAL objects are 
>> create behind the scene?
> 
> Essentially yes, even though I may add that GDAL has a very nice and 
> quick to learn interface.  So it's not to make GDAL simpler but 
> rather to automate the process of reading, processing in chunks, and 
> writing out. A user would init an image by passing it a filename and
> in most cases they won't have to worry about calling Read/Write 
> functions, instead they call processing functions.


Yes, I think I understand your objectives now.
Basically, you're going to use GDAL as as a I/O
interface to access images.
Like using fopen function without wanting to make it simplier or
change its interface and behaviour, but just use it.

So, definitely inheritance is not a good idea here,
what we've already discussed.


> I'm actually quite interested at some point to write iterators (1-D 
> and 2-D), so that STL or more specifically VIGRA 
> (http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/) style 
> algorithms could be used directly but that would take a lot more work
>  and the trick would be to make them smart enough to minimize I/O.

Yes, the idea is good.
Similarly, I create my own iterator (input iterator) for Shapefile,
so I can use STL algorithms accepting input iterators on shape objects.
(it's under development, I'm going to publish it in October,
now I don't have any time to finish it.)

The main idea is to define proper "protocol" of data exchange between
iterator (client) and underlying "container" (image).

Another interesting idea is a View concept.
View is a kind of "looking glass" through which a set of elements
can be observed in different ways without interfering the structure of
the set itself. You know, too look at something as it would have
different structure than it actually has.

View concept in C++ is usually based on two fundamental concepts:
sequence and iterator. For example, one may want to define
a chunk_view for raster (2D array of pixels) which would enable
user to iterate raster by-chunks (for example by 20x20 pixel chunks)
instead of by-single-pixel. And thanks to STL-compliant iterators,
this may be done with STL algorithms.

A very trivial use case, for presentation purpose:
You have a blank (white or black) raster of size of 200x200 pixels.
You can use view + iterator + std::for_each or std::transform algorithm
to make it fill 20x20 pixels chunks with black and white to make
it a chessboard. With view/iterator, this operation can be made in
single line of code.

The View concept is powerful and pretty coder-friendly to grasp.
Here is a very good intruduction: STL Sequences & the View Concept
http://www.ddj.com/dept/cpp/184401789

View Template Library is a set of predefined STL-compliant views:
http://www.zib.de/weiser/vtl/

BTW, I think our debate may be  getting Off-Topic for
the gdal-dev list :-)

> I haven't thoguht out the process yet but  I'd probably start by 
> restricting the case to forward iterators and then read in a block 
> when you hit the beginning of it and store which piece has been read 
> in.  This isn't in the scope of my current effort but it would be 
> nice to see someday.

If you mean to do read-only in forward progress, then input
iterators should be used here (using STL iterators nomenclature).
Forward iterators provide read-write access, during forward
iteration only.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net