[gdal-dev] GDAL Raster Attribute Tables.

[Even Rouault]

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