[GRASS-dev] v.buffer and v.parallel

[twiens]

Well, I've finally had some time to spend looking at
v.buffer and found that the problem is not easily solved. 

>From what I can tell in the function parallel_line in
(lib/vector/Vlib/buffer.c), there is no checking of what
side of the line is inside or outside of an area. In fact,
near as I can tell there is no way to determine this
information from the GRASS topology information or even from
the DGLib spatial index. So when using Maciek's example
polygon that breaks v.buffer, even running v.parallel
doesn't work properly because in part of the lack of forcing
GRASS digitizing to follow a right-hand rule. I used v.edit
to fix the direction of one of the lines, but it still
doesn't solve the problem completely.

So the first task the must be undertaken, and I have no idea
how to do it, is to force checking of area boundary sides
when buffering areas or creating parallel lines around or
within them. I suspect this will resolve, most if not all
issues, but until this is done, nothing else can be solved. 

I don't understand the vector library well enough to even
begin to address this problem. If others know how to do it,
I would appreciate any assistance or guidance.

Thanks

T

PS for those who don't have this sample polygon here it is:

$ v.in.ascii out=ditch_1205 form=standard -n << EOF
B  4
 600727.68682251 5677973.32091602
 600739.16582305 5678137.49568095
 600736.32863997 5678140.4618269
 600730.63832718 5678056.67823368
B  2
 600730.63832718 5678056.67823368
 600725.02385533 5677974.01131491
C  1 1
 600730.04890192 5678035.56666655
 1     1205
B  2
 600727.68682251 5677973.32091602
 600725.02385533 5677974.01131491
EOF

reproduce the following 2 commands with v.buffer.ellipsoid:

$ v.buffer ditch_1205 out=ditch_1205_b1 type=area buffer=1
$ v.buffer ditch_1205 out=ditch_1205_b4 type=area buffer=4



--
Trevor Wiens
twiens at interbaun.com