Opened 9 years ago

Closed 9 years ago

#1426 closed defect (fixed)

v.colors resetting vector display

Reported by: cmbarton Owned by: grass-dev@…
Priority: normal Milestone: 7.0.0
Component: wxGUI Version: svn-trunk
Keywords: v.colors, colorrules Cc:
CPU: Unspecified Platform: Unspecified

Description

v.colors seems to reset all vector settings to default. If you have set the symbol type and size, for example, running v.colors resets it to a 5 point "x".

Change History (15)

comment:1 Changed 9 years ago by martinl

I don't fully understand, eg.

d.vect bridges size=10 icon=basic/box

OK

v.colors bridges color=ryg
d.vect bridges size=10 icon=basic/box

OK

comment:2 Changed 9 years ago by cmbarton

d.vect bridges size=10 icon=basic/box

OK

v.colors bridges color=ryg

Update display screen (without running d.vect again). size reverts to 5 and icon reverts to basic/x

Michael

comment:3 in reply to:  2 Changed 9 years ago by martinl

Replying to cmbarton:

Update display screen (without running d.vect again). size reverts to 5 and icon reverts to basic/x

are you referring to wxGUI or monitors (d.mon)?

comment:4 Changed 9 years ago by cmbarton

wxgui

comment:5 in reply to:  4 Changed 9 years ago by martinl

Replying to cmbarton:

wxgui

  • start wxgui
  • add vector map 'bridges' (no color table defined)
  • set size to '10' and icon to 'basic/box'
  • re-render, OK
  • launch v.colors and set color table to byr
  • re-render, OK, symbols are boxes with size of 10

Right?

comment:6 Changed 9 years ago by cmbarton

Maybe it's happing if v.colors is run with rules=

This effect can be seen when setting color rules via colorrules.py

OnApply? calls v.colors rules=[some rules], and then UpdateMap?. When it does, it resets all d.vect settings back to default except for the color. If it is not v.colors. It is not UpdateMap? that is causing this. The only other command being run is v.colors rules=

comment:7 Changed 9 years ago by cmbarton

The same effect happens in the preview window. This is copying the vector layer command from the layer tree and then running v.colors rules=

comment:8 Changed 9 years ago by annakrat

Yes, I can see where the problem is. I'll fix it tomorrow.

Anna

comment:9 Changed 9 years ago by cmbarton

Thanks Anna.

Michael

comment:10 Changed 9 years ago by annakrat

This bug happens when using GRASSRGB column instead of color table. It should be fixed (r47891). Still I'm not sure if this is the problem you mean.

Anna

comment:11 Changed 9 years ago by cmbarton

I'll test the revision. Thanks. It seems like something in v.colors was running d.vect -a and it shouldn't do that. It should simply set the colors.

Michael

comment:12 in reply to:  11 Changed 9 years ago by martinl

Replying to cmbarton:

I'll test the revision. Thanks. It seems like something in v.colors was running d.vect -a and it shouldn't do that. It should simply set the colors.

v.colors cannot run d.vect itself, it' just modifying color table. wxGUI wrapper runs d.vect for preview. Also note that d.vect -a is required only for color rules stored in attribute table. If you set up file-based color table, d.vect renders vector table colorized without any flag.

comment:13 Changed 9 years ago by cmbarton

This is fixed for the main display, though it would be nice if preview also looked like the main display too. The only issue is that now, a 'no color rules set' error is popping up when colorrules is launched and when a field is selected to create color rules, even if the color rules checkbox is not checked. Probably just needs a conditional for the error check in CreatColorTable? or to move the error check to another position. Thanks much for the fix.

comment:14 Changed 9 years ago by martinl

Component: DefaultwxGUI
Keywords: colorrules added

comment:15 Changed 9 years ago by cmbarton

Resolution: fixed
Status: newclosed

I fixed the error message. The preview display is an enhancement request for colorrules, not v.colors. So this is now fixed. Closing.

Note: See TracTickets for help on using tickets.