<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 17, 2015 at 2:44 PM, Markus Metz <span dir="ltr"><<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, Jan 17, 2015 at 5:45 PM, Anna Petrášová <<a href="mailto:kratochanna@gmail.com">kratochanna@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> When importing National Landcover Dataset<br>
> (<a href="http://www.mrlc.gov/nlcd2011.php" target="_blank">http://www.mrlc.gov/nlcd2011.php</a>), I would like to get the classes imported<br>
> as raster labels. Gdalinfo reports existing attribute table where one of the<br>
> columns is<br>
><br>
>   <FieldDefn index="6"><br>
>     <Name>Land Cover Class</Name><br>
>     <Type>2</Type><br>
>     <Usage>0</Usage><br>
>   </FieldDefn><br>
><br>
> r.in.gdal should be able to recognize it and use it as a label. The problem<br>
> is that the field Usage reports 0, which represents GFU_Generic (General<br>
> purpose field) instead of GFU_Name (Class name) and as a result r.in.gdal<br>
> doesn't take it into account. The attributes are supposed to be stored in<br>
> some vat.dbf file in the NLCD dataset (I was not able to open it on Ubuntu<br>
> with LibreOffice due to some encoding problems to see what's exactly there).<br>
> I don't understand how GDAL decides which column is generic or represents<br>
> class name and I don't know if the problem is on GDAL's side or on the side<br>
> of the data provider. Would it make sense to have an option in r.in.gdal to<br>
> specify the name of the column which should be used for labels?<br>
<br>
</div></div>You can use the table option of r.in.gdal to dump the raster attribute<br>
table in plain text, then modify the table such that it can be used as<br>
rules option for r.category.<br></blockquote><div><br></div><div>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. 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.</div><div><br></div><div>Thanks,</div><div><br></div><div>Anna</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Markus M<br>
<br>
><br>
> Thanks,<br>
><br>
> Anna<br>
><br>
><br>
><br>
> _______________________________________________<br>
> grass-user mailing list<br>
> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
</blockquote></div><br></div></div>