<div dir="ltr">I also (respectfully) think that there are too many classes (mostly the abstract classes and interfaces) which make it a bit hard to understand.<div><br></div><div>I like Vincent's second suggestion to have 3 base Dataset classes (GDALRasterDataset, GDALVectorDataset, GDALHybridDataset) which inherit from GDALDataset, and an enum (vector,raster,hybrid) to easily query which type the Dataset is (or which type its driver supports). You then subclass the relevant Dataset class and it *should* work auto-magically for rasters.  For example, a given Dataset which subclasses GDALDataset would be migrated as  a subclass of GDALRasterDataset, which would imply that it does not have a vector dataset. If the implementation changes to allow vector, then you would change its parent and implement relevant vector methods.</div>
<div><br></div><div>My view on this is KISS with a minimum number of classes...</div><div><br></div><div>cheers</div><div>Etienne<br><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 9:13 AM, Vincent Mora <span dir="ltr"><<a href="mailto:vincent.mora@oslandia.com" target="_blank">vincent.mora@oslandia.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 25/03/2014 11:44, Even Rouault wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Selon Vincent Mora <<a href="mailto:vincent.mora@oslandia.com" target="_blank">vincent.mora@oslandia.com</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 24/03/2014 21:46, Even Rouault wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
"Release soon, release early", so for people who like UML diagrams (there<br>
</blockquote>
is<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
also a prototype of C++ classes for those who don't like UML very much),<br>
</blockquote>
here's<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
a blog entry with the outcome of my thoughts for a possible re-organisation<br>
</blockquote>
of<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the GDAL/OGR class hierarchy<br>
<br>
<br>
</blockquote></blockquote>
<a href="http://erouault.blogspot.ca/2014/03/draft-gdalogr-class-hierarchy-for-gdal.html" target="_blank">http://erouault.blogspot.ca/<u></u>2014/03/draft-gdalogr-class-<u></u>hierarchy-for-gdal.html</a><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't understand the need for HandleRasterData() and HandleVectorData().<br>
<br>
Isn't inheriting from GDALEmptyRasterDataset or GDALEmptyVectorDataset<br>
sufficient to convey the information that the class doesn't handle those<br>
kind of datasets.<br>
<br>
A call to GetLayerCount()/<u></u>GetRasterCount() from the class user is<br>
sufficient to say "no vector/raster data here", and a dynamic _cast to<br>
GDALEmptyVectorDataset/<u></u>GDALEmptyRasterDataset is even clearer to me, so<br>
HandleRasterData()/<u></u>HandleVectorData() would be a third way to tell the<br>
same thing.<br>
</blockquote>
Actually, when thinking more about this, this kind of information should be at<br>
the driver level, and not at the dataset level. The idea is that there are use<br>
cases where you want to know if a driver can handle only vector, only raster, or<br>
both. For example if you still want to have separate Open dialog boxes for<br>
raster or vector.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also I'm not sure about the names GDALAbstract* since those are partial<br>
implementations.<br>
</blockquote>
I know I'm not very good at naming. Do you have an alternative proposal ? The<br>
issue is that with my draft we end up with a lot of classes and interfaces, so<br>
it is not obvious to find a good name to reflect their content.<br>
</blockquote></div></div>
Partial sound ok to me, but I not so good at naming  ?<br>
<br>
Considering the number of classes, I gave it some thoughts this morning and, like Dmitry, thought of merging the Abtract (Partial) into the interface before realizing that, even if it works (you can overload de default function in Empty) it's a bit ugly and I ended up preferring your solution.<br>

<br>
An altenative would be to have a Dataset with both aspects and provide three partial specialisations: one for vector (it will behave like empty raster) one for raster, and one for both. Code duplications could be avoided by implementing protected member functions in the Dataset class and simply calling them in the implementations of partial specialization. This solution avoid the diamond shaped inheritance diagram of hell :)<br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  Even<br>
<br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
______________________________<u></u>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/gdal-dev</a><br>
</div></div></blockquote></div><br></div>