Opened 8 years ago

Closed 8 years ago

#1632 closed defect (fixed)

v.proj: split_q.c:69: RTreeClassify: Assertion `!p->taken[i]' failed. in the same projection

Reported by: pertusus Owned by: grass-dev@…
Priority: normal Milestone: 7.0.0
Component: Vector Version: 6.4.2
Keywords: Cc:
CPU: x86-64 Platform: All

Description

I have a vector map of lines I did myself (automatically, though), in the grass ascii format. In one location I import it with v.in.ascii with format=standard and everything seems fine.

When I project to a location that is exactly in the same projection, however, I get

v.proj potential_reservoir_demands_links location=proj_location
Building topology for vector map <potential_reservoir_demands_links>...
Registering primitives...
v.proj: split_q.c:69: RTreeClassify: Assertion `!p->taken[i]' failed.

I did a backtrace in gdb

(gdb) run
Starting program: /usr/lib64/grass-6.4.2/bin/v.proj potential_reservoir_demands_links location=proj_location
[Thread debugging using libthread_db enabled]
Building topology for vector map <potential_reservoir_demands_links>...
Registering primitives...
v.proj: split_q.c:69: RTreeClassify: Assertion `!p->taken[i]' failed.

Program received signal SIGABRT, Aborted.
0x0000003fdb432885 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003fdb432885 in raise () from /lib64/libc.so.6
#1  0x0000003fdb434065 in abort () from /lib64/libc.so.6
#2  0x0000003fdb42b9fe in __assert_fail_base () from /lib64/libc.so.6
#3  0x0000003fdb42bac0 in __assert_fail () from /lib64/libc.so.6
#4  0x000000314f802fcb in RTreeClassify (i=0, group=<value optimized out>, p=0x314fa04be0) at split_q.c:69
#5  0x000000314f803519 in RTreePickSeeds (n=0xb29a70, b=<value optimized out>, nn=0x7fffffffca68) at split_q.c:114
#6  RTreeMethodZero (n=0xb29a70, b=<value optimized out>, nn=0x7fffffffca68) at split_q.c:230
#7  RTreeSplitNode (n=0xb29a70, b=<value optimized out>, nn=0x7fffffffca68) at split_q.c:307
#8  0x000000314f80225c in RTreeAddBranch (B=<value optimized out>, N=<value optimized out>, New_node=<value optimized out>)
    at node.c:201
#9  0x000000314f801a9b in RTreeInsertRect2 (r=0x7fffffffce50, child=0x5a3a, n=0xb29a70, new_node=0x7fffffffca68,
    level=<value optimized out>) at index.c:121
#10 0x000000314f801b15 in RTreeInsertRect2 (r=0x7fffffffce50, child=0x5a3a, n=0xb2d270, new_node=0x7fffffffcb28,
    level=<value optimized out>) at index.c:102
#11 0x000000314f801b15 in RTreeInsertRect2 (r=0x7fffffffce50, child=0x5a3a, n=0xae3c90, new_node=0x7fffffffcbe8,
    level=<value optimized out>) at index.c:102
#12 0x000000314f801b15 in RTreeInsertRect2 (r=0x7fffffffce50, child=0x5a3a, n=0xb0fd40, new_node=0x7fffffffcca8,
    level=<value optimized out>) at index.c:102
#13 0x000000314f801b15 in RTreeInsertRect2 (r=0x7fffffffce50, child=0x5a3a, n=0xa90b80, new_node=0x7fffffffcd68,
    level=<value optimized out>) at index.c:102
#14 0x000000314f801b15 in RTreeInsertRect2 (r=0x7fffffffce50, child=0x5a3a, n=0x946320, new_node=0x7fffffffce18,
    level=<value optimized out>) at index.c:102
#15 0x000000314f801d00 in RTreeInsertRect1 (R=<value optimized out>, Child=<value optimized out>, Root=0x7fffffffd2c0,
    Level=<value optimized out>) at index.c:162
#16 0x000000315040d609 in dig_spidx_add_line (Plus=0x7fffffffd0b0, line=23098, box=0x7fffffffceb0) at spindex.c:160
#17 0x0000003150409350 in add_line (plus=0x7fffffffd0b0, lineid=23098, type=2, Points=0x60acf0, offset=854603)
    at plus_line.c:83
#18 0x0000003150409520 in dig_add_line (plus=0x7fffffffd0b0, type=2, Points=<value optimized out>,
    offset=<value optimized out>) at plus_line.c:114
#19 0x00000034f7815bed in Vect_build_nat (Map=0x7fffffffd0a0, build=4) at build_nat.c:537
#20 0x00000034f7814686 in Vect_build_partial (Map=0x7fffffffd0a0, build=4) at build.c:134
#21 0x0000000000402366 in main (argc=6326848, argv=0x608a40) at main.c:300

It is reproducible, but I also do the same for different maps and on different locations (all Lambert) and it leads to the assertion only in one case.

I attach a tarball that allows to reproduce the issue.

After expanding and cd'ing into, you should adjust the path to grass in and proj.sh. Then run

./do_all.sh

which simply runs ./prepare_location.sh that does the v.in.ascii and then ./proj.sh that does the v.proj.

Attachments (1)

bug_v_proj.tar.gz (168.0 KB) - added by pertusus 8 years ago.
tarball to reproduce the assertion

Download all attachments as: .zip

Change History (2)

Changed 8 years ago by pertusus

Attachment: bug_v_proj.tar.gz added

tarball to reproduce the assertion

comment:1 Changed 8 years ago by mmetz

Milestone: 6.4.37.0.0
Platform: LinuxAll
Resolution: fixed
Status: newclosed

This is a bug in the spatial index used by the vector library in 6.x. Import works fine in 7.0, which uses a different spatial index. The result seems to be ok, because the bounding boxes are identical and the vector features seem to be identical judged by visual inspection. This bug fix can not be backported and will thus not be fixed in 6.x.

Markus M

Note: See TracTickets for help on using tickets.