[gdal-dev] GDAL Raster Attribute Tables.

Tue Apr 30 18:43:17 PDT 2013

Hi Peter,

Your RFC only mentions HFA driver but there other drivers that uses RAT as we can see by searching for GetDefaultRAT();

\frmts\aigrid\aigdataset.cpp(105):    virtual const GDALRasterAttributeTable *GetDefaultRAT();
\frmts\georaster\georaster_priv.h(250):    virtual const       GDALRasterAttributeTable *GetDefaultRAT();
\frmts\hfa\hfadataset.cpp(398):    virtual const GDALRasterAttributeTable *GetDefaultRAT();
\frmts\idrisi\IdrisiDataset.cpp(347):    virtual const GDALRasterAttributeTable *GetDefaultRAT();
\frmts\nitf\nitfdataset.h(300):        /*virtual const GDALRasterAttributeTable *GetDefaultRAT();
\frmts\raw\idadataset.cpp(119):    virtual const GDALRasterAttributeTable *GetDefaultRAT();

I don't know much about the IDA and AIG drivers. The GeoRaster driver uses regular database table to store Value Attribute Tables. The only way to do that is by implementing GetDefaultRAT() and SetDefaultRAT() and I completely agree that loading a large table at once in memory could be prohibitive. The NITF driver seems to have not implemented RAT support, the lines are commented. And if I remember correctly the Idrisi driver only uses RAT to share CategoryNames+ColorTable with ArcGIS.

But I think you have mentioned something about using OGR API to query and access the RAT. I liked that idea. 

Best regards,

Ivan

>  -------Original Message-------
>  From: Peter Bunting <petebunting at mac.com>
>  To: Frank Warmerdam <warmerdam at pobox.com>
>  Cc: gdal-dev at lists.osgeo.org <gdal-dev at lists.osgeo.org>
>  Subject: Re: [gdal-dev] GDAL Raster Attribute Tables.
>  Sent: Apr 30 '13 18:29
>  
>  Hi All,
>  
>  
>  Sam and I have prepared an RFC for our proposal for improving raster
>  attribute table (RAT) support and put it on the trac.
>  
>  
>  [LINK: http://trac.osgeo.org/gdal/wiki/rfc40_enhanced_rat_support]
>  http://trac.osgeo.org/gdal/wiki/rfc40_enhanced_rat_support
>  
>  
>  We'd be keen to here feedback on our proposal.
>  
>  
>  Best wishes,
>  
>  
>  Pete
>  
>  
>  ****************************************************
>  * Dr Pete Bunting
>  * Senior Lecturer in Remote Sensing
>  * Institute of Geography and Earth Sciences
>  * Aberystwyth University
>  * Aberystwyth
>  * Ceredigion
>  * SY23 3DB
>  * UK
>  *
>  * Ph: +44 (0) 1970 622615
>  * Mob: +44 (0) 7917 842743
>  * NZ Ph: +64 (0) 4 280 7430
>  * Email: [LINK: mailto:pfb at aber.ac.uk] pfb at aber.ac.uk
>  ****************************************************
>  
>  
>  On 24 Apr 2013, at 11:03, Peter Bunting <[LINK: mailto:petebunting at mac.com]
>  petebunting at mac.com> wrote:
>  
>  Thanks Frank,
>  
>  
>  Sam and I will prepare a RFC and pass it around. Should we post it to the
>  mailing list or add directly to the trac?
>  
>  
>  Best wishes,
>  
>  
>  Pete
>  
>  
>  On 24 Apr 2013, at 10:17, Frank Warmerdam <[LINK:
>  mailto:warmerdam at pobox.com] warmerdam at pobox.com> wrote:
>  
>  Peter,
>  
>  
>  Actually, I should have added that I think a following stage should be for
>  you to prepare a formal detailed RFC proposal for voting on by the PSC
>  rather than just throwing a patch at us since this is an API change.
>  
>  
>  Best regards,
>  Frank
>  
>  
>  On Tue, Apr 23, 2013 at 3:16 PM, Frank Warmerdam <[LINK:
>  mailto:warmerdam at pobox.com] warmerdam at pobox.com> wrote:
>  
>  
>  On Tue, Apr 23, 2013 at 1:57 PM, Peter Bunting <[LINK:
>  mailto:petebunting at mac.com] petebunting at mac.com> wrote:
>  
>  
>  Hi All,
>  
>  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.
>  
>  
>  Peter,
>  
>  
>  You do seem to be pushing raster attribute tables well beyond the expected
>  use cases.
>  
>  
>  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.
>  
>  
>  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.
>  
>  
>  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.
>  
>  
>  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?
>  
>  
>  I had not been contemplating treating raster attribute tables as OGR
>  layers.
>  
>  I must confess that I'm still not certain that pushing raster attribute
>  tables to be very large is a good idea.
>  
>  
>  Best
>  regards,---------------------------------------+--------------------------------------
>  I set the clouds in motion - turn up   | Frank Warmerdam, [LINK:
>  mailto:warmerdam at pobox.com] warmerdam at pobox.com
>  light and sound - activate the windows | [LINK:
>  http://pobox.com/~warmerdam] http://pobox.com/~warmerdam
>  and watch the world go round - Rush    | Geospatial Software Developer
>  
>  
>  --
>  ---------------------------------------+--------------------------------------
>  I set the clouds in motion - turn up   | Frank Warmerdam, [LINK:
>  mailto:warmerdam at pobox.com] warmerdam at pobox.com
>  light and sound - activate the windows | [LINK:
>  http://pobox.com/~warmerdam] http://pobox.com/~warmerdam
>  and watch the world go round - Rush    | Geospatial Software Developer
>  
>  _______________________________________________
>  gdal-dev mailing list
>  [LINK: mailto:gdal-dev at lists.osgeo.org] gdal-dev at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/gdal-dev
>  
>  --------------------
>  _______________________________________________
>  gdal-dev mailing list
>  [LINK: compose.php?to=gdal-dev at lists.osgeo.org] gdal-dev at lists.osgeo.org
>  [LINK: http://lists.osgeo.org/mailman/listinfo/gdal-dev]
>  http://lists.osgeo.org/mailman/listinfo/gdal-dev