[GRASS-dev] [GRASS GIS] #2501: r.out.gdal -t creates offset values in raster table for integer grids with values beginning with 1

GRASS GIS GRASS GIS developer
,
1

#2501: r.out.gdal -t creates offset values in raster table for integer grids with
values beginning with 1
--------------------------------------------------+-------------------------
Reporter: dnewcomb | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Keywords: r.out.gdal table attribute alignment | Platform: Linux
      Cpu: x86-64 |
--------------------------------------------------+-------------------------
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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2501&gt;
GRASS GIS <http://grass.osgeo.org>

2

#2501: r.out.gdal -t creates offset values in raster table for integer grids with
values beginning with 1
--------------------------------------------------+-------------------------
Reporter: dnewcomb | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Keywords: r.out.gdal table attribute alignment | Platform: Linux
      Cpu: x86-64 |
--------------------------------------------------+-------------------------

Comment(by dnewcomb):

Sorry, example tables in a more readable format[[BR]]

Expected Table:[[BR]]

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

Current table:[[BR]][[BR]]

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

Hacked table:[[BR]][[BR]]

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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2501#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

3

#2501: r.out.gdal -t creates offset values in raster table for integer grids with
values beginning with 1
-----------------------+----------------------------------------------------
  Reporter: dnewcomb | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Resolution: wontfix | Keywords: r.out.gdal table attribute alignment
  Platform: Linux | Cpu: x86-64
-----------------------+----------------------------------------------------
Changes (by mmetz):

  * status: new => closed
  * resolution: => wontfix

Comment:

Replying to [ticket:2501 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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2501#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

4

#2501: r.out.gdal -t creates offset values in raster table for integer grids with
values beginning with 1
-----------------------+----------------------------------------------------
  Reporter: dnewcomb | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Resolution: wontfix | Keywords: r.out.gdal table attribute alignment
  Platform: Linux | Cpu: x86-64
-----------------------+----------------------------------------------------

Comment(by dnewcomb):

Software used to read the raster table was ArcGIS 10.2.2

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2501#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

5

#2501: r.out.gdal -t creates offset values in raster table for integer grids with
values beginning with 1
-----------------------+----------------------------------------------------
  Reporter: dnewcomb | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Resolution: wontfix | Keywords: r.out.gdal table attribute alignment
  Platform: Linux | Cpu: x86-64
-----------------------+----------------------------------------------------

Comment(by dnewcomb):

Replying to [comment:2 mmetz]:
> Replying to [ticket:2501 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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2501#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>