[GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
Vaclav Petras
wenzeslaus at gmail.com
Mon Feb 24 11:15:55 PST 2014
On Sat, Feb 22, 2014 at 8:11 AM, Markus Metz
<markus.metz.giswork at gmail.com>wrote:
> On Fri, Feb 21, 2014 at 5:45 PM, Markus Metz
> <markus.metz.giswork at gmail.com> wrote:
> > On Fri, Feb 21, 2014 at 5:39 PM, Vaclav Petras <wenzeslaus at gmail.com>
> wrote:
> >> Unfortunately, I have data where GDAL does not identify the columns.
> >
> > Does GDAL find a raster attribute table?
> >
> >> One is
> >> the only string there, and the other three are the red, green, blue (in
> the
> >> range 0-1).
> >
> > ... which would need to be transformed to the range 0,255.
> >
> > Here it seems easier to edit the attribute table outside GRASS, then
> > use r.category and r.colors.
> >
> >> For me it is clear what column I would like to transform to
> >> label and to color rules but I'm not sure if GDAL has even a chance to
> >> determine it somehow. So, some options to set this would be great.
> >>
> >> I can share the data, they are from a public source.
>
> For these data, GDAL can not determine the usage of the "RED",
> "GREEN", and "BLUE" fields, also not for the "FBFM13" field. IMHO, the
> best we could do is add an option to dump the raster attribute table
> in text format and let the user modify it such that it can be used
> with r.category and/or r.colors. The GDAL function to dump a raster
> attribute table dumps it in xml, and the documentation says itself
> that this is barely readable, so we would need our own dump function.
>
> Hi Markus,
I was actually dealing with this just before you started committing the
attribute table related things. Since I don't know GDAL, I asked and it
seems that the right thing to do is to use API [1] to generate whatever is
appropriate for you (so exactly what you say). Now it seems that the best
will be to forgot about CSV or XML and generate rules for colors or labels.
This could be done in separate (C/Python) module based on [1] but having
this as a part of r.in.gdal would be advantageous (number of parameters
would be higher but you would import everything in one step).
It is possible that I will write Python module to turn attribute table into
label and color rules in next weeks but I cannot promise.
Vaclav
[1]
http://gis.stackexchange.com/questions/84700/how-to-show-only-raster-attribute-table-using-gdal/
Markus M
>
> >
> > I would be interested.
> >
> > Markus M
> >
> >>
> >> But anyway, connection to color tables and labels is great, colors and
> >> labels solves at least significant part of the cases where raster
> attribute
> >> tables are used.
> >>
> >> Vaclav
> >>
> >>
> >> On Fri, Feb 21, 2014 at 11:26 AM, Moritz Lennert
> >> <mlennert at club.worldonline.be> wrote:
> >>>
> >>> On 21/02/14 17:12, Markus Metz wrote:
> >>>>
> >>>> On Fri, Feb 21, 2014 at 2:00 PM, Moritz Lennert
> >>>> <mlennert at club.worldonline.be> wrote:
> >>>>>
> >>>>> On 21/02/14 11:30, Markus Metz wrote:
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Feb 21, 2014 at 9:35 AM, Moritz Lennert
> >>>>>> <mlennert at club.worldonline.be> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On 20/02/14 22:14, Markus Metz wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I would not replace a working gdal version with a probably not
> >>>>>>>> working
> >>>>>>>> gdal version. Your gdalinfo reported a raster attribute table, not
> >>>>>>>> mine. You could double-check again if your gdalinfo still finds a
> >>>>>>>> raster attribute table, then import with r.in.gdal.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Out of curiosity: if a table contains several columns which one(s)
> >>>>>>> is/are
> >>>>>>> imported and in what form do they appear in GRASS (I don't have a
> file
> >>>>>>> here
> >>>>>>> to test myself) ?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Each column has a dedicated usage. For "name" usage, the column is
> >>>>>> treated as category labels. For any of the color usages, the column
> is
> >>>>>> treated as corresponding red, green, or blue color. See also the
> gdal
> >>>>>> documentation [0]. Currently, r.out.gdal exports category labels or
> >>>>>> color rules to a raster attribute table with the new -t flag, and
> >>>>>> r.in.gdal automatically imports any information it finds.
> >>>>>>
> >>>>>> Markus M
> >>>>>>
> >>>>>> [0]
> http://www.gdal.org/gdal_8h.html#a27bf786b965d5227da1acc2a4cab69a1
> >>>>>
> >>>>>
> >>>>>
> >>>>> So, IIUC you get the GFU_Name and the color information, but if the
> >>>>> table
> >>>>> contains several fields (which I guess will be of type GFU_Generic)
> >>>>> these
> >>>>> are ignored ?
> >>>>
> >>>>
> >>>> GFU_Generic usage is ignored because it is unknown what this could be
> >>>> good for.
> >>>
> >>>
> >>> VAT tables allow as many fields as the user wants, not only a class
> name.
> >>> But I don't know (and can't tell from ESRI's documentation) whether
> these
> >>> additional fields will all be considered GFU_Names or GFU_Generics)
> and as I
> >>> don't have relevant data here (and data that colleagues created for me
> >>> causes an error with gdal...) I can't test this at this stage.
> >>>
> >>> My question was: if a raster has several fields as in the attribute
> table,
> >>> would it be possible to chose the field to use as labels in GRASS ?
> >>>
> >>> Moritz
> >>>
> >>>
> >>> _______________________________________________
> >>> 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-user/attachments/20140224/180e9feb/attachment-0001.html>
More information about the grass-user
mailing list