GeoTiff's do not support Raster Attribute Tables. Try sticking to HFA
instead.
Sam.
On 20 January 2014 12:55, sam sung wrote:
> Hello, folks,
>
> I tried to build a Raster Attribute Table (denoted as RAT below) for a
> GeoTiff raster file(attached as “test.tif”) in C within Visual Studio 2008
Hi Ivan,
Unfortunately the color table API does not support the functionality that
was added to the RAT API in RFC40. As a result, dealing with large color
tables can be problematic.
Yes the HFA driver does report colors correctly as 0-255 with the color
table API and one solution could be to add
Hi List,
There appears to be an inconsistency in the way color columns are handled
within Raster Attribute Tables (RATs) by different drivers. Color columns
are currently identified by their 'usage' setting - GFU_Red, GFU_Green,
GFU_Blue and GFU_Alpha. The HFA driver presents color columns as doub
Hi Ivan,
Yes I can see this also with the trunk version. The problem is that with
the RFC40 changes the HFA driver always returns something from
GetDefaultRAT even if it is an empty table - you can now start writing data
directly into the table with the returned object.
Below is a patch to preven
Hi Even,
http://trac.osgeo.org/gdal/ticket/5129
Yes I have recently updated the patch with the changes you and Frank
suggested to GetValueAsString so the returned pointer is temporary. I have
also changed the definition of GetDefaultRAT to return a non-const pointer
and updated relevant drivers.
Dear PSC members,
I propose a motion to get RFC 40 - "Improving performance of Raster
Attribute Table implementation for large tables" formally adopted.
This adds some new functionality for GDAL 2.0. Even, Frank and others have
made suggestions and these have been incorporated into the RFC:
http:
Hi Frank,
I've updated the RFC.
Sam.
On 16 May 2013 10:26, Frank Warmerdam wrote:
>
>
>
> On Wed, May 15, 2013 at 2:58 PM, Sam Gillingham
> wrote:
>
>> Etienne, Frank,
>>
>> The original idea was to save space with the byte type, although I admit
;> booleans as Byte instead of integer.
>>
>
> everywhere else booleans are defined as integers like this
>
> int bSomeVar;
>
>
>>
>> Best regards,
>> Frank
>>
>>
>>
>> On Mon, May 13, 2013 at 9:37 PM, Sam Gillingham > > wrote:
>>
>
Hi All,
I propose a motion to get RFC 40 - "Improving performance of Raster
Attribute Table implementation for large tables" adopted. This adds some
new functionality for GDAL 2.0. Even and others have made suggestions and
these have been incorporated into the RFC:
http://trac.osgeo.org/gdal/wiki
wrote:
> Selon Sam Gillingham :
>
> > 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 attribu
nverting a GDALRasterAttributeTable to a GDALIORasterAttributeTable
(maybe an alternate constructor of GDALRasterAttributeTable).
Would this be a more acceptable proposal?
Sam.
On 3 May 2013 11:32, Even Rouault wrote:
> Le vendredi 03 mai 2013 00:23:48, Sam Gillingham a écrit :
> > Hi
Hi Evan,
Response to your points below:
1) Good point about bool not being available in C. How about making
this an 8 bit int instead? The idea was to be able to express
True/False values without using a whole integer, thus saving space. We
included it in case future drivers support it.
2) I was
Thanks Ivan,
We explicitly referenced the HFA driver as this is one which is
commonly used and we are familiar with the source code having
submitted a number of patches for the driver.
We plan to provide default implementations of the new functions which
will call the existing Get/Set functions (
13 matches
Mail list logo
