[gdal-dev] Draft GDAL/OGR class hierarchy for GDAL 2.0

[Even Rouault]

Hi,

answering some questions from Dmitry in the comment of
http://erouault.blogspot.ca/2014/03/draft-gdalogr-class-hierarchy-for-gdal.html#comment-form
:

> A few questions:
> 1) Why the need GDALAbstractXXXDataset and GDALEmptyXXXDataset? May be
Abstract will be enouth?

--> The AbstractXXX has the actual code of current GDALDataset or OGRDataSource
that is needed for real implementations. Whereas EmptyXXXX is used to provide a
null implementation of the raster or vector interface for drivers that are
raster of vector only, but that need to expose both interfaces for the
consistance of the unification.

> 2) There is some therminology problem GDALIMajorObject and GDALMajorObject.

Well, the first one is the interface and the other one is the implementation.
The idea is that the 3 classes GDALRasterDataset (raster only),
GDALVectorDataset (vector only) and GDALDataset (raster and vector) can be seen
as MajorObject.

> 3) The metadata may be on dataset level and band/layer level. So it maybe to
do GDALMajorDataset for datasets and GDALMajorLayer for band/layer?

Not sure to follow what you meant.

Even

> Hi,
>
> "Release soon, release early", so for people who like UML diagrams (there is
> also a prototype of C++ classes for those who don't like UML very much),
> here's
> a blog entry with the outcome of my thoughts for a possible re-organisation
> of
> the GDAL/OGR class hierarchy
>
>
http://erouault.blogspot.ca/2014/03/draft-gdalogr-class-hierarchy-for-gdal.html
>
> Comments, suggestions, ideas greatly welcome. It is really a challenge to
> revamp
> the class hierarchy while avoiding to touch every existing driver in a
> non-automated way.
>
> Even
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>