[GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters

[Markus Metz]

On Mon, Feb 24, 2014 at 9:50 PM, Markus Metz
<markus.metz.giswork at gmail.com> wrote:
> On Mon, Feb 24, 2014 at 8:15 PM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
>>
>>
>>
>> On Sat, Feb 22, 2014 at 8:11 AM, Markus Metz <markus.metz.giswork at gmail.com>
>> wrote:
>>>
>>> On Fri, Feb 21, 2014 at 5:45 PM, Markus Metz
>>> <markus.metz.giswork at gmail.com> wrote:
>>> > On Fri, Feb 21, 2014 at 5:39 PM, Vaclav Petras <wenzeslaus at gmail.com>
>>> > wrote:
>>> >> Unfortunately, I have data where GDAL does not identify the columns.
>>> >
>>> > Does GDAL find a raster attribute table?
>>> >
>>> >> One is
>>> >> the only string there, and the other three are the red, green, blue (in
>>> >> the
>>> >> range 0-1).
>>> >
>>> > ... which would need to be transformed to the range 0,255.
>>> >
>>> > Here it seems easier to edit the attribute table outside GRASS, then
>>> > use r.category and r.colors.
>>> >
>>> >> For me it is clear what column I would like to transform to
>>> >> label and to color rules but I'm not sure if GDAL has even a chance to
>>> >> determine it somehow. So, some options to set this would be great.
>>> >>
>>> >> I can share the data, they are from a public source.
>>>
>>> For these data, GDAL can not determine the usage of the "RED",
>>> "GREEN", and "BLUE" fields, also not for the "FBFM13" field. IMHO, the
>>> best we could do is add an option to dump the raster attribute table
>>> in text format and let the user modify it such that it can be used
>>> with r.category and/or r.colors. The GDAL function to dump a raster
>>> attribute table dumps it in xml, and the documentation says itself
>>> that this is barely readable, so we would need our own dump function.
>>>
>> Hi Markus,
>>
>> I was actually dealing with this just before you started committing the
>> attribute table related things. Since I don't know GDAL, I asked and it
>> seems that the right thing to do is to use API [1] to generate whatever is
>> appropriate for you (so exactly what you say).
>
> According to this link, it would be easy to implement the RAT dump as
> CSV in r.in.gdal.

Done in trunk r62160,7.

>> Now it seems that the best
>> will be to [...] generate rules for colors or labels.

This is done by r.in.gdal automatically since r59073, as long as GDAL
reports field usages that are suitable to generate rules for colors or
labels.

Markus M

>
> The user would need to define these rules if GDAL can not figure them
> out from the intended usage of the fields. In order to do so, the user
> must be able to inspect the attribute table, preferably not in XML
> format. CSV seems to me the logical choice.
>
>> This could be done in separate (C/Python) module based on [1] but having
>> this as a part of r.in.gdal would be advantageous (number of parameters
>> would be higher but you would import everything in one step).
>
> It would require two steps: first dump all the RATs in human-readable
> format, such that the user can specify any rules. Note that rules
> including any scale factor would need to be specified for each band in
> the GDAL raster dataset. The number of parameters would thus explode.
>
> Markus M
>
>>
>> It is possible that I will write Python module to turn attribute table into
>> label and color rules in next weeks but I cannot promise.
>>
>> Vaclav
>>
>> [1]
>> http://gis.stackexchange.com/questions/84700/how-to-show-only-raster-attribute-table-using-gdal/
>>
>>> Markus M
>>>
>>> >
>>> > I would be interested.
>>> >
>>> > Markus M
>>> >
>>> >>
>>> >> But anyway, connection to color tables and labels is great, colors and
>>> >> labels solves at least significant part of the cases where raster
>>> >> attribute
>>> >> tables are used.
>>> >>
>>> >> Vaclav
>>> >>
>>> >>
>>> >> On Fri, Feb 21, 2014 at 11:26 AM, Moritz Lennert
>>> >> <mlennert at club.worldonline.be> wrote:
>>> >>>
>>> >>> On 21/02/14 17:12, Markus Metz wrote:
>>> >>>>
>>> >>>> On Fri, Feb 21, 2014 at 2:00 PM, Moritz Lennert
>>> >>>> <mlennert at club.worldonline.be> wrote:
>>> >>>>>
>>> >>>>> On 21/02/14 11:30, Markus Metz wrote:
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On Fri, Feb 21, 2014 at 9:35 AM, Moritz Lennert
>>> >>>>>> <mlennert at club.worldonline.be> wrote:
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> On 20/02/14 22:14, Markus Metz wrote:
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> I would not replace a working gdal version with a probably not
>>> >>>>>>>> working
>>> >>>>>>>> gdal version. Your gdalinfo reported a raster attribute table,
>>> >>>>>>>> not
>>> >>>>>>>> mine. You could double-check again if your gdalinfo still finds a
>>> >>>>>>>> raster attribute table, then import with r.in.gdal.
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> Out of curiosity: if a table contains several columns which one(s)
>>> >>>>>>> is/are
>>> >>>>>>> imported and in what form do they appear in GRASS (I don't have a
>>> >>>>>>> file
>>> >>>>>>> here
>>> >>>>>>> to test myself) ?
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Each column has a dedicated usage. For "name" usage, the column is
>>> >>>>>> treated as category labels. For any of the color usages, the column
>>> >>>>>> is
>>> >>>>>> treated as corresponding red, green, or blue color. See also the
>>> >>>>>> gdal
>>> >>>>>> documentation [0]. Currently, r.out.gdal exports category labels or
>>> >>>>>> color rules to a raster attribute table with the new -t flag, and
>>> >>>>>> r.in.gdal automatically imports any information it finds.
>>> >>>>>>
>>> >>>>>> Markus M
>>> >>>>>>
>>> >>>>>> [0]
>>> >>>>>> http://www.gdal.org/gdal_8h.html#a27bf786b965d5227da1acc2a4cab69a1
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> So, IIUC you get the GFU_Name and the color information, but if the
>>> >>>>> table
>>> >>>>> contains several fields (which I guess will be of type GFU_Generic)
>>> >>>>> these
>>> >>>>> are ignored ?
>>> >>>>
>>> >>>>
>>> >>>> GFU_Generic usage is ignored because it is unknown what this could be
>>> >>>> good for.
>>> >>>
>>> >>>
>>> >>> VAT tables allow as many fields as the user wants, not only a class
>>> >>> name.
>>> >>> But I don't know (and can't tell from ESRI's documentation) whether
>>> >>> these
>>> >>> additional fields will all be considered GFU_Names or GFU_Generics)
>>> >>> and as I
>>> >>> don't have relevant data here (and data that colleagues created for me
>>> >>> causes an error with gdal...) I can't test this at this stage.
>>> >>>
>>> >>> My question was: if a raster has several fields as in the attribute
>>> >>> table,
>>> >>> would it be possible to chose the field to use as labels in GRASS ?
>>> >>>
>>> >>> Moritz
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> grass-user mailing list
>>> >>> grass-user at lists.osgeo.org
>>> >>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>> >>
>>> >>
>>
>>