Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
On Mon, Feb 24, 2014 at 9:50 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Mon, Feb 24, 2014 at 8:15 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Sat, Feb 22, 2014 at 8:11 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Feb 21, 2014 at 5:45 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Feb 21, 2014 at 5:39 PM, Vaclav Petras wenzesl...@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). According to this link, it would be easy to implement the RAT dump as CSV in r.in.gdal. Done in trunk r62160,7. Now it seems that the best will be to [...] generate rules for colors or labels. This is done by r.in.gdal automatically since r59073, as long as GDAL reports field usages that are suitable to generate rules for colors or labels. Markus M The user would need to define these rules if GDAL can not figure them out from the intended usage of the fields. In order to do so, the user must be able to inspect the attribute table, preferably not in XML format. CSV seems to me the logical choice. 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 would require two steps: first dump all the RATs in human-readable format, such that the user can specify any rules. Note that rules including any scale factor would need to be specified for each band in the GDAL raster dataset. The number of parameters would thus explode. Markus M 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 mlenn...@club.worldonline.be wrote: On 21/02/14 17:12, Markus Metz wrote: On Fri, Feb 21, 2014 at 2:00 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 21/02/14 11:30, Markus Metz wrote: On Fri, Feb 21, 2014 at 9:35 AM, Moritz Lennert mlenn...@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 ?
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
On Sat, Feb 22, 2014 at 8:11 AM, Markus Metz markus.metz.gisw...@gmail.comwrote: On Fri, Feb 21, 2014 at 5:45 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Feb 21, 2014 at 5:39 PM, Vaclav Petras wenzesl...@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 mlenn...@club.worldonline.be wrote: On 21/02/14 17:12, Markus Metz wrote: On Fri, Feb 21, 2014 at 2:00 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 21/02/14 11:30, Markus Metz wrote: On Fri, Feb 21, 2014 at 9:35 AM, Moritz Lennert mlenn...@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ 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 Fri, Feb 21, 2014 at 5:45 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Feb 21, 2014 at 5:39 PM, Vaclav Petras wenzesl...@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. 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 mlenn...@club.worldonline.be wrote: On 21/02/14 17:12, Markus Metz wrote: On Fri, Feb 21, 2014 at 2:00 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 21/02/14 11:30, Markus Metz wrote: On Fri, Feb 21, 2014 at 9:35 AM, Moritz Lennert mlenn...@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ 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 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) ? Moritz ___ 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 Fri, Feb 21, 2014 at 9:35 AM, Moritz Lennert mlenn...@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 ___ 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 21/02/14 11:30, Markus Metz wrote: On Fri, Feb 21, 2014 at 9:35 AM, Moritz Lennert mlenn...@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 ? Moritz ___ 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 Fri, Feb 21, 2014 at 2:00 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 21/02/14 11:30, Markus Metz wrote: On Fri, Feb 21, 2014 at 9:35 AM, Moritz Lennert mlenn...@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. For importing categories, field usages GFU_Name + GFU_MinMax or GFU_Name + GFU_Min + GFU_Max is needed. For importing color rules, GFU_Min + GFU_Max + GFU_RedMin + GFU_RedMax + GFU_GreenMin + GFU_GreenMax + GFU_BlueMin + GFU_BlueMax (8 fields) are needed, or GFU_MinMax + GFU_Red + GFU_Green + GFU_Blue (4 fields). Markus M ___ 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 21/02/14 17:12, Markus Metz wrote: On Fri, Feb 21, 2014 at 2:00 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 21/02/14 11:30, Markus Metz wrote: On Fri, Feb 21, 2014 at 9:35 AM, Moritz Lennert mlenn...@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
Unfortunately, I have data where GDAL does not identify the columns. One is the only string there, and the other three are the red, green, blue (in the range 0-1). 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. 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 mlenn...@club.worldonline.be wrote: On 21/02/14 17:12, Markus Metz wrote: On Fri, Feb 21, 2014 at 2:00 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 21/02/14 11:30, Markus Metz wrote: On Fri, Feb 21, 2014 at 9:35 AM, Moritz Lennert mlenn...@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ 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 Fri, Feb 21, 2014 at 5:39 PM, Vaclav Petras wenzesl...@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. 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 mlenn...@club.worldonline.be wrote: On 21/02/14 17:12, Markus Metz wrote: On Fri, Feb 21, 2014 at 2:00 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 21/02/14 11:30, Markus Metz wrote: On Fri, Feb 21, 2014 at 9:35 AM, Moritz Lennert mlenn...@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ 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 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,
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
On Thu, Feb 20, 2014 at 9:32 AM, manuel.martin manuel.mar...@orleans.inra.fr wrote: 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. 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. Alternatively, you can get the original corine land cover as raster (the vector version is full of errors and tricky to clean up) and the legend and import these. Markus M 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
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 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. 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 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 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 /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
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 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 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]],
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
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-- ___ 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 13/02/14 18:48, manuel.martin wrote: 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. If you can export the information with gdalinfo, you should be able to treat it automatically to create the necessary input files for r.reclass or r.category. I don't have any sample files here, so I can't test for myself. If you want to send me a sample file, I can try to see what is possible. BTW: I just added to the GRASS wiki page on Corine Land Cover [2] the input necessary for r.reclass to transform a raster with generic 0-255 categories to a raster with the CLC codes as categories and the description of each class as a label. 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?) If you have access to ArcGIS, you can apparently export the raster data table [3]. You should then be able to input that table into r.reclass or r.category depending on your needs and on the data. 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? GRASS raster format does not store attributes for rasters (or maximum one in the form of labels). So if you want to store the information contained in several fields in an attribute table, you have to create as many raster maps as there are attributes (assuming that these attributes are numerical). So I think you best bet is to try to get the attribute data in text form and then extract from that the inputs to r.reclass/r.category. Moritz [1] http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/Raster_dataset_attribute_tables/009t000900/ [2] http://grasswiki.osgeo.org/wiki/CORINE_Land_Cover#Legend ___ 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 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 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 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/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
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
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
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
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
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
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
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 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
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@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@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 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. 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 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,
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
[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
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
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
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
