<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 17, 2015 at 5:15 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 10:50 PM, Anna Petrášová <<a href="mailto:kratochanna@gmail.com">kratochanna@gmail.com</a>> wrote:<br>
><br>
><br>
> On Sat, Jan 17, 2015 at 2:44 PM, Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Sat, Jan 17, 2015 at 5:45 PM, Anna Petrášová <<a href="mailto:kratochanna@gmail.com">kratochanna@gmail.com</a>><br>
>> 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<br>
>> > imported<br>
>> > as raster labels. Gdalinfo reports existing attribute table where one of<br>
>> > 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<br>
>> > 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<br>
>> > r.in.gdal<br>
>> > doesn't take it into account. The attributes are supposed to be stored<br>
>> > in<br>
>> > some vat.dbf file in the NLCD dataset (I was not able to open it on<br>
>> > Ubuntu<br>
>> > with LibreOffice due to some encoding problems to see what's exactly<br>
>> > there).<br>
>> > I don't understand how GDAL decides which column is generic or<br>
>> > represents<br>
>> > class name and I don't know if the problem is on GDAL's side or on the<br>
>> > side<br>
>> > of the data provider. Would it make sense to have an option in r.in.gdal<br>
>> > to<br>
>> > specify the name of the column which should be used for labels?<br>
>><br>
>> 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>
><br>
><br>
> Thanks, I didn't quite get what the option is doing. So, I was trying to<br>
> import the exported csv file as a standard vector attribute table with<br>
> db.in.ogr (which uses v.in.ogr), however, ogr refused it probably because of<br>
> the separator (pipe). Once I changed the separator to comma, it worked.<br>
<br>
</div></div>Why did you try to import raster category labels as a vector attribute<br>
table? The purpose of the RAT dump is to give you a chance to modify<br>
the dumped raster attribute table with your preferred text processing<br>
tools (a combination of cat, cut, tr, sed could help) in order to<br>
create input for either r.category or r.colors.<br></blockquote><div><br></div><div>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).</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Shouldn't r.in.gdal output a csv file with common separator like comma? I<br>
> understand that you don't always need to import it as attribute table, but<br>
> anyway comma seems more reasonable to me.<br>
<br>
</span>Comma is too commonly used in text entries.<br></blockquote><div> </div><div>True </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>From a GRASS perspective, a raster attribute table is a GDAL-specific<br>
thing that has nothing in common with a vector attribute table. There<br>
are no raster attribute tables in GRASS. r.in.gdal tries to extract<br>
information from GDAL raster attribute tables that can be used as<br>
category labels (see r.category) or color rules (see r.colors).<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Best,</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>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Thanks,<br>
><br>
> Anna<br>
><br>
>><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>
><br>
><br>
</div></div></blockquote></div><br></div></div>