[GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters

manuel.martin manuel.martin at orleans.inra.fr
Thu Feb 13 09:48:04 PST 2014


On 02/13/2014 04:31 PM, Moritz Lennert wrote:
> On 13/02/14 13:32, manuel.martin wrote:
>> I think geoTiffs do not handle categorical variables (can anyone
>> confirm?), neither the writeRAST6() function from spgrass6 (tested
>> yesterday), and that's why I looked for a full GRASS option (avoiding
>> using R to go from ArcGIS to GRASS). So it is true that I can import
>> categorical ArcGIS binary rasters into R, but then I'm stuck into R and
>> cannot move to GRASS...
>
> AFAIU, your "categorical" variables are just integers, or ? So no 
> problem to create a GeoTiff with them.
>
> This said, what exactly is the format the data is in ? Is it really a 
> binary with several values per pixel, or do you have one value per 
> pixel and then a lookup table linking these values to clc categories ? 
> ESRI's binary ArcInfo Grid format has a specific file (vat.adf for 
> Value Attribute Table) which contains this lookup table, with a value 
> and count field.
Hi Moritz and thank you for the valuable informations.

So I looked closer at the data and it is ESRI's binary ArcInfo Grid 
format with vat.adf files in the layer directory. These tables may be 
accessed outside of ArcGIS using for instance gdalinfo, and the R raster 
library seem to do it as well. However these tables seem to contain some 
binary codes so they cannot easily be read from automatic processing.

Unfortunately, CLC is not the only categorical layer I need to process, 
and manually linking the imported rasters values (within GRASS) to 
manually extracted codes (which again may be also strings) is not really 
an option. (or maybe is there a way to automate the process?)

So I am now thinking to convert these ArcGIS layers to another format 
using the gdal library (function gdal_translate for instance) for latter 
importing these converted layers to grass. I am thus facing two new 
questions.
1) which format is the best suited for carrying such categorical data on 
larger rasters among supported gdal formats and
2) will this format be supported by grass?

It seems to me that this story with multiple fields and categorical data 
might be related to the problem described here : 
http://r-forge.r-project.org/forum/forum.php?thread_id=1689&forum_id=962

Cheers,       Manuel

