[GRASS-dev] [GRASS-user] raster attribute table problems

[Anna Petrášová]

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).
> >> > 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).

>
> > 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.

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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150117/937e3598/attachment-0001.html>