r.out.gdal -t creates offset values in raster table for integer grids with values beginning with 1

[dnewcomb]

Exporting integer grids with values starting with 1 using r.out.gdal -t results in a raster attribute table with vertically shifted values in the last 3 columns. For example, if you have a raster with values of 1 to 5 with associated classes, you would expect a table that looks like this: OID Value MIN MAX CLASS 1 1 1 1 flat 2 2 2 2 summit 3 3 3 3 ridge 4 4 4 4 shoulder 5 5 5 5 spur

( Should the OID start with 0?, not sure )

In the current version of the software, the output table looks like this: OID Value MIN MAX CLASS 0 0 1 1 flat 1 1 2 2 summit 2 2 3 3 ridge 3 3 4 4 shoulder 4 4 5 5 spur 5 5 0 0 ERROR

See ​http://lists.osgeo.org/pipermail/grass-dev/2014-November/072021.html,

The issue seems to be in lines 73 - 78 in r.out.gdal/attr.c:

if (maptype == CELL_TYPE) {

for (i = 0; i < cats.ncats; i++) {

label = Rast_get_ith_c_cat(&cats, i, &CellMin, &CellMax);

GDALRATSetValueAsInt(hrat, i, 0, CellMin); GDALRATSetValueAsInt(hrat, i, 1, CellMax); GDALRATSetValueAsString(hrat, i, 2, label);

With this current ugly hack I've got has the values aligned with the classes again, but there is an extra OID 0 line with 0 or blank values for the fields at the beginning of the table.

if (maptype == CELL_TYPE) {

for (i = 0; i < cats.ncats-1; i++) {

label = Rast_get_ith_c_cat(&cats, i, &CellMin, &CellMax);

GDALRATSetValueAsInt(hrat, i+1, 0, CellMin); GDALRATSetValueAsInt(hrat, i+1, 1, CellMax); GDALRATSetValueAsString(hrat, i+1, 2, label);

Sample output to this hack would be: OID Value MIN MAX CLASS 0 0 0 0 1 1 1 1 flat 2 2 2 2 summit 3 3 3 3 ridge 4 4 4 4 shoulder 5 5 5 5 spur

This does not look quite right.

[dnewcomb]

Sorry, example tables in a more readable format

Expected Table:

OID Value MIN MAX CLASS
1 1 1 1 flat
2 2 2 2 summit
3 3 3 3 ridge
4 4 4 4 shoulder
5 5 5 5 spur

Current table:

OID Value MIN MAX CLASS
0 0 1 1 flat
1 1 2 2 summit
2 2 3 3 ridge
3 3 4 4 shoulder
4 4 5 5 spur
5 5 0 0 ERROR

Hacked table:

OID Value MIN MAX CLASS
0 0 0 0
1 1 1 1 flat
2 2 2 2 summit
3 3 3 3 ridge
4 4 4 4 shoulder
5 5 5 5 spur

[mmetz]

Replying to dnewcomb:

Exporting integer grids with values starting with 1 using r.out.gdal -t results in a raster attribute table with vertically shifted values in the last 3 columns.

In your example, the output is shifted in the first 2 columns. The last 3 columns are correct. What software did you use? The faulty fields OID and value are added by this software.

Here is an example using the NC sample dataset:

g.region -p rast=landclass96
r.out.gdal in=landclass96 out=landclass96.tif -t

This creates a GeoTIFF with an associated file landclass96.tif.aux.xml holding the attribute table. The fields and first entry of this attribute table are

min, max, label
1, 1, developed

all fine.

According to gdalinfo landclass96.tif, the fields and first entry of this attribute table are

min, max, label
1, 1, developed

all fine.

Exporting landclass96 in Erdas Imagine format (format=HFA), there is no associated .xml file.

According to gdalinfo landclass96.img, the fields and first entry of this attribute table are now

Red, Green, Blue, min, max, Class_Names
0, 0, 0, 0, 1, 1, developed

this is wrong, a bug in GDAL.

If GDAL itself is not able to correctly reproduce raster attribute tables created by itself, other software does not really have a chance to read raster attribute tables ay provided by GDAL. Further on, it seems that some other software further modifies the raster attribute table:

It seems that raster attribute tables created by GDAL are not widely supported, if yes, errors might be introduced.

Closing as wontfix because this is a problem of GDAL and GIS software other than GRASS.

[dnewcomb]

Software used to read the raster table was ArcGIS 10.2.2

[dnewcomb]

Replying to mmetz:

Replying to dnewcomb:

Exporting integer grids with values starting with 1 using r.out.gdal -t results in a raster attribute table with vertically shifted values in the last 3 columns.

In your example, the output is shifted in the first 2 columns. The last 3 columns are correct. What software did you use? The faulty fields OID and value are added by this software.

Here is an example using the NC sample dataset:

g.region -p rast=landclass96
r.out.gdal in=landclass96 out=landclass96.tif -t

This creates a GeoTIFF with an associated file landclass96.tif.aux.xml holding the attribute table. The fields and first entry of this attribute table are

min, max, label
1, 1, developed

all fine.

According to gdalinfo landclass96.tif, the fields and first entry of this attribute table are

min, max, label
1, 1, developed

all fine.

Exporting landclass96 in Erdas Imagine format (format=HFA), there is no associated .xml file.

According to gdalinfo landclass96.img, the fields and first entry of this attribute table are now

Red, Green, Blue, min, max, Class_Names
0, 0, 0, 0, 1, 1, developed

this is wrong, a bug in GDAL.

If GDAL itself is not able to correctly reproduce raster attribute tables created by itself, other software does not really have a chance to read raster attribute tables ay provided by GDAL. Further on, it seems that some other software further modifies the raster attribute table:

It seems that raster attribute tables created by GDAL are not widely supported, if yes, errors might be introduced.

Closing as wontfix because this is a problem of GDAL and GIS software other than GRASS.

I'll check with the gdal list. BTW,I'm running GRASS 70 with gdal 1.11.1, and when I run r.out.gdal -t, I get associated .xml files with both .tif and .img formats.