Hi Even, Frank etc, I have updated the RFC to incorporate the comments from this thread.
http://trac.osgeo.org/gdal/wiki/rfc40_enhanced_rat_support Let me know if there is anything else that needs to be addressed, or if I have missed anything. Thanks, Sam. On 3 May 2013 20:18, Even Rouault <[email protected]> wrote: > 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
