[GRASS-dev] backporting new v.digit to the 6.2 branch

[Hamish]

> Hamish wrote:
> > Can anyone point to **specific bug reports that cause a crash or
> > data loss, and are fixed in the 6.3-CVS version**?
> > 
> > https://intevation.de/rt/webrt?q_status=open&q_queue=grass&q_subject=v.digit

Maciej wrote:
> Issues resolved in 6.3 CVS but present in 6.2, AFAIK, [1],[2],[3]:


> [1]https://intevation.de/rt/webrt?serial_num=4110
> 1. One can't use encodings besides ISO-8859-1 in data tables [1].

Certainly annoying for non-English folks, but this is a feature enhancement
- not a critical bug - so not a backport candidate.
Does the same issue exist for "d.what.vect -e"?


> [2]https://intevation.de/rt/webrt?serial_num=4454
 "v.digit: 'Digitize new point' tool is activated by default"
 "It shouldn't. None other tool should either."

This is more of a wish/annoyance than a bug, certainly not a serious bug.
Not a backport candidate.


> [3]http://grass.itc.it/pipermail/grassuser/2007-February/038176.html
> 2. One can't digitize areas [3].
> The issue [3] was never reported in the tracker but it's present in
> 6.2 and fixed in 6.3, AFAICT.

Ok, this one is a backport candidate if we can isolate it & fix it.
But I can't reproduce it. I tried:

#spearfish60 + DBF driver
g.region rast=roads

v.digit -n new_map1
digitize 5 new boundaries
use move vertex tool to close the 5 boxes
choose add centroid tool
for Mode select "No category"
put a centroid in each box
remove all centroids with the delete feature tool
put a centroid in each box
remove all centroids with the delete feature tool
change Mode to "Manual Entry" (1)
put a centroid in each box
remove all centroids with the delete feature tool
change Mode to "Next not used"
put a centroid in each box
remove all centroids with the delete feature tool
remove all boundaries with the delete feature tool
add a bunch of centroids into empty space
remove them
add them again
remove them again

all works as expected. shrug. maybe need to add 100+ centroids? (hours of
work lost; new user never uses grass again)

Jarek says in the OP "This is my first digitizing task", so maybe the
problem is related to a default DB not yet being chosen??? trying in
a new mapset without a "VAR" file, I still can't reproduce it.

I see in a new post you say it happens when *editing attributes*.
I didn't try that as it wasn't mentioned in the parent post. I'll
try that now & report back in a followup post.



> Present in both in 6.2 and 6.3 are, AFAIK, [4],[5].

Thus not reasons to backport the full 6.3 version; but while we are here,
a quick look anyway:

> [4]https://intevation.de/rt/webrt?serial_num=5127
Was this mentioned on the mailing list in just the last day or two?

> [5]https://intevation.de/rt/webrt?serial_num=2962
[v.digit changes the WIND file instead of setting up a WIND_OVERRIDE
setting or similar] Also might not use "g.region -a" alignment during
zooming/panning so underlayed raster at coarse res may appear to shift
about under the vector line leading to inexact digitization.
from the bug report:
"Hamish: This bug should be kept open as the v.digit code should a) not
be changing the WIND file (if that's possible with mixed Tcl + C) and
b) use "g.region -a" like code when zooming so as not to corrupt
background raster resampling."
Note that it now restores the startup region upon clean exit.



So it boils down to issue [3] "can't digitize centroids".
But this works fine for me in 6.2.1, so .....?



what's more, v.digit in GRASS 6.3 segfaults on startup for me currently.
Not an encouraging sign for the 6.3 version being mature enough to
backport.

g.region rast=roads
v.digit -n test_dig_area
New empty map created.
###wish gui flashes up then disappears###
Segmentation fault

gdb:
G63> gdb `which v.digit`
..
(gdb) run -n test_map1
Starting program: /usr/local/src/grass/grass63/dist.i686-pc-linux-gnu/bin/v.digit -n test_map1
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 9024)]
New empty map created.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 9024)]
0x406e4a02 in Tcl_ParseCommand () from /usr/lib/libtcl8.3.so.1

(gdb) where
#0  0x406e4a02 in Tcl_ParseCommand () from /usr/lib/libtcl8.3.so.1
#1  0x406e5a77 in Tcl_EvalEx () from /usr/lib/libtcl8.3.so.1
#2  0x406e5967 in Tcl_EvalTokens () from /usr/lib/libtcl8.3.so.1
#3  0x406e5ad8 in Tcl_EvalEx () from /usr/lib/libtcl8.3.so.1
#4  0x406e5ead in Tcl_Eval () from /usr/lib/libtcl8.3.so.1
#5  0x0805074f in get_window (t=0xbfffdddc, b=0xbfffddd8, l=0xbfffddd4, r=0xbfffddd0) at driver.c:58
#6  0x08050811 in setup () at driver.c:73
#7  0x0805091c in driver_open () at driver.c:101
#8  0x0804f9cd in tool_centre () at centre.c:50
#9  0x0804e9b7 in c_tool_centre (cdata=0x0, interp=0x8069248, argc=1, argv=0xbfffdf40) at c_face.c:159
#10 0x406ad7ab in TclInvokeStringCommand () from /usr/lib/libtcl8.3.so.1
#11 0x406e529c in TclExpandTokenArray () from /usr/lib/libtcl8.3.so.1
#12 0x406e5b3d in Tcl_EvalEx () from /usr/lib/libtcl8.3.so.1
#13 0x406dca0e in Tcl_EvalFile () from /usr/lib/libtcl8.3.so.1
#14 0x40609774 in Tk_MainEx () from /usr/lib/libtk8.3.so.1
#15 0x08055102 in main (argc=3, argv=0xbffff6b4) at main.c:171


same thing starting with:
G63> GRASS_WISH=wish8.4  v.digit -n test_map2

[as Glynn stated in an earlier thread, debugging C+Tcl mixed code is a
real pain]


We seem to have agreed (yes?) that backporting the new EPSG code search
tool in violation of the "fixes for serious bugs only" rule is ok, as
it is a non-critical component and the new version is really really nice.
So I hope I'm not seeming to be unfair in playing conservative with
v.digit while at the same time pushing for the new EPSG picker.



regards,
Hamish