Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
On 02/18/2014 09:31 PM, Markus Metz wrote: On Tue, Feb 18, 2014 at 2:09 PM, manuel.martin manuel.mar...@orleans.inra.fr wrote: On 02/18/2014 01:56 PM, Markus Metz wrote: On Tue, Feb 18, 2014 at 1:14 PM, manuel.martin manuel.mar...@orleans.inra.fr wrote: On 02/18/2014 12:47 PM, Markus Metz wrote: On Tue, Feb 18, 2014 at 11:43 AM, manuel.martin manuel.mar...@orleans.inra.fr wrote: Hi, I just compiled grass r59073 and gave a try. I could not get the attributes imported along with the raster, but maybe am I missing something from the new revision of r.in.gdal (although from the code it looks that the import of values from the attribute table should be automatic?). Yes, r.in.gdal automatically imports whatever it finds as color tables or attribute labels. Markus, I just sent you the ESRI layer I am trying to import, in case you would like to try as well. GDAL does not see an attribute table in the data you sent to me, thus GRASS can not import any attributes. If there is really an attribute table, it is not recognized by GDAL. Then maybe this is a gdal problem : I'm saying this because through the command gdalinfo, it looks like gdal detects an attribute table (see below). Cheers GRASS 7.0.svn (lambert93):~/tmp gdalinfo /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4 Driver: AIG/Arc/Info Binary Grid Files: /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4 This file is missing in the archive you sent: /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4.aux.xml I am pretty sure that it contains the raster attribute table. Markus M Sorry about that, I just sent the landforms/test_lf4.aux.xml to you, but unfortunately it does not seem to contain the raster attribute table...: Right. Unfortunately I can not reproduce the gdalinfo output you sent previously, and as long as gdal does not see an attribute table, GRASS can not import the labels in the attribute table. I use gdal 1.10.1, if that helps. Markus M I am running GDAL 1.10.0, maybe that explains the difference. I will let you know when I will have 1.10.1 running if I still get the same gdalinfo results. Manuel GRASS 7.0.svn (lambert93):~/tmp more /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4.aux.xml PAMDataset SRSPROJCS[quot;RGF_1993_Lambert_93quot;,GEOGCS[quot;GCS_RGF_1993quot;,DATUM[quot;Reseau_Geodesique_Francais_1993quot;,SPHEROID[quot;GRS_1980quot;,63 78137.0,298.257222101]],PRIMEM[quot;Greenwichquot;,0.0],UNIT[quot;Degreequot;,0.0174532925199433]],PROJECTION[quot;Lambert_Conformal_Conic_2SPquot;],PARAM ETER[quot;False_Eastingquot;,70.0],PARAMETER[quot;False_Northingquot;,660.0],PARAMETER[quot;Central_Meridianquot;,3.0],PARAMETER[quot;Standard_Pa rallel_1quot;,44.0],PARAMETER[quot;Standard_Parallel_2quot;,49.0],PARAMETER[quot;Latitude_Of_Originquot;,46.5],UNIT[quot;Meterquot;,1.0]]/SRS PAMRasterBand band=1 Descriptiontest_lf4/Description Histograms HistItem HistMin1/HistMin HistMax6/HistMax BucketCount256/BucketCount IncludeOutOfRange1/IncludeOutOfRange Approximate0/Approximate HistCounts1313166|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|79933|0|0|0|0|0|0|0|0|0|0|0|0|0| 0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|110782|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0 |0|0|0|0|0|0|0|0|0|0|42435|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|69408|0|0|0|0|0|0|0|0|0|0|0|0|0|0 |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1341719/HistCounts /HistItem /Histograms /PAMRasterBand /PAMDataset /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/hdr.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/dblbnd.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/w001001.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/w001001x.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/sta.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/vat.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/log /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/prj.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/metadata.xml Size is 2504, 2089 Coordinate System is: PROJCS[unnamed, GEOGCS[Unknown datum based upon the GRS 1980 ellipsoid, DATUM
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
Hi, I just compiled grass r59073 and gave a try. I could not get the attributes imported along with the raster, but maybe am I missing something from the new revision of r.in.gdal (although from the code it looks that the import of values from the attribute table should be automatic?). Markus, I just sent you the ESRI layer I am trying to import, in case you would like to try as well. Thank you in advance Manuel On 02/17/2014 02:48 PM, Markus Metz wrote: On Fri, Feb 14, 2014 at 5:41 PM, manuel.martin manuel.mar...@orleans.inra.fr wrote: On 02/14/2014 05:08 PM, Markus Metz wrote: On Wed, Feb 12, 2014 at 5:05 PM, manuel.martin manuel.mar...@orleans.inra.fr 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). r.in.gdal will soon support import of category labels such as those stored in the CODE_06 field. You can then inspect the labels with r.category. GDAL supports reading and writing of raster attribute tables, so far only the color rules stored in a raster attribute table are imported, but I plan to add import of labels to r.in.gdal. Note that this applies only to GRASS 7. Markus M Good to hear that ;-). I will wait for the next release of r.in.gdal Done in r59073. Markus M (meanwhile I did import clc vector layers with v.in.ogr and later managed the category labels with v.to.rast). All the best, Manuel 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 -- 00-- 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 00-- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- 00-- 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 00-- -- 00-- 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 00-- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
On 02/18/2014 12:47 PM, Markus Metz wrote: On Tue, Feb 18, 2014 at 11:43 AM, manuel.martin manuel.mar...@orleans.inra.fr wrote: Hi, I just compiled grass r59073 and gave a try. I could not get the attributes imported along with the raster, but maybe am I missing something from the new revision of r.in.gdal (although from the code it looks that the import of values from the attribute table should be automatic?). Yes, r.in.gdal automatically imports whatever it finds as color tables or attribute labels. Markus, I just sent you the ESRI layer I am trying to import, in case you would like to try as well. GDAL does not see an attribute table in the data you sent to me, thus GRASS can not import any attributes. If there is really an attribute table, it is not recognized by GDAL. Then maybe this is a gdal problem : I'm saying this because through the command gdalinfo, it looks like gdal detects an attribute table (see below). Cheers GRASS 7.0.svn (lambert93):~/tmp gdalinfo /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4 Driver: AIG/Arc/Info Binary Grid Files: /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4 /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4.aux.xml /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/hdr.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/dblbnd.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/w001001.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/w001001x.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/sta.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/vat.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/log /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/prj.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/metadata.xml Size is 2504, 2089 Coordinate System is: PROJCS[unnamed, GEOGCS[Unknown datum based upon the GRS 1980 ellipsoid, DATUM[Not_specified_based_on_GRS_1980_ellipsoid, SPHEROID[GRS 1980,6378137,298.257222101, AUTHORITY[EPSG,7019]], AUTHORITY[EPSG,6019]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4019]], PROJECTION[Lambert_Conformal_Conic_2SP], PARAMETER[standard_parallel_1,44], PARAMETER[standard_parallel_2,49], PARAMETER[latitude_of_origin,46.5], PARAMETER[central_meridian,3], PARAMETER[false_easting,70], PARAMETER[false_northing,660], UNIT[METERS,1]] Origin = (198837.500,6808087.500) Pixel Size = (50.000,-50.000) Corner Coordinates: Upper Left ( 198837.500, 6808087.500) ( 3d45' 3.55W, 48d10'48.77N) Lower Left ( 198837.500, 6703637.500) ( 3d37'59.07W, 47d14'36.54N) Upper Right ( 324037.500, 6808087.500) ( 2d 4'11.49W, 48d15'52.06N) Lower Right ( 324037.500, 6703637.500) ( 1d58'52.06W, 47d19'34.69N) Center ( 261437.500, 6755862.500) ( 2d51'32.26W, 47d45'23.95N) Band 1 Block=256x16 Type=Byte, ColorInterp=Undefined Description = test_lf4 Min=1.000 Max=6.000 NoData Value=255 GDALRasterAttributeTable FieldDefn index=0 NameVALUE/Name Type0/Type Usage5/Usage /FieldDefn FieldDefn index=1 NameCOUNT/Name Type0/Type Usage1/Usage /FieldDefn FieldDefn index=2 NameCLASS_NAME/Name Type2/Type Usage0/Usage /FieldDefn Row index=0 F1/F F1313166/F FValleys/F /Row Row index=1 F2/F F79933/F FLower Slopes/F /Row Row index=2 F3/F F110782/F FGentle Slopes/F /Row Row index=3 F4/F F42435/F FSteep Slopes/F /Row Row index=4 F5/F F69408/F FUpper Slopes/F /Row Row index=5 F6/F F1341719/F FRidges/F /Row /GDALRasterAttributeTable Markus M Thank you in advance Manuel On 02/17/2014 02:48 PM, Markus Metz wrote: On Fri, Feb 14, 2014 at 5:41 PM, manuel.martin manuel.mar...@orleans.inra.fr wrote: On 02/14/2014 05:08 PM, Markus Metz wrote: On Wed, Feb 12, 2014 at 5:05 PM, manuel.martin manuel.mar...@orleans.inra.fr 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
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
On 02/18/2014 01:56 PM, Markus Metz wrote: On Tue, Feb 18, 2014 at 1:14 PM, manuel.martin manuel.mar...@orleans.inra.fr wrote: On 02/18/2014 12:47 PM, Markus Metz wrote: On Tue, Feb 18, 2014 at 11:43 AM, manuel.martin manuel.mar...@orleans.inra.fr wrote: Hi, I just compiled grass r59073 and gave a try. I could not get the attributes imported along with the raster, but maybe am I missing something from the new revision of r.in.gdal (although from the code it looks that the import of values from the attribute table should be automatic?). Yes, r.in.gdal automatically imports whatever it finds as color tables or attribute labels. Markus, I just sent you the ESRI layer I am trying to import, in case you would like to try as well. GDAL does not see an attribute table in the data you sent to me, thus GRASS can not import any attributes. If there is really an attribute table, it is not recognized by GDAL. Then maybe this is a gdal problem : I'm saying this because through the command gdalinfo, it looks like gdal detects an attribute table (see below). Cheers GRASS 7.0.svn (lambert93):~/tmp gdalinfo /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4 Driver: AIG/Arc/Info Binary Grid Files: /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4 This file is missing in the archive you sent: /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4.aux.xml I am pretty sure that it contains the raster attribute table. Markus M Sorry about that, I just sent the landforms/test_lf4.aux.xml to you, but unfortunately it does not seem to contain the raster attribute table...: GRASS 7.0.svn (lambert93):~/tmp more /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4.aux.xml PAMDataset SRSPROJCS[quot;RGF_1993_Lambert_93quot;,GEOGCS[quot;GCS_RGF_1993quot;,DATUM[quot;Reseau_Geodesique_Francais_1993quot;,SPHEROID[quot;GRS_1980quot;,63 78137.0,298.257222101]],PRIMEM[quot;Greenwichquot;,0.0],UNIT[quot;Degreequot;,0.0174532925199433]],PROJECTION[quot;Lambert_Conformal_Conic_2SPquot;],PARAM ETER[quot;False_Eastingquot;,70.0],PARAMETER[quot;False_Northingquot;,660.0],PARAMETER[quot;Central_Meridianquot;,3.0],PARAMETER[quot;Standard_Pa rallel_1quot;,44.0],PARAMETER[quot;Standard_Parallel_2quot;,49.0],PARAMETER[quot;Latitude_Of_Originquot;,46.5],UNIT[quot;Meterquot;,1.0]]/SRS PAMRasterBand band=1 Descriptiontest_lf4/Description Histograms HistItem HistMin1/HistMin HistMax6/HistMax BucketCount256/BucketCount IncludeOutOfRange1/IncludeOutOfRange Approximate0/Approximate HistCounts1313166|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|79933|0|0|0|0|0|0|0|0|0|0|0|0|0| 0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|110782|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0 |0|0|0|0|0|0|0|0|0|0|42435|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|69408|0|0|0|0|0|0|0|0|0|0|0|0|0|0 |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1341719/HistCounts /HistItem /Histograms /PAMRasterBand /PAMDataset /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/hdr.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/dblbnd.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/w001001.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/w001001x.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/sta.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/vat.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/log /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/prj.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/metadata.xml Size is 2504, 2089 Coordinate System is: PROJCS[unnamed, GEOGCS[Unknown datum based upon the GRS 1980 ellipsoid, DATUM[Not_specified_based_on_GRS_1980_ellipsoid, SPHEROID[GRS 1980,6378137,298.257222101, AUTHORITY[EPSG,7019]], AUTHORITY[EPSG,6019]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4019]], PROJECTION[Lambert_Conformal_Conic_2SP], PARAMETER[standard_parallel_1,44], PARAMETER[standard_parallel_2,49], PARAMETER[latitude_of_origin,46.5], PARAMETER[central_meridian,3], PARAMETER[false_easting,70
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
On 02/14/2014 05:08 PM, Markus Metz wrote: On Wed, Feb 12, 2014 at 5:05 PM, manuel.martin manuel.mar...@orleans.inra.fr 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). r.in.gdal will soon support import of category labels such as those stored in the CODE_06 field. You can then inspect the labels with r.category. GDAL supports reading and writing of raster attribute tables, so far only the color rules stored in a raster attribute table are imported, but I plan to add import of labels to r.in.gdal. Note that this applies only to GRASS 7. Markus M Good to hear that ;-). I will wait for the next release of r.in.gdal (meanwhile I did import clc vector layers with v.in.ogr and later managed the category labels with v.to.rast). All the best, Manuel 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 -- 00-- 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 00-- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- 00-- 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 00-- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
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 -- 00-- 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 00-- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- 00-- 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 00-- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
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 -- 00-- 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 00-- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- 00-- 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 00-- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
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...
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 bendu...@fastmail.fm
mailto:bendu...@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
--
00--
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
00--
___
grass-user mailing list
grass-user@lists.osgeo.org mailto:grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
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=1689forum_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 bendu...@fastmail.fm mailto:bendu...@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
Re: [GRASS-user] Strange r.slope.aspect output of Aster dem : slope calculations
Thanks for the replies, we actually derived SRTM DEMs and yes this thime without artifacts. Cheers On 01/08/2014 09:16 PM, Markus Metz wrote: On Fri, Dec 20, 2013 at 4:54 PM, manuel.martin manuel.mar...@orleans.inra.fr wrote: Hi all, I just computed the slope using r.slope.aspect on the Aster data over the full French territory, and as a result got large artefact stripes on a south west-north east axe? When could it come from (inadequate re-projection, the slope routine or the aster data)? The stripped result : https://www.dropbox.com/s/fcxaei1be9wsmka/slopeFranceSmall.png https://www.dropbox.com/s/b52k5co46ujmpt7/slopeFrance.jpg ASTER data are not really suitable to derive a DEM, your example is another demonstration that an ASTER-derived DEM contains artefacts. SRTM DEMs are without these artefacts. Markus M -- 00-- 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 00-- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
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 -- 00-- 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 00-- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Strange r.slope.aspect output of Aster dem : slope calculations
Hi all, I just computed the slope using r.slope.aspect on the Aster data over the full French territory, and as a result got large artefact stripes on a south west-north east axe? When could it come from (inadequate re-projection, the slope routine or the aster data)? The stripped result : https://www.dropbox.com/s/fcxaei1be9wsmka/slopeFranceSmall.png https://www.dropbox.com/s/b52k5co46ujmpt7/slopeFrance.jpg Thank you in advance,Manuel -- 00-- 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 00-- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] empty values from v.what.vect
Dear all, i am using the d.what.vect function in order to update the smu field of the attribute table of a vector map named rmqs_to_million, from the values of the field SMU of the third layer (attribute table) of a vector map called million. The type of both the smu and the SMU fieds is integer here is the piece of code : v.what.vect vector=rmqs_to_million column=smu qlayer=3 qvect=million qcolumn=SMU dmax=1000 The output looks ok : GRASS 6.4.3RC3 (lambertWgs84):~/dev v.what.vect vector=rmqs_to_million column=smu qlayer=3 \ qvect=million qcolumn=SMU dmax=1000 100% 100% 100% 2193 categories with more than 1 feature in vector map rmqs_to_million 2193 categories read from the map 2193 categories exist in the table 2193 categories read from the map exist in the table 2193 records updated v.distance complete. But when I look at the rmqs_to_million attribute table, the smu field is empty. - This does not depends on the value used for dmax - This does not depends on the field (assuming it of of type integer) I use from the 3rd layer of the million map - This does not depends on the qlayer which the field used for updating belongs to I tried to do the same with a vector map having only one attribute table (layer), and this time, I was successful. Thus I wonder if there is not a problem with the d.what.vect function when vector maps with multiple layers are used for updating a field of the attribute table of another map? I had this problem with both grass6.4 and 7 under Ubuntu 12.04. Cheers, Manuel -- 00-- 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 00-- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] d.what.vect on selected polygons
Hi, is it possible to 1) selected some objects of a vector layer and 2) to run the d.what.vect in order to update a column of the attribute table of another vector layer, from only the previously selected objects of the first layer? Thank you in advance, Manuel -- 00-- 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 00-- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
