[Gdal-dev] GDALDataset as a Base Class

[Ivan Lucena]

Matt, All,

You are not alone, I don't mind use the pointer either. See in the
attachment an initial attempt to implement Michael Goodchild's Spatial
Model (Well, at least GetExtent() is working identically for
Fields[GDAL] and Objects[OGR] :-).

But what bugs me a little bit is the proliferation of wrapper and
facades for GDAL that *we* are creating. For example, I am following the
idea of VB6 GDAL wrapper and implementing a Delphi wrapper!

And I also believe that we can count the wrappers automatic created by
swig because they also produce slightly different interfaces that
requires especial documentation (and a separated support group from the
gdal-dev list).

Any thoughts on that subject? 

Any COM, CORBA, .Net idea?

Ivan

-----Original Message-----
From: gdal-dev-bounces at lists.maptools.org
[mailto:gdal-dev-bounces at lists.maptools.org] On Behalf Of Matt Hanson
Sent: Wednesday, August 30, 2006 10:58 AM
To: Mateusz Loskot; gdal-dev at lists.maptools.org
Subject: RE: [Gdal-dev] GDALDataset as a Base Class

I don't mind dealing with pointers.  The purpose of the GSImage and
related objects is partly to simplify data access (for use by other
programmers) and also to add functionality (for image processing).
GSBand adds a data access function to return chunks of read data to CImg
objects (see cimg.sourceforge.net ), but also will facilitate easy
artihmetic and logical operators on entire bands.
 
However I confused by the GDALRasterBand implementation, it's an
abstract class due to the pure virtual IRead function.  Thus to derive
from it I would need to define that function.   How does GDAL create
instances of GDALRasterBand (within the GDALDataset) without first
defining that function ?    I don't see the need to be able to create
GSBand objects outside a Dataset though so this is really a moot point.
Encapsulating the GDALRasterBand as a data member and recreating the
interface to it is a relatively small task and works for this
application.  I would use inheritance but I have too many questions with
regard to the GDALRasterBand class. I'm not supposed to call the
GDALRasterBand ctor directly, nor it's dtor, so how does this work with
a dervied class??    I would need a copy constructor to take in a
GDALRasterBand object that I would presumably get with
ds->GDALGetRasterBand(bandnum), but if my derived class goes out of
scope then the base class dtor will be autom!
 atically called which is a no-no for GDALRasterBand.   I guess I should
add then currently my GSImage contains a vector<GSBand>.    The GSImage
won't directly support removing of bands (instead you would call
Subset() function which would write a new file containing the subset)
and I can't currently picture a scenario where an element of
vector<GSBand> would be removed but I'm not deep enough in this to say
that it could never happen.
 
matt

________________________________

From: gdal-dev-bounces at lists.maptools.org on behalf of Mateusz Loskot
Sent: Tue 8/29/2006 11:11 PM
To: gdal-dev at lists.maptools.org
Subject: Re: [Gdal-dev] GDALDataset as a Base Class



Matt Hanson wrote:
> Interesting, my original implementation had GDALDataset as a private
> member as you suggest.   As I spent more time thinking about it I
> thought that a derived class would be better in the long run, so I
> started looking into what was required for that.

Matt,

...I'm back from dog walk so last reply today before going to bed :-)

Please, be aware that my reply refers to a general idea/concept,
and I likely have not considered design requirements of your project.
So, it's a kind of brainstorm from my side.

I assumed that:
- you want to avoid playing with pointers if it's possible
- you want to simplify GDAL dataset to form of image (to access
its bands, and other properties)

with these points in mind, I'd use composition.
BTW, to avoid misunderstanding, I use 'composition' term
according to this explanation:
http://ootips.org/uml-hasa.html

> As it turns out
> though I had already come to the conclusion that my GSBand class
> would have to use GDALRasterBand as a private member because of
> course you can't create raster objects directly.

Similarly to discussion above, everything depends on what is the
relation between GDALRasterBand and GSBand.
What does GSBand with the GDALRasterBand do?
Is GSBand is going to be a kind of Facade Pattern
(http://en.wikipedia.org/wiki/Facade_pattern)
that will offer realization of the same concept as GDALRasterBand,
but with simplified interface (e.g. tighter subset of functions, etc.)

Another option is taht GSBand will *extend* GDALRasterBand
functionality. In this case I'd consider inheritance.

Yet another variation possible is that may be your GSBand and other GS*
classes are going to enable users to play with values and references,
instead of pointers.

Yet more another option is that may be GSBand (and other GS* classes)
are needed to be an adapter around GDAL API (Adapter Pattern -
http://en.wikipedia.org/wiki/Wrapper_pattern)
adapting it to your system interface, etc.

> I suppose at the
> very least it makes sense to have them use the same design, thus
> GDALRasterBand and GDALDataset as private members.

I just want to say, I'm speculating a bit saying "I'd use encapsulation
over inheritance" because everything depends on your objectives.

> Thanks for the explanations, it's been a tremendous help!

I'm happy to hear I'm able to help someone with something!

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net <http://mateusz.loskot.net/> 
_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/gdal-dev



_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/gdal-dev
-------------- next part --------------
class Spatial;
class Field;
class Object;

class Spatial
{
public:
    static Spatial *Open(const char *pszFileName, GDALAccess eAccess);
    virtual CPLErr GetExtent(double *adfExtent);
};

class Field : public Spatial
{
    GDALDataset *poGDALDataset;			// <---- the infamious pointer
    GDALDriver *poGDALDriver;			// <---- the infamious pointer
    
public:
    Field(void);
    ~Field(void);
    static Field *Open(const char *pszFileName, GDALAccess eAccess);
    virtual CPLErr GetExtent(double *adfExtent);
};

class Object : public Spatial
{
    OGRDataSource *poOGRDataSource;		// <---- the infamious pointer
    OGRSFDriver *poOGRDriver;			// <---- the infamious pointer
    
public:
    Object(void);
    ~Object(void);

    static Object *Open(const char *pszFileName, GDALAccess eAccess);
    virtual CPLErr GetExtent(double *adfExtent);
};