[Bug] v.colors cannot properly copy color table

[cmbarton]

Describe the bug
The 'raster=' argument does not seem to work correctly. It colors the vector map but not at all like the raster map from which it is copied. Thereafter, the color cannot be set in d.vect unless the color table is removed using v.colors.

To Reproduce
Using the NC dataset, make a raster map from TOTAL_POP from the SW Wake census map, and give it a nice histogram stretched blue color ramp (It does not matter what colors are used, the results are similarly random)

v.to.rast input=censusblk_swwake@PERMANENT output=censusblk_swwake_vect@spatialtech2021 use=attr attribute_column=TOTAL_POP --o
r.colors -e map=censusblk_swwake_vect@spatialtech2021 color=blues

Try to copy this raster color table to the original vector map

v.colors map=censusblk_swwake@PERMANENT use=attr column=TOTAL_POP raster=censusblk_swwake_vect@spatialtech2021

Expected behavior
The color table in the vector map should be the same as in the raster map but it is not

The incorrect colors are also written to a selected RGB column if the rgb_column= argument is used

Screenshots
Raster version of census blocks

Vector of census blocks after running v.color to copy the raster color table

System description (please complete the following information):

• Operating System: Mac OS 11
• GRASS GIS version 7.8.6 dev

Additional context
Possibly the problem is that a raster color table has colors assigned to raster values (TOTAL_POP here). But a vector color table has colors assigned to the CAT value, not the attribute value that it is supposed to match. I think that in this case, v.colors is assigning raster colors to whatever vector objects have CAT values that match raster values (TOTAL_POP here) instead of objects that have matching attribute values, even though the v.color arguments use=attr column=TOTAL_POP are specified.

Also note that v.colors is lacking histogram equalization.

[cmbarton]

Unlike importing a raster color table, if you export a raster color table to a rules file (r.colors.out) and import the rules file into v.colors, this does create a good color table that matches the raster.

[cmbarton]

Further color weirdness. If rgb_column= is used, v.colors will not create a color table. Now I see that it is sort of implied in the docs for rgb_column= , but not stated. Seems like writing a color table should at least be a user option, regardless of whether the info is written to a column or not.

When a selection criteria is used in in d.vect (where=), area boundaries become invisible because they take on the color of the fill. Selecting transparent for the boundary color does make them transparent.

[wenzeslaus]

...area boundaries become invisible because they take on the color of the fill...

I have a similar issue. See discussion in #1146.

[HuidaeCho]

@cmbarton column= is only used when either color= or rules= is specified. It's not meant to be used with raster=, so your last command is the same as

v.colors map=censusblk_swwake@PERMANENT raster=censusblk_swwake_vect

and, yes, you're right. You're doing TOTAL_POP to cat color transfer.

When you use r.colors.out, rules=, and column=TOTAL_POP, you do TOTAL_POP to TOTAL_POP.

It would be great if we could do

r.colors.out censusblk_swwake_vect rules=- | v.colors map=censusblk_swwake@PERMANENT use=attr column=TOTAL_POP rules=-

but reading rules from stdin is not implemented yet.

[HuidaeCho]

Check #1389.

v.to.rast input=censusblk_swwake use=attr attribute_column=TOTAL_POP output=censusblk_swwake_total_pop
r.colors -e map=censusblk_swwake_total_pop color=blues
r.colors.out map=censusblk_swwake_total_pop rules=- | v.colors map=censusblk_swwake use=attr column=TOTAL_POP rules=-

[HuidaeCho]

@cmbarton Please check #1392.

[HuidaeCho]

@cmbarton The original command (raster= with use=attr and column=) implemented in #1393. Please test it.

[cmbarton]

I will do so. Thanks much.

[cmbarton]

I approved the PR and it works great. Can this be backported to 7.8? Then we can close this issue. Histogram is still open.

[HuidaeCho]

I approved the PR and it works great. Can this be backported to 7.8? Then we can close this issue. Histogram is still open.

Are you talking about both #1393 and #1389, or just #1393?

[cmbarton]

#1393

Sorry if there was confusion. That was the main issue reported here.