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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
