> From: [email protected] > To: [email protected] > Subject: Re: [gdal-dev] Fwd: Color Columns in Raster Attribute Tables > Date: Sat, 18 Jan 2014 15:22:43 +0100 > CC: [email protected]; [email protected] > > Le samedi 18 janvier 2014 15:18:20, Ivan Lucena a écrit : > > Hi Even, > > > > In a parallel and almost not related topic, I am getting users complains > > that gdal_translate crashes > > Well, that should be debugged and fixed... You don't have more details ?
I waiting to get a sample file to debug it, but even when it doesn't crash they need to manage what to do with the useless VAT table on the database. > > > or waste their time and storage space with > > some ridiculous RAT that doesn't make any sense for their use case. Maybe > > we should have a -noRAT option on gdal_translate. I could also add an > > "RAT2VAT=NO" create-option on GeoRaster driver. > > Yes, -norat option in gdal_translate makes sense. IMHO, I don't think we should go to big deal of RPC discussion and voting to add that option to gdal_translate. One work around that they are using is to run gdal_translate -of VRT, since VRT drivers does not support RAT, they can use it as input instead of the HFA .img files. They could just add -outsize 100% 100%, I guess. That would also do the trick without create VRT files. But gdal_translate is not the only way to run the CreateCopy of a driver, so I think I am going to add my create-option anyway. Regards, Ivan > > > > > Any better idea? > > > > Regards, > > > > Ivan > > > > > From: [email protected] > > > To: [email protected] > > > Date: Fri, 17 Jan 2014 20:33:21 +0100 > > > CC: [email protected] > > > Subject: Re: [gdal-dev] Fwd: Color Columns in Raster Attribute Tables > > > > > > Le vendredi 17 janvier 2014 01:21:14, Sam Gillingham a écrit : > > > > Hi Even, Frank, > > > > > > > > I'm interested to hear if you have an opinion on this. Is this > > > > behaviour by design or a bug in the HFA driver? > > > > > > > > I'm happy to supply a patch to the HFA driver if you think this is > > > > sensible solution. I just want to make sure I'm not missing > > > > anything... > > > > > > RAT is not my cup of tea, so I'm not sure to have a particularly > > > enlightened opinion on this. It is a bit annoying that the HFA behaviour > > > goes against the documentation. AFAIK nobody has ever complained about > > > this, so this might be just a sign that RAT is not widely used. Provided > > > that it is documented in MIGRATION_GUIDE.TXT, I think it would be OK to > > > make the driver behaviour consistant with the doc. > > > Actually, I'm just thinking to the following point : if the color table > > > in IMG is represented as a float, could values that are not of the form > > > N / 255 be possible (when generated by Imagine) ? If so, we would loose > > > information by casting to int. It is a bit strange they have selected a > > > floating point serialization. > > > Another possibility would be to indicate the validity range of the > > > attribute, e.g 0-255 or 0-1, so that applications can normalize to > > > [0,255] if they need to. > > > > > > > Thanks for your time, > > > > > > > > Sam. > > > > > > > > ---------- Forwarded message ---------- > > > > From: Sam Gillingham <[email protected]> > > > > Date: 14 January 2014 08:51 > > > > Subject: Re: [gdal-dev] Color Columns in Raster Attribute Tables > > > > To: Ivan Lucena <[email protected]> > > > > Cc: gdal dev <[email protected]> > > > > > > > > > > > > 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 RFC40 functionality to the > > > > color table API. However, it does seem that it does make sense to be > > > > able to manipulate colors from the RAT API for e.g. setting colors > > > > based on the value(s) found in other attribute columns easily. > > > > > > > > I accept that no consistency can be expected for user defined columns > > > > (usage == GFU_Generic) but I would have though applications could > > > > depend on the color columns since they are marked as such by their > > > > usage. In fact the documentation for the usage values ( > > > > http://www.gdal.org/gdal_8h.html#a27bf786b965d5227da1acc2a4cab69a1) > > > > does specify them to be 0-255 so this seems to have been the intention > > > > and is maybe just a bug in the HFA driver. > > > > > > > > Sam. > > > > > > > > On 13 January 2014 15:18, Ivan Lucena <[email protected]> wrote: > > > > > Hi Sam, > > > > > > > > > > In GDAL color table is supported by the GDALColorTable > > > > > http://gdal.org/classGDALColorTable.html not by > > > > > GDALRasterAttributeTable > > > > > http://gdal.org/classGDALRasterAttributeTable.html. > > > > > > > > > > The GDALColorTable is a little bit limited but it is pretty much > > > > > consistent across all the drivers that support it. For example, when > > > > > you say that HFA reports RGBA with values from 0..1 as RAT it > > > > > probably reports the correct 0..255 as GDALGetColorTable or it > > > > > doesn't report it at all, because of the GDALColorTable limitation, > > > > > like data type or number of colors. > > > > > > > > > > But IMHO, there is no reason to expect consistency on the > > > > > representation of color table from a driver RAT. An RAT could be > > > > > user defined or generated by some driver or application. > > > > > > > > > > What you are seem is that some drivers are using, or maybe abusing, > > > > > the freedom format of RAT to report information than can be > > > > > understood by some particular application or software (mea culpa on > > > > > one of those). > > > > > > > > > > Best regards, > > > > > > > > > > Ivan > > > > > > > > > > ------------------------------ > > > > > Date: Mon, 13 Jan 2014 13:06:01 +1300 > > > > > From: [email protected] > > > > > To: [email protected] > > > > > Subject: [gdal-dev] Color Columns in Raster Attribute Tables > > > > > > > > > > > > > > > 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 doubles between 0 and 1 as this is how they are > > > > > stored in the file. The IDRISI driver presents them as integers > > > > > between 0 and 255 like the Color Table API. Code that uses color > > > > > columns from the RAT API currently needs to know which driver it is > > > > > using, defeating one of the aims of GDAL. > > > > > > > > > > I propose that the RAT API be defined so that color columns always > > > > > appear as Integer 0-255 no matter what type and range they are > > > > > stored as. This would make the RAT API consistent with the Color > > > > > Table API and would mean a change to the HFA driver > > > > > > > > > > Another option is that flags are added to the RAT SetValue, > > > > > GetValueAs* and ValuesIO calls to specify the conversion to/from the > > > > > native type. This seems a bigger change. > > > > > > > > > > Any thoughts? > > > > > > > > > > Sam. > > > > > > > > > > _______________________________________________ gdal-dev mailing list > > > > > [email protected] > > > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- > Geospatial professional services > http://even.rouault.free.fr/services.html
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
