<div dir="ltr"><div>Hi Even, Frank etc,<br><br></div>I have updated the RFC to incorporate the comments from this thread.<br><div><br><a href="http://trac.osgeo.org/gdal/wiki/rfc40_enhanced_rat_support">http://trac.osgeo.org/gdal/wiki/rfc40_enhanced_rat_support</a><br>
<br></div><div>Let me know if there is anything else that needs to be addressed, or if I have missed anything.<br><br></div><div>Thanks,<br></div><div>Sam.<br></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 3 May 2013 20:18, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Selon Sam Gillingham <<a href="mailto:gillingham.sam@gmail.com">gillingham.sam@gmail.com</a>>:<br>
<div class="im"><br>
> Hi Even,<br>
><br>
> Another alternative that will have less impact on existing code and<br>
> behaviour may be to leave GetDefatultRAT and SetDefaultRAT as they are (ie<br>
> returning an in-memory representation of the attribute table -<br>
> GDALRasterAttributeTable). This means existing code can Clone() and<br>
> Serialize() etc.<br>
><br>
> We could then have another function on GDALRasterBand (eg GetRAT()) that<br>
> returns the virtual base class version ('GDALIORasterAttributeTable'), if<br>
> supported by the driver. We don't need a SetRAT() as the intention is that<br>
> all modifications to the returned object are written to disc. Applications<br>
> could call GetRAT() first to see if they can use the 'new' way, or drop<br>
> back to GetDefaultRAT if they can't (memory permitting).<br>
><br>
> GDALRasterAttributeTable doesn't need to be derived from<br>
> GDALIORasterAttributeTable (although it could be). We could have a way of<br>
> converting a GDALRasterAttributeTable to a GDALIORasterAttributeTable<br>
> (maybe an alternate constructor of GDALRasterAttributeTable).<br>
><br>
> Would this be a more acceptable proposal?<br>
<br>
</div>Hi Sam,<br>
<br>
I didn't want to mean that the previous proposal was not acceptable. I was just<br>
underlying that it had consequences a bit larger than the original scope of the<br>
RFC, without being a complete revolution. I'd be interested if FrankW could<br>
share his views on this, his being the author of the RAT mechanism.<br>
<br>
I'm not entirely convinced by the above alternate proposal. Seems a bit<br>
confusing from the user point of view : "should I use GetRAT() or<br>
GetDefaultRAT() ?". And I've not well understood how<br>
GDALRasterAttributeTable and GDALIORasterAttributeTable would relate. Both would<br>
be available in the C++ API ? We should try to keep it as simple as possible<br>
IMHO.<br>
<br>
To go back on the first idea - GDALRasterAttributeTable being an abstract class,<br>
GDALDefaultRasterAttributeTable deriving it to implement the functionnality of<br>
1.X GDALRasterAttributeTable, and a HFARasterAttributeTable, specialized version<br>
of GDALRasterAttributeTable implementing the ValuesIO() methods -, how would it<br>
be complicated to have Clone() and Serialize() to work in<br>
HFARasterAttributeTable only if the RAT is of reasonable size (e.g. product of<br>
GetRowCount() * GetColCount() < 1 000 000) ?  Clone() could<br>
return a GDALDefaultRasterAttributeTable. Actually, Clone() could be lazily<br>
implemented as a "return new<br>
GDALDefaultRasterAttributeTable()->Deserialize(Serialize())" (with the<br>
appropriate check if Serialize() returns NULL).<br>
<span class=""><font color="#888888"><br>
Even<br>
</font></span></blockquote></div><br></div></div></div></div>