Selon Sam Gillingham <[email protected]>: > Hi Even, > > Another alternative that will have less impact on existing code and > behaviour may be to leave GetDefatultRAT and SetDefaultRAT as they are (ie > returning an in-memory representation of the attribute table - > GDALRasterAttributeTable). This means existing code can Clone() and > Serialize() etc. > > We could then have another function on GDALRasterBand (eg GetRAT()) that > returns the virtual base class version ('GDALIORasterAttributeTable'), if > supported by the driver. We don't need a SetRAT() as the intention is that > all modifications to the returned object are written to disc. Applications > could call GetRAT() first to see if they can use the 'new' way, or drop > back to GetDefaultRAT if they can't (memory permitting). > > GDALRasterAttributeTable doesn't need to be derived from > GDALIORasterAttributeTable (although it could be). We could have a way of > converting a GDALRasterAttributeTable to a GDALIORasterAttributeTable > (maybe an alternate constructor of GDALRasterAttributeTable). > > Would this be a more acceptable proposal?
Hi Sam, I didn't want to mean that the previous proposal was not acceptable. I was just underlying that it had consequences a bit larger than the original scope of the RFC, without being a complete revolution. I'd be interested if FrankW could share his views on this, his being the author of the RAT mechanism. I'm not entirely convinced by the above alternate proposal. Seems a bit confusing from the user point of view : "should I use GetRAT() or GetDefaultRAT() ?". And I've not well understood how GDALRasterAttributeTable and GDALIORasterAttributeTable would relate. Both would be available in the C++ API ? We should try to keep it as simple as possible IMHO. To go back on the first idea - GDALRasterAttributeTable being an abstract class, GDALDefaultRasterAttributeTable deriving it to implement the functionnality of 1.X GDALRasterAttributeTable, and a HFARasterAttributeTable, specialized version of GDALRasterAttributeTable implementing the ValuesIO() methods -, how would it be complicated to have Clone() and Serialize() to work in HFARasterAttributeTable only if the RAT is of reasonable size (e.g. product of GetRowCount() * GetColCount() < 1 000 000) ? Clone() could return a GDALDefaultRasterAttributeTable. Actually, Clone() could be lazily implemented as a "return new GDALDefaultRasterAttributeTable()->Deserialize(Serialize())" (with the appropriate check if Serialize() returns NULL). Even _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
