Bug report #19391
Grass algorithms give incorrect output if selecting an attribute column named "cat"
| Status: | Open | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Processing/GRASS | ||
| Affected QGIS version: | 3.2 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 27219 |
Description
When using the v.to.rast processing tool, with "Source of raster values" = "attr", the results are incorrect if the "Name of column for 'attr' parameter" is "cat". Instead of using the values in the "cat" column it gives each feature a unique value.
If the "Name of column for 'attr' parameter" is not "cat" (e.g. use the column named "category" in the example file), then the results are as expected. See the attached screenshots.
This problem occurs because "cat" is a sort of feature ID in grass, and when the file is imported the existing cat column is renamed to "cat_" and a new "cat" column is populated with unique values. I guess this means that the problem could be worked around by the algorithm telling GRASS to use "cat_" when you choose "cat". But it is a little more complicated - there might already be a cat_ column, in which case GRASS renames "cat_" to "cat__1" (if I remember correctly). So the algorithm would really need to fully reimplement the logic GRASS uses to rename the column.
An poor alternative might be something like a warning message in the gui or in the algorithm output if a column named "cat" is selected.
I presume this issue also affects other grass algorithms that take a column name as an input. IMO this is a pretty major usability problem - users should be able to safely use GRASS processing algorithms without understanding intricacies of GRASS. There's a possibility the user might not even notice that the algorithm did not do what they expected.
History
#1
Updated by Alister Hood over 6 years ago
Incidentally, the v.to.rast algorithm has an option "Name of column used as raster category labels", which only accepts columns with numeric data, when it should accept string data. This is an easy to fix error, but I don't think the option is actually useful. Currently the labels don't make it back into QGIS with the output layer (this could be achieved e.g. if the r.category.trim module could be run before bringing the outputs back from grass, but there is also a grass ticket about writing the labels to the .aux.xml file).
#2
Updated by Alister Hood over 6 years ago
I see in the GRASS wx gui that there is an option for the name of the Key column (under Gui Settings>Attributes>Create table).
So I guess it would be possible for processing algorithms to create a key column with a different name than "cat", in which case it might be slightly simpler to use that as a simpler workaround e.g. detect if an input layer has a Key column named "cat", and if so create a Key column named something else.