[GRASS-dev] bug in Vect_break_lines() ? [bug #2765] [was: v.buffer bug]

[Hamish]

> Hamish wrote:
> > I still see the "holes get filled" bug in my own data though,
..
> > Ahh, I've got you now Obi Wan, the interior-fill bug happens when
> > there is an interior dangle in my road network ... and I've isolated
> > it to a vector made up of 10 polylines.

attached are instructions for recreating the bug with a simplified set
of lines which trigger it.   ("v.clean tool=prune" worked well!)

Things start to go wrong in Vect_break_lines(): the island (hole) in the
middle of the area (test with d.what.vect) becomes an area, so then
area_in_buffer() loops through it as a real overlapping area. Then the
island's centroid is nearer to a boundary than the buffer distance,
which lets it pass the test. Perhaps area_in_buffer() could test cw vs
ccw side of polygon to solve this?

I get the same results if I stop v.buffer with debug=buffer and run
"v.clean tool=break".

also in the Vect_break_lines() step it goes from 8 boundaries to 167,
so I can't later pass a stored buffer value for each of the 8 buffers to
the area_in_buffer() test (but this may not be important if it knows
that the island isn't an area in the first place). It's still a bug that
the dynamic buffer size area_in_buffer() uses the last buffer &
tolerance loaded for post-processing, as I've noted in the source.


> > I don't understand why you consistently get the error, and I
> > don't, using the same* dataset.
..
> Very strange. Maybe it has something to do with the compiler used?
> 
> $ gcc -v
> gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
> 
> Or locale? I'm from Poland, where we use "," instead of "." for
> decimal point delimiter. But how that would impact v.buffer I don't
> know - just trying to think of *something*.
> 
> Does v.buffer depend on anything that could differ between your and my
> system? I'm on Ubuntu Dapper 6.06, kernel 2.6.15-27-686. What is
> yours?

No idea. I'm using Debian/Sarge, gcc 3.3.5, linux 2.4.27-3-686 on a P4.


Can you try running
  v.buffer ditches buffer=4 debug=buffer
? and have a look at the output with d.vect and d.what.vect ?
maybe some clues/hope there.



Hamish
-------------- next part --------------
cat << EOF > vbuf_fill_bug.vasc
L  2 1
 1772686.30519775 5851775.14702921
 1773306.00632122 5852447.04425756
 1     1         
L  2 1
 1774243.98302532 5850080.4624088
 1773306.00632122 5852447.04425756
 1     2         
L  2 1
 1773306.00632122 5852447.04425756
 1773195.48790797 5853628.13605358
 1     3         
L  4 1
 1773145.65706623 5849811.18970544
 1771278.44193002 5850577.88976232
 1771661.0129225 5852557.45636742
 1773195.48790797 5853628.13605358
 1     4         
L  2 1
 1773145.65706623 5849811.18970544
 1774243.98302532 5850080.4624088
 1     5         
L  2 1
 1773218.55495855 5849304     
 1773145.65706623 5849811.18970544
 1     6         
L  2 1
 1773195.48790797 5853628.13605358
 1774528      5854386.23216845
 1     7         
L  2 1
 1774243.98302532 5850080.4624088
 1774528      5850056.01304682
 1     8         
EOF


OUTMAP="vbuf_fill_bug"
v.in.ascii -n in=vbuf_fill_bug.vasc out="$OUTMAP" format=standard

ATTR_COLS="CAT int, ID int, LANE_COUNT int"
v.db.addtable map="$OUTMAP" columns="$ATTR_COLS"

db.execute << EOF
  UPDATE $OUTMAP SET id=16029, lane_count=1 WHERE cat=1;
  UPDATE $OUTMAP SET id=16032, lane_count=1 WHERE cat=2;
  UPDATE $OUTMAP SET id=16032, lane_count=1 WHERE cat=3;
  UPDATE $OUTMAP SET id=6,     lane_count=2 WHERE cat=4;
  UPDATE $OUTMAP SET id=16033, lane_count=2 WHERE cat=5;
  UPDATE $OUTMAP SET id=6,     lane_count=2 WHERE cat=6;
  UPDATE $OUTMAP SET id=6,     lane_count=2 WHERE cat=7;
  UPDATE $OUTMAP SET id=16033, lane_count=2 WHERE cat=8;
EOF

# demonstation of buggy output
v.buffer input=$OUTMAP output=${OUTMAP}_buf_dyn bufcol=LANE_COUNT scale=150

# stop processing after buffering, before cleaning
v.buffer input=$OUTMAP output=${OUTMAP}_buf_dyn_DBGb bufcol=LANE_COUNT \
   scale=150 debug=buffer

# 8 boundaries: how to associate the 8 lane_count values for area_in_buffer() ?
v.info -t ${OUTMAP}_buf_dyn_DBGb
 
 
# notice center hole is not reported an Area
d.vect ${OUTMAP}_buf_dyn_DBGb
d.what.vect

### No good: tool=break makes island into an area, 
###   and makes relating 8 parent polygons to lane_count ?? v.distance ??
# break at intersections
v.clean in=${OUTMAP}_buf_dyn_DBGb out=${OUTMAP}_bdy tool=break
# add centroids
v.category in=${OUTMAP}_bdy out=${OUTMAP}_area step=0
# result: same as v.buffer without debug:
v.dissolve in=${OUTMAP}_area out=${OUTMAP}_final