Preserve GRASS raster labels

[qgib]

Author Name: Paolo Cavallini (@pcav) Original Redmine Issue: 5742

Redmine category:processing/grass

---

• GRASS raster can have labels (very convenient, e.g. r.param.scale saves feature names along with categories)
• when saving to TIFF, these are stripped
• as a consequence, the flow DTM>Features raster>Feature vector strips the categories, and data are lost.

Of course we can Use raster values as categories, but keeping the labels would be much better. One way would be to pipe directly the two GRASS commands, without exporting in between, but this is not implemented yet.

Notes from Etienne Tourigny: labels could be added as GTIFF metadata, which GDAL supports but I don't know how/if this could be done in GRASS

If the export is using r.out.gdal there must be a way to put/get metadata in a gtiff?

from r.out.gdal:

metaopt=string[,string,...]
Metadata key(s) and value(s) to include
In the form of "META-TAG=VALUE", separate multiple entries with a comma. Not supported by all output format drivers.

Notes from Benjamin Ducke:

Theoretically, it wouldn't be very hard to read the labels from the mapset in which SEXTANTE is storing the (temporary) GRASS datasets; they are saved as plain ASCII there.

However, the host GIS for SEXTANTE must then somehow deal with this additional data in some useful way (e.g. via a virtual raster attribute table).

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

From Markus Metz, GRASS mailing list:

An alternative would be to make use of the GDAL raster attribute table in both GRASS and QGIS, with the benefit that reading labels for other raster maps imported with GDAL would also be supported.

IIUC, QGIS is currently using GDALGetRasterCategoryNames() which has very limited functionality and supports only integer maps. In a GDAL raster attribute table, as with GRASS-internal categories, floating point values and data ranges are supported, e.g.

min=358.5, max=359.5, name=359 degrees ccw from east

A GDAL raster attribute table would also solve the problem of importing/exporting color rules for floating point data types.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Paolo Cavallini wrote:

From Markus Metz, GRASS mailing list:

An alternative would be to make use of the GDAL raster attribute table in both GRASS and QGIS, with the benefit that reading labels for other raster maps imported with GDAL would also be supported.

IIUC, QGIS is currently using GDALGetRasterCategoryNames() which has very limited functionality and supports only integer maps. In a GDAL raster attribute table, as with GRASS-internal categories, floating point values and data ranges are supported, e.g.

min=358.5, max=359.5, name=359 degrees ccw from east

A GDAL raster attribute table would also solve the problem of importing/exporting color rules for floating point data types.

may be this has been implemented n qgis?

see

8bdaf42dbaec240151eacaa9a28e02f49a53fd66

---

• status_id was changed from Open to Feedback

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

I think more work has to be done on the Processing side, to add these options to the export command.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• category_id removed 59
• project_id was changed from 78 to 17

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• category_id was configured as Processing/GRASS

[qgib]

Author Name: Médéric RIBREUX (Médéric RIBREUX)

---

Hello,

after some work on r.category implementation, I've found that in GRASS7 (and only GRASS7), you can use the '-t' parameter for r.out.gdal (command that is internally used by Processing GRASS) to export raster labels. Labels are exported in GDAL Raster Attribute Table (RAT). The RAT takes the form of an xml file named after the raster filename concatenated with '.aux.xml'.

For the moment, QGIS raster provider can't use the values that are in the RAT. The only thing that QGIS uses for rasters are GDAL categories (and only for integer rasters). But we can make Processing GRASS algorithms to export raster labels just by adding the '-t' parameter to every r.out.gdal output (for the default case).

For importing labels and keeping labels, this is a little bit more complex: it seems that only r.in.gdal (which duplicates the raster) can import labels into GRASS7 (but the import is complete from the RAT and very well integrated into GRASS database). Processing uses r.external for raster imports (because it just makes a link to the raster file, there is no data duplication). We have different choices (as far as I can see):

• replace r.external to r.in.gdal by default (everywhere) with the drawback to always duplicate data (but some of GRASS7 algorithms need to use r.in.gdal instead of r.External).
• use only r.in.gdal for some algorithms (r.category, r.reclass): implementation can be made with the 'ext' mechanism so no need to change main Grass7Algorithm.py.
• add an (virtual) option as a checkbox in every algorithm dialog box which could be entitled like: 'preserve raster labels (warning: duplicates raster data in temporary GRASS database)'. If the user checks the box, use r.in.gdal instead of r.external (just some lines to add in Grass7Algorithm.py and for the GUI). It would be like the region extent or the cell size options.
• add a new general option for GRASS7 for 'preserve raster labels' which define if user want to import labels by default.
• both of the two last points.
• do nothing and open a GRASS7 ticket to add label preservation for r.external !

What do you think about this ? Feel free to add any other choice or just your opinion...

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

IMHO the last option is the best one.

[qgib]

Author Name: Médéric RIBREUX (Médéric RIBREUX)

---

Ok, I have opened "a ticket into GRASS bugtracker for r.external":https://trac.osgeo.org/grass/ticket/2963...

On QGIS side, we need to add '-t' option for r.out.gdal command in Grass7Algorithm.py. I'll do it once "my global r.* Pull-Request":https://github.com/qgis/QGIS/pull/2865 will be merged.

---

• status_id was changed from Feedback to Open

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• easy_fix was configured as 0

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

Still true in Q3

---

• assigned_to_id removed Victor Olaya
• description was changed from * GRASS raster can have labels (very convenient, e.g. r.param.scale saves feature names along with categories)
• when saving to TIFF, these are stripped
• as a consequence, the flow DTM>Features raster>Feature vector strips the categories, and data are lost.

Of course we can Use raster values as categories, but keeping the labels would be much better. One way would be to pipe directly the two GRASS commands, without exporting in between, but this is not implemented yet.

Notes from Etienne Tourigny: labels could be added as GTIFF metadata, which GDAL supports but I don't know how/if this could be done in GRASS

If the export is using r.out.gdal there must be a way to put/get metadata in a gtiff?

from r.out.gdal:

metaopt=string[,string,...]
Metadata key(s) and value(s) to include
In the form of "META-TAG=VALUE", separate multiple entries with a comma. Not supported by all output format drivers.

Notes from Benjamin Ducke:

Theoretically, it wouldn't be very hard to read the labels from the mapset in which SEXTANTE is storing the (temporary) GRASS datasets; they are saved as plain ASCII there.

However, the host GIS for SEXTANTE must then somehow deal with this additional data in some useful way (e.g. via a virtual raster attribute table). to * GRASS raster can have labels (very convenient, e.g. r.param.scale saves feature names along with categories)

• when saving to TIFF, these are stripped
• as a consequence, the flow DTM>Features raster>Feature vector strips the categories, and data are lost.

Of course we can Use raster values as categories, but keeping the labels would be much better. One way would be to pipe directly the two GRASS commands, without exporting in between, but this is not implemented yet.

Notes from Etienne Tourigny: labels could be added as GTIFF metadata, which GDAL supports but I don't know how/if this could be done in GRASS

If the export is using r.out.gdal there must be a way to put/get metadata in a gtiff?

from r.out.gdal:

metaopt=string[,string,...]
Metadata key(s) and value(s) to include
In the form of "META-TAG=VALUE", separate multiple entries with a comma. Not supported by all output format drivers.

Notes from Benjamin Ducke:

Theoretically, it wouldn't be very hard to read the labels from the mapset in which SEXTANTE is storing the (temporary) GRASS datasets; they are saved as plain ASCII there.

However, the host GIS for SEXTANTE must then somehow deal with this additional data in some useful way (e.g. via a virtual raster attribute table).