[GRASSLIST:7581] Re: [bug #3427] Re: Interior Buffers

[Hamish]

> Accidently I have found the functionality you are interested in in
> v.buffer,  which seems to be a undocumented feature or a bug.
> 
> Anyway: if the input for v.buffer is a *closed* *line* (not the area),
> then  the output is an "internal buffer" :) area polygon, which is of
> about  *twice* the extent you provide in option "buffer=".

I don't see this. 

What I do see is:

points are buffered to the correct distance.

areas (boundary + centroid) are buffered externally to the correct
distance.

boundaries without centroid are not buffered.

lines are buffered either side. If the line forms a closed polygon then
the width of the buffer area is 2x the number given for buffer=, but
this is just the sum of the buffering on both sides of the line. The
area is centered on the line. The internal buffer is not 2x the buffer
distance, just 1x.

tip: use 'd.vect cat=1-99999' to only fill where there is data, ie skip
holes.


> I have reported it as a bug
> http://intevation.de/rt/webrt?serial_num=3427.

I just tried your "border" vector file. It works as expected for me:
width is 1x internal, 2x internal+external.

?


> After rethinking it, I'm not sure what to think. It seems a kind of
> bug on  one hand, especially that the "internal buffer" size is 2 x
> the buffer  required, and a cool functionality on the other.

Line is buffered on both sides. How is this new functionality be it 1x
or 2x or 23x buffer width?

 
> The best IMHO would be to extend v.buffer to be able to create such 
> "internal buffers" in a controlled and documented way. Any chances?
> What do  others think?

If you want an inverse buffer of an area make a inverse vector with
v.in.region + v.overlay, then v.buffer on that.



Hamish