[GRASS-user] raster attribute table problems

[Markus Metz]

On Sat, Jan 17, 2015 at 11:50 PM, Anna Petrášová <kratochanna at gmail.com> wrote:
>
>
> On Sat, Jan 17, 2015 at 5:15 PM, Markus Metz <markus.metz.giswork at gmail.com>
> wrote:
>>
>> On Sat, Jan 17, 2015 at 10:50 PM, Anna Petrášová <kratochanna at gmail.com>
>> wrote:
>> >
>> >
>> > On Sat, Jan 17, 2015 at 2:44 PM, Markus Metz
>> > <markus.metz.giswork at gmail.com>
>> > wrote:
>> >>
>> >> On Sat, Jan 17, 2015 at 5:45 PM, Anna Petrášová <kratochanna at gmail.com>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > When importing National Landcover Dataset
>> >> > (http://www.mrlc.gov/nlcd2011.php), I would like to get the classes
>> >> > imported
>> >> > as raster labels. Gdalinfo reports existing attribute table where one
>> >> > of
>> >> > the
>> >> > columns is
>> >> >
>> >> >   <FieldDefn index="6">
>> >> >     <Name>Land Cover Class</Name>
>> >> >     <Type>2</Type>
>> >> >     <Usage>0</Usage>
>> >> >   </FieldDefn>
>> >> >
>> >> > r.in.gdal should be able to recognize it and use it as a label. The
>> >> > problem
>> >> > is that the field Usage reports 0, which represents GFU_Generic
>> >> > (General
>> >> > purpose field) instead of GFU_Name (Class name) and as a result
>> >> > r.in.gdal
>> >> > doesn't take it into account. The attributes are supposed to be
>> >> > stored
>> >> > in
>> >> > some vat.dbf file in the NLCD dataset (I was not able to open it on
>> >> > Ubuntu
>> >> > with LibreOffice due to some encoding problems to see what's exactly
>> >> > there).

It seems that the *.val.dbf file contains only cell counts per category.

>> >> > I don't understand how GDAL decides which column is generic or
>> >> > represents
>> >> > class name and I don't know if the problem is on GDAL's side or on
>> >> > the
>> >> > side
>> >> > of the data provider. Would it make sense to have an option in
>> >> > r.in.gdal
>> >> > to
>> >> > specify the name of the column which should be used for labels?
>> >>
>> >> You can use the table option of r.in.gdal to dump the raster attribute
>> >> table in plain text, then modify the table such that it can be used as
>> >> rules option for r.category.
>> >
>> >
>> > Thanks, I didn't quite get what the option is doing. So, I was trying to
>> > import the exported csv file as a standard vector attribute table with
>> > db.in.ogr (which uses v.in.ogr), however, ogr refused it probably
>> > because of
>> > the separator (pipe). Once I changed the separator to comma, it worked.
>>
>> Why did you try to import raster category labels as a vector attribute
>> table? The purpose of the RAT dump is to give you a chance to modify
>> the dumped raster attribute table with your preferred text processing
>> tools (a combination of cat, cut, tr, sed could help) in order to
>> create input for either r.category or r.colors.
>
>
> I was trying to find a way using only GRASS commands (e.g. for Windows
> users). But I must admit, even if the db.in.ogr worked, still it's not very
> straightforward (db.in.ogr -> db.select -> r.category). The landcover
> dataset is used a lot so I hoped there will be some easier way to get it
> into GRASS (which not experienced students with Windows would be able to
> do).

IMHO, the easiest solution is to manually modify the RAT dump such
that it can be used as input for r.category and/or r.colors. Manual
modification means modification outside GRASS to prepare input for
r.category/r.colors.

>>
>>
>> > Shouldn't r.in.gdal output a csv file with common separator like comma?
>> > I
>> > understand that you don't always need to import it as attribute table,
>> > but
>> > anyway comma seems more reasonable to me.
>>
>> Comma is too commonly used in text entries.
>
>
> True
>
>>
>> From a GRASS perspective, a raster attribute table is a GDAL-specific
>> thing that has nothing in common with a vector attribute table. There
>> are no raster attribute tables in GRASS. r.in.gdal tries to extract
>> information from GDAL raster attribute tables that can be used as
>> category labels (see r.category) or color rules (see r.colors).
>
>
> Sure. My initial suggestion was to specify which column should be used for
> labels. In case of multiband raster it could be problematic (but maybe this
> case would not come up often), so I understand the exported table is a more
> general solution but also less convenient. It seems this type of data are
> being used quite often (at least in the US) so we might get more feedback on
> the current solution.

The kind and content of raster attribute tables as reported by GDAL is
format-dependent. E.g. if GRASS exports the exact same raster map to
different formats, GDAL might report different raster attribute
tables. Therefore r.in.gdal tries to be fail-safe and only uses fields
with known usage (not custom or general purpose). Fields with usage
custom or general purpose need to be interpreted by the user, for each
band separately.

The land cover data in question comes in Erdas Imagine format (HFA for
GDAL), and raster attribute tables reported by GDAL for this format
are most probably wrong. You need to get the labeling from somewhere
else, e.g. by looking at the jpg file provided at
http://www.mrlc.gov/nlcd11_leg.php and creating a text file from that
image. This should work on all platforms. This is highly inconvenient,
please complain with the data providers.

Markus M

>
> Best,
>
> Anna
>
>>
>> Markus M
>>
>> >
>> > Thanks,
>> >
>> > Anna
>> >
>> >>
>> >> Markus M
>> >>
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Anna
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > grass-user mailing list
>> >> > grass-user at lists.osgeo.org
>> >> > http://lists.osgeo.org/mailman/listinfo/grass-user
>> >
>> >
>
>