[GRASS5] [5.7] v.digit

[Hamish]

> > some requests/feedback for 5.7's v.digit:
...
> > 1) remove vertex:
> > when there are duplicates, there needs to be some way to select
> > next/previous line. Otherwise it can be impossible to get rid of
> > duplicates by hand. GRASS 5.0's v.digit can do this.
> >
> >         |---------|         what I want to get rid of
> >
> > --x-----x---------x------>  displayed
> >
> >         |---------------->  only line it will select with mouse
> 
> This requires more work, see below.

I was able to work around this by trying again and removing lines in a 
different order, but I guess the problem still remains. Anther solution
might be to use the 'move vertex' to tease out one end of the bad line
so you can select it ..


> BTW, how this can be done in 5.0?

src/mapdev/v.digit/node_lines.c
src/mapdev/v.digit/mouse_yn.c


> > 2) settings/symbology (colors):
> > yellow is very hard to see on the white background.
> > Change default highlight color to blue?
> > Make no default color the same?
> 
> Blues is hard to see on orthophoto (often dark (forest)), cyan?

mmm I see. I was just draping the vectors without a backdrop.
I can see yellow looking good there.

Cyan would be ok, maybe just a darker yellow is needed?
I'm not too picky about it, but what's there now is hard too see on a 
white backdrop.

Also I found it hard to track down the red "+" errors on a complicated 
unclosed-area boundary that was also colored red. Making the boundary 
light grey made them show up well.. the bright cyan looks good there too.

I see you get to choose from 256:256:256 so the choices are endless.


> > 3) settings/symbology (colors):
> > Unchecking box for "Node (2 lines)" & then redraw doesn't work.
> >
> > It is impossible to track down where area boundaries are open when
> > every node is shown! Had to export to GRASS 5.0 to see where the
> > problem was.
> 
> Yes, this was bug and I have fixed that, will be in cvs soon.

already done ;)


> > 4) Is it possible to exit without saving?
> > Nice for beginners, as there is no required input= and output=, and
> > you don't always remember to make a copy first.
> 
> No, each change is immediately written to disk, this is vector library
> feature.

Could it save to a temporary vector file and copy over to the real one
at the very end? Right now the vector file ends up broken if v.digit is
killed or crashes during editing.. or is this too much overhead on a huge
vector? (e.g. I have several 600mb-1gig vector maps)


> > 5) XFree86 is using ~45% of the local CPU when v.digit is running.
> > ssh uses about another 45% (tunneled X over ssh). Is it stuck in
> > some sort of feedback loop? When you click exit, it stops as soon as
> > "Registering Lines:   nnnnn", seconds before the menu disappears.
> 
> The loop is used in R_get_location_*(), that means always, when
> v.digit is waiting for input in XDRIVER. 

Is it useful in this situation to put a 20ms sleep towards the end of 
the loop to slow it down, but still too fast for humans to notice?

 
> I don't want to spend too much time on v.digit, it was temporary
> solution, my plan is to add v.digit functionality to QGIS.

FWIW, I think it's pretty good right now. The UI is so much better than the
old one that it makes up for any missing features of the old v.digit.

[eg missing feature in the new one: Toolbox->"d" : Display Duplicate lines]


Were you planning on QGIS becoming the main way to edit vectors for GRASS,
or just would rather someone else took care of v.digit?



regards,
Hamish