On Sat, Jan 17, 2015 at 11:50 PM, Anna Petrášová kratocha...@gmail.com wrote:
On Sat, Jan 17, 2015 at 5:15 PM, Markus Metz markus.metz.gisw...@gmail.com
wrote:
On Sat, Jan 17, 2015 at 10:50 PM, Anna Petrášová kratocha...@gmail.com
wrote:
On Sat, Jan 17, 2015 at 2:44 PM, Markus Metz
markus.metz.gisw...@gmail.com
wrote:
On Sat, Jan 17, 2015 at 5:45 PM, Anna Petrášová kratocha...@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
NameLand Cover Class/Name
Type2/Type
Usage0/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
