<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 23, 2013 at 1:57 PM, Peter Bunting <span dir="ltr"><<a href="mailto:petebunting@mac.com" target="_blank">petebunting@mac.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div dir="ltr"><div>Hi All,<br><br></div>We were wondering if there is any interest in the GDAL community for improving the Raster Attribute Implementation? Within our group of collaborators we have been representing image segmentations as clump files often large attribute tables containing millions of rows and numerous columns of data used for classification. We are finding the current approach that reads a single value at a time with the whole attribute table in memory to be quite poor performance wise and resource (i.e., memory) hungry. </div>
</div></div></blockquote><div><br></div><div style>Peter,</div><div style><br></div><div style>You do seem to be pushing raster attribute tables well beyond the expected use cases. </div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div dir="ltr"><div><div><br></div>We would like to propose a new implementation that allows reading and writing of whole chunks of a single column within the attribute table more like RasterIO. </div>
</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div dir="ltr"><div><br>If we were to create a patch, would the GDAL community be receptive to this? We were thinking this would be incorporated within the interface changes in GDAL 2.0.</div>
</div></div></div></blockquote><div><br></div><div style>I would be receptive to additional read (and perhaps write) methods for chunks of the attribute table at a time if it can be done with a minimum of distruption of the existing api. </div>
<div style>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div dir="ltr"><div>It has been muted that OGR might be merged into GDAL in version 2.0 if this were to occurred how would attribute tables be dealt with and are the changes we proposing something that needs to be considered in that wider context also?<br>
</div></div></div></div></blockquote><div><br></div><div style>I had not been contemplating treating raster attribute tables as OGR layers.</div><div style> </div><div style>I must confess that I'm still not certain that pushing raster attribute tables to be very large is a good idea. </div>
<div style><br></div><div style>Best regards,</div></div>---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up   | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>
light and sound - activate the windows | <a href="http://pobox.com/~warmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>and watch the world go round - Rush    | Geospatial Software Developer<br>
</div></div>