>
> In GRASS, the equivalent would be labels linked to category values. 
> But actually since the CLC categories are also integers, you could use 
> those as category values and put the text descriptions into the labels.
>
> The CLC data contains a legend which links values to categories:
>
> http://www.eea.europa.eu/data-and-maps/data/corine-land-cover-2006-raster#tab-additional-information 
>
>
> see  clc_legend.csv
>
> Using that file and a bit of text handling magic you can easily create 
> an input file for r.reclass to create a map with clc categories as 
> values and the textual descriptions as labels.
>
> Moritz
>
>
>
>>
>> Manuel
>>
>> On 02/13/2014 11:58 AM, Nuno Sá wrote:
>>> Out of the box:
>>>
>>> Import it in R and save it as a Tiff - use GRASS to open this tiff.
>>> Maybe it works ;P
>>>
>>>
>>> On 13 February 2014 10:50, Benjamin Ducke <benducke at fastmail.fm
>>> <mailto:benducke at fastmail.fm>> wrote:
>>>
>>>     Ouch. I am beginning to suspect that the ESRI "field"
>>>     concept for raster layers does not translate well
>>>     to GRASS/GDAL. Sorry for not being able to help.
>>>     Maybe someone else on this list has experience with
>>>     this type of data structure?
>>>
>>>     At least now we know that r.in.gdal starts counting
>>>     bands with "1"!
>>>
>>>     Ben
>>>
>>>     On 13/02/14 11:14, manuel.martin wrote:
>>>     > I had already tried this (with "2") ;-). No luck either. Reading
>>>     your
>>>     > email I tried with "0" (maybe would gdal detect only two bands 
>>> over
>>>     > three). It comes out that only "band=1" works....
>>>     >
>>>     >
>>>     > GRASS 7.0.svn (lambert93):~ > r.in.gdal --o
>>>     >
>>> input=/home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m
>>>     > band=0 output=testclc
>>>     > WARNING: Raster map <testclc> already exists and will be 
>>> overwritten
>>>     > WARNING: Datum <Not_specified_based_on_GRS_1980_ellipsoid> not
>>>     recognised
>>>     >          by GRASS and no parameters found
>>>     > Projection of input dataset and current location appear to match
>>>     > ERROR 5:
>>>     >
>>> /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m:
>>>     > GDALDataset::GetRasterBand(0) - Illegal band #
>>>     >
>>>     > ERROR: Selected band (0) does not exist
>>>     >
>>>     >
>>>     >
>>>     >
>>>     > On 02/13/2014 10:59 AM, Benjamin Ducke wrote:
>>>     >> Hmm, the manual page does not say so explicitely,
>>>     >> but maybe band numbering starts with "0"?
>>>     >> In that case your band 3 would have index number "2".
>>>     >>
>>>     >> Ben
>>>     >>
>>>     >> On 13/02/14 10:48, manuel.martin wrote:
>>>     >>> Hi Ben,
>>>     >>> Thanks for the reply. I tried with the band option but it
>>>     looks like
>>>     >>> gdal does not detect the multiple fields as multiple bands :
>>>     >>>
>>>     >>> GRASS 7.0.svn (lambert93):~ > r.in.gdal --o \
>>>     >>>
>>> input=/home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m
>>>     >>>
>>>     >>> \
>>>     >>>> band=3 output=testclc
>>>     >>> WARNING: Raster map <testclc> already exists and will be
>>>     overwritten
>>>     >>> WARNING: Datum <Not_specified_based_on_GRS_1980_ellipsoid> not
>>>     >>> recognised
>>>     >>>           by GRASS and no parameters found
>>>     >>> Projection of input dataset and current location appear to 
>>> match
>>>     >>> ERROR 5:
>>>     >>>
>>> /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m:
>>>     >>>
>>>     >>> GDALDataset::GetRasterBand(3) - Illegal band #
>>>     >>>
>>>     >>> ERROR: Selected band (3) does not exist
>>>     >>>
>>>     >>>
>>>     >>> Cheers, Manuel
>>>     >>>
>>>     >>> On 02/12/2014 08:25 PM, Benjamin Ducke wrote:
>>>     >>>> Hi Manuel,
>>>     >>>>
>>>     >>>> GRASS does not support multi-band rasters, so you'll have
>>>     >>>> to import each band as a separate raster map.
>>>     >>>>
>>>     >>>> r.in.gdal has the "band=" option to specify a band number
>>>     >>>> to import.
>>>     >>>>
>>>     >>>> Best,
>>>     >>>>
>>>     >>>> Ben
>>>     >>>>
>>>     >>>> On 12/02/14 17:05, manuel.martin wrote:
>>>     >>>>> Hi all,
>>>     >>>>>
>>>     >>>>> I tried to import an ArcGIS binary raster (corine land cover
>>>     for the
>>>     >>>>> French territory) with three fields on each pixels (VALUE,
>>>     COUNT and
>>>     >>>>> CODE_06) using the *r.in.gdal* command. The import works
>>>     just fine,
>>>     >>>>> except that in the resulting raster, in GRASS, I only get
>>>     one field,
>>>     >>>>> which seems to be the VALUE field (and not the CODE_06
>>>     field, which
>>>     >>>>> I am
>>>     >>>>> interested in, and which is a categorical field, although
>>>     coded with
>>>     >>>>> integers).
>>>     >>>>>
>>>     >>>>> Is there a way to produce a resulting raster with all the
>>>     fields of
>>>     >>>>> the
>>>     >>>>> initial ArcGIS layer, or alternatively to choose one unique
>>>     field?
>>>     >>>>> Also,
>>>     >>>>> is there a limitation on categorical fields. For instance,
>>>     what if
>>>     >>>>> instead of integer corine land cover codes I have literal
>>>     labels, i.e.
>>>     >>>>> levels of my categorical field coded with strings?
>>>     >>>>>
>>>     >>>>> Cheers, Manuel
>>>     >>>>>
>>>     >>>>> --
>>>     >>>>>
>>>     >>>>> ----------------0----0------
>>>     >>>>> INRA - InfoSol
>>>     >>>>> Centre de recherche d'Orléans
>>>     >>>>> 2163 Avenue de la Pomme de Pin
>>>     >>>>> CS 40001 ARDON
>>>     >>>>> 45075 ORLEANS Cedex 2
>>>     >>>>> tel : (33) (0)2 38 41 48 21
>>>     >>>>> fax : (33) (0)2 38 41 78 69
>>>     >>>>> http://www.gissol.fr
>>>     >>>>> ----0----0------------------
>>>     >>>>>
>>>     >>>>>
>>>     >>>>>
>>>     >>>>> _______________________________________________
>>>     >>>>> grass-user mailing list
>>>     >>>>> grass-user at lists.osgeo.org 
>>> <mailto:grass-user at lists.osgeo.org>
>>>     >>>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>     >>>>>
>>>     >>>>
>>>     >>>
>>>     >>
>>>     >>
>>>     >
>>>     >
>>>
>>>
>>>
>>>     --
>>>     Dr. Benjamin Ducke, M.A.
>>>     {*} Geospatial Consultant
>>>     {*} GIS Developer
>>>
>>>     benducke at fastmail.fm <mailto:benducke at fastmail.fm>
>>>     _______________________________________________
>>>     grass-user mailing list
>>>     grass-user at lists.osgeo.org <mailto:grass-user at lists.osgeo.org>
>>>     http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>>
>>>
>>>
>>> -- 
>>>
>>> Nuno César de Sá
>>> +351 91 961 90 37
>>>
>>>
>>>
>>> _______________________________________________
>>> grass-user mailing list
>>> grass-user at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>>
>> -- 
>>
>> ----------------0----0------
>> INRA - InfoSol
>> Centre de recherche d'Orléans
>> 2163 Avenue de la Pomme de Pin
>> CS 40001 ARDON
>> 45075 ORLEANS Cedex 2
>> tel : (33) (0)2 38 41 48 21
>> fax : (33) (0)2 38 41 78 69
>> http://www.gissol.fr
>> ----0----0------------------
>>
>>
>>
>> _______________________________________________
>> grass-user mailing list
>> grass-user at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
>
>


-- 

----------------0----0------
INRA - InfoSol
Centre de recherche d'Orléans
2163 Avenue de la Pomme de Pin
CS 40001 ARDON
45075 ORLEANS Cedex 2
tel : (33) (0)2 38 41 48 21
fax : (33) (0)2 38 41 78 69
http://www.gissol.fr
----0----0------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20140213/7f30e2e8/attachment-0001.html>


More information about the grass-user mailing list