[gdal-dev] GDAL Raster Attribute Tables.

[Sam Gillingham]

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 <even.rouault at mines-paris.org> wrote:

> Selon Sam Gillingham <gillingham.sam at gmail.com>:
>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130505/f67503c5/attachment.html>