[GRASS5] v.buffer now does v.bubble

GRASS GIS GRASS GIS developer
1

Hi,

v.buffer now can do dynamic buffer sizes with values taken from an
attribute column and scale factor. Probably buggy so please test/fix.

As previously, overlapping circle boundaries are disolved into one
cohesive blob, with boundary cat number changing as you go around the
edge to refer to the closest source cat.

works for all supported vector feature types.

previously you had to use 'd.vect.chart ctype=pie' or ps.map::vpoints::
sizecol or a mad v.buffer+v.patch script.

I wouldn't mind renaming the "bufcol" option something else if someone
can think of something better. I don't want it to collide with buffer=
in the parser (I don't mind typing buff=100, but buffer=100 would be
annoying to type every time if the first 6 letters were not unique).

enjoy,
Hamish

2

Hamish,

are you sure it works? I am almost sure it does not.
The first part which cunstructs buffer boundaries is OK.
The second which decides which areas are in buffer
(function area_in_buffer ) is using constant buffer size.
It will not be so easy, you have to rewrite
area_in_buffer() function to always check the right buffer
size for each feature in neighbourhood.

Radim

On 11/8/05, Hamish <hamish_nospam@yahoo.com> wrote:

Hi,

v.buffer now can do dynamic buffer sizes with values taken from an
attribute column and scale factor. Probably buggy so please test/fix.

As previously, overlapping circle boundaries are disolved into one
cohesive blob, with boundary cat number changing as you go around the
edge to refer to the closest source cat.

works for all supported vector feature types.

previously you had to use 'd.vect.chart ctype=pie' or ps.map::vpoints::
sizecol or a mad v.buffer+v.patch script.

I wouldn't mind renaming the "bufcol" option something else if someone
can think of something better. I don't want it to collide with buffer=
in the parser (I don't mind typing buff=100, but buffer=100 would be
annoying to type every time if the first 6 letters were not unique).

enjoy,
Hamish

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

3

> v.buffer now can do dynamic buffer sizes with values taken from an
> attribute column and scale factor. Probably buggy so please
> test/fix.

..

are you sure it works? I am almost sure it does not.

I tested it on some simple point, line, and area input maps and it
seemed to work ok. Obviously not enough. "Partially functional" might be
a good way to describe it. Boundaries are generated correctly, centroids
are not always correct.

screenshots:
http://bambi/hamish/grass/v_buffer_lines_9Nov2005.png
(d.vect cat=1-99999, buffer size taken from number of road lanes
   column, note areas filled in error)

http://bambi/hamish/grass/v_buffer_points_9Nov2005.png
http://bambi/hamish/grass/v_buffer_points2_9Nov2005.png
(note ok centroid placement in this case)

The first part which cunstructs buffer boundaries is OK.
The second which decides which areas are in buffer
(function area_in_buffer ) is using constant buffer size.
It will not be so easy, you have to rewrite
area_in_buffer() function to always check the right buffer
size for each feature in neighbourhood.

Yes.......... I didn't get that far down into the code. so centroid
placement can be bad for the 2 calls to area_in_buffer(), as buffer
and tolerance are taken from last category encountered. Not sure
what happens when entire column is null, zero, or negative. "buffer"
gets used uninitialized I guess.

On the positive side only the new code is broken and using a
constant buffer will still work the same, so we don't have to revert
the code while we try for a fix. And I think it is useful even now.

I am forgetting the module that adds missing centroids.. maybe document
v.extract type=boundary + that as a work around until it is fixed.
Or is there a problem whether or not islands/holes get a category number
when they shouldn't then?

For a v.bubble replacement it isn't very good to use this module as
small bubbles will be disolved in bigger bubbles. Better for people to
use d.vect.chart or the v.buffer+v.patch loop for that I guess.

I will discuss possible fixes in another email. (still have to study the
different point in polygon tests & a different one I have used in the past)

Hamish

4

On the positive side only the new code is broken and using a
constant buffer will still work the same, so we don't have to revert
the code while we try for a fix. And I think it is useful even now.

It can be for a while in CVS, but it cannot be in release.

I am forgetting the module that adds missing centroids.. maybe document
v.extract type=boundary + that as a work around until it is fixed.
Or is there a problem whether or not islands/holes get a category number
when they shouldn't then?

Yes it is problem, it works like this:
1) generate boundaries around input features
2) break and clean boundaries to get clean topology
3) create centroids in ALL areas (including those outside
    buffer, e.g. those which become islands in utput)
4) identify centroids in buffer
5) merge (dissolve boundaries) areas in buffer
6) delete centroids outside buffer

For a v.bubble replacement it isn't very good to use this module as
small bubbles will be disolved in bigger bubbles.

I will be once we add also the possibility to assign categories
of input features to buffers. That means merge only the areas
with the same categories. So I think you can go on here.

Radim