[Gdal-dev] GDALDataset as a Base Class

[Matt Hanson]

Well I'm glad to see my post started a discussion about these things but I don't have much to add because I'm having a hard time following some of it.  My background's in Imaging Science, not Computer Science...and while I'm ok at programming I'm no blackbelt.
To clarify what I'm doing, I'm creating an Geospatial Image Processing library.   The underlying dataset resides on disk and is interfaced through GDAL, and is read and processed in chunks, and written out.   My goal is to make the file I/O and chunking process as transparent as possible to the developer.  I'm essentially applying the power and ease of use of the CImg library to Geospatial imagery.   My hope is to make is publicly available but as both libraries are LGPL it is ultimately up to my boss to make that decision.

________________________________

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



Ivan Lucena wrote:
> Hi there,
>
> Mateusz Loskot wrote:
>> And? Something wrong with those wrappers? I've never seen them, but
> again
>> I'm not sure what is the problem here, if any.
>
> That is ok. I understand. The issue is more sensible to Frank. So I
> believe his answer is good enough for both of us.

OK, it's clear.

>> Pointers are nothing bad, even good, but only if used correctly.
>> I'm not sure what to try to observe there.
>
> I am showing a piece of my C++ implementation that uses GDALDataset
> pointer as an attribute of my class. The things that Matt Hanson tried
> to do in C++ I've tried too a year ago. But I finally give it up to the
> "good use of pointer". It works and it is robust and I encouraging Matt
> to keep doing this way.

I understand, yes this seems reasonable for me too.

> We both agree with that. I just have a sense
> that the use of this kind of class-pointers is an indicator that
> something is lacking. IMHO you should be able o develop in C++ without
> ever looking to the GDAL C API.

I'd try to develop smart pointers for GDALDataset and other
types to expose underlying types in reference-line style
and garbage collecting provided.

> But that leads to the discussion about the proliferation of GDAL
> wrapper. So Frank had thought about that a long time ago, by adoption
> SWIG. My questions is: Are we relying too much in SWIG and wrapper and
> maybe there is something that could me done at once in GDAL?

Personally, I don't see anything better for "done at once" idea
for scripting languages than SWIG.

>> Idea about what?
>> COM wrapper would good for Windows environment because COM provides
>> highest flexibility of reuse -> scripting languages, .NET, VC6, and
>> even C/C++ -  without additional wrapping layer.
>> So, personally if I'd need a GDAL wrapper for .NET, I'd go with COM.
>> Also COM-CORBA bridging is possible, but I don't see any
>> application here.
>
> So Mateusz, Now that you've got the "Idea", let's talk:

Note, my COM idea is a non-portable idea.

> If you look around what the "competitors" (the GDAL's analogous) are
> doing (there is a bunch of SDK to deal with geo-spatial data and
> functionality out there,MapXtreme,

in Java for Windows

> ArcObject,

C++/.NET for Windows and Unix though I've no idea how it's portable

> BlueMarble,

C++ or VB -> for Windows

> TatukGIS,

Borland technologies (C++/Delphi) -> for Windows

> Abaco,

no idea

> They are developing in a "component" oriented fashion.
> Don't you think so?

Yes, but in highly not portable fashion at the same time.
What's the best portable technology of writing
software in your opinion?

> Or whatever name you like to put on it. By doing
> this way they can easily take the advantage of implementing the API
> trough technologies like COM and have it done only once. Document once
> too. For example, browsing at edn.esri.com I don't need to see only
> Delphi example to learn some tricks. I can see then in C++, C# or
> VB.NET, etc.

I agree that component-based arch is good, but I hardly see
conjunction to SWIG/GDAL issue.

> I have worked with UNIX for 10 years but I am out of it for 7, so I
> don't know what is going on there.

One of the famouse COM-like components arch is Bonobo,
created by Miguel de Icaza.

> But I think that by exposing classes'
> names and behavior and attributes though a C++ library it is not going
> to make a lot of difference from a COM interface. That "COM-CORBA
> bridging" think look interesting I will check it out...

C++ vtable is compatible with COM binary interface, so you don't
have to use COM to expose interface-based access to your components.
But I still don't see how it applies to "SWIG or not to SWIG" issue.

> GDAL architecture is really good.

Yes, and the main advantage for me is that it's very clear.
You can learn how to write GDAL/OGR driver in minutes.
Genuine simplicity is a bless, I can say something about it :-)

> I use it trough C++, Python and trough
> my own Delphi wrapper :-).  My Delphi plans are still the same: develop
> a wrapper. It is fun. Some little tricks will make my wrapper easier to
> user and therefore more productive. So, it looks like Matt and I have
> the same goal.

IMHO, wrappers are good because they open wide range of "markets"
for particular software, e.g. for GDAL and I agree it's good to
have wrappers for scripting languages, etc.

Regarding Matt's idea, I'm not sure what are his objectives.
IMHO, if it's like rewriting or restructuring GDAL types into
new shape that fits conventions of particular project, then
I'd say it's a waste of time
But if wrapping GDAL brings new values, then it's a good idea.

> Finally, if that is the philosophy of GDAL. I don't argue about It. It's
> an excellent base layer and we will continue to create ours wrappers.

I am not able to answer for GDAL project. I'm only share my
personal opinions.

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