I posted a question some time ago about directional or differential
buffering. I've managed to resolve my bugs and am now unsure what is the
best way to incorporate this code back into GRASS. I assume it is
desirable as I assume others may find it useful from time to time.
Largely what I did is modify v.buffer to work with an ellipse rather
than a circle for buffering (you will recall that a circle is actually
just a special case of an ellipse), so that amount of code changed is
minimal. I did however have to replicate some of the code in
Vlib/buffer.c to achieve this. I know that for actual incorporation,
this is a bad thing.
In terms of interface, the scale attribute has been replaced with
nscale, sscale, escale, and wscale for north, south .... If the scale
values are all the same (eg 1.0) then it gives the same result as
v.buffer does now. But when they are different it uses the angle from
the source line in the formula of an ellipse to calculate distance using
the two appropriate cardinal scale values.
Now I could create separate versions of the needed functions in
buffer.c or create a single modified version. In this case v.buffer
would simply be modified and no new module would need to be created. I
could however create a separate module called for example
v.buffer.ellipsoid.
My guess is that we don't really want the code base to grow
without good reason, so it is probably best to modify the
existing routines. Since I don't really like messing with Vlib, I can
write my modifications such that if the scale values are all the same,
the original code is executed, just in case there is something odd that
I've not found in my testing.
Now I seem to have messed up my CVS access so once I get things in
condition to commit, I'll need someone to do it on my behalf.
T
--
Trevor Wiens
twiens@interbaun.com
The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)
On Wednesday 14 March 2007 13:00, Trevor Wiens wrote:
I posted a question some time ago about directional or differential
buffering. I've managed to resolve my bugs and am now unsure what is the
best way to incorporate this code back into GRASS. I assume it is
desirable as I assume others may find it useful from time to time.
Hi Trevor. Can you elaborate on what was causing the 'spikes' in your
previously posted version?
Largely what I did is modify v.buffer to work with an ellipse rather
than a circle for buffering (you will recall that a circle is actually
just a special case of an ellipse), so that amount of code changed is
minimal. I did however have to replicate some of the code in
Vlib/buffer.c to achieve this. I know that for actual incorporation,
this is a bad thing.
In terms of interface, the scale attribute has been replaced with
nscale, sscale, escale, and wscale for north, south .... If the scale
values are all the same (eg 1.0) then it gives the same result as
v.buffer does now. But when they are different it uses the angle from
the source line in the formula of an ellipse to calculate distance using
the two appropriate cardinal scale values.
Now I could create separate versions of the needed functions in
buffer.c or create a single modified version. In this case v.buffer
would simply be modified and no new module would need to be created. I
could however create a separate module called for example
v.buffer.ellipsoid.
My guess is that we don't really want the code base to grow
without good reason, so it is probably best to modify the
existing routines. Since I don't really like messing with Vlib, I can
write my modifications such that if the scale values are all the same,
the original code is executed, just in case there is something odd that
I've not found in my testing.
Although I am not a developer, it seems that modifying the buffer.c functions
(pending thorough testing) would be the best long-term strategy. These
extensions to simple GIS functionality are a great asset to GRASS.
Now I seem to have messed up my CVS access so once I get things in
condition to commit, I'll need someone to do it on my behalf.
T
cheers,
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341
Trevor Wiens wrote:
I posted a question some time ago about directional or differential
buffering. I've managed to resolve my bugs and am now unsure what is the
best way to incorporate this code back into GRASS. I assume it is
desirable as I assume others may find it useful from time to time.
Trevor,
Sure, sounds interesting! I'm also hoping that your v.buffer
modification will not suffer from the bug v.buffer does. Can you try
creating a vector in a following way,
$ 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
and let us know if the resulting buffers are OK? Most folks who tried
it (actually, everyone who reported, besides Hamish) confirmed the
output of v.buffer was bad. If v.buffer.ellipsoid has this problem
fixed, it would be great news and I'd say that it should replace
v.buffer then, if possible.
Cheers
Maciek
On Wed, 14 Mar 2007 13:55:15 -0700
Dylan Beaudette wrote:
On Wednesday 14 March 2007 13:00, Trevor Wiens wrote:
> I posted a question some time ago about directional or differential
> buffering. I've managed to resolve my bugs and am now unsure what is the
> best way to incorporate this code back into GRASS. I assume it is
> desirable as I assume others may find it useful from time to time.
Hi Trevor. Can you elaborate on what was causing the 'spikes' in your
previously posted version?
There were two problems, one related to a sign issue in my own
code. The second related to inserting segments to round
corners when there is a change in direction. The buffer.c
Vect_line_buffer code inserts an additional point and then re-inserts
the starting point to close the polygon. I wasn't able to grok its
location calculation so by simply commenting out the problem went away.
It doesn't appear to cause any problems when inspecting the results
visually.
T
--
Trevor Wiens
twiens@interbaun.com
The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)
On Wed, 14 Mar 2007 22:30:13 +0100
Maciej Sieczka wrote:
--- snip ---
and let us know if the resulting buffers are OK? Most folks who tried
it (actually, everyone who reported, besides Hamish) confirmed the
output of v.buffer was bad. If v.buffer.ellipsoid has this problem
fixed, it would be great news and I'd say that it should replace
v.buffer then, if possible.
Well, it reproduces probably the same error that others are seeing.
After fiddling with this code for a couple of days I think I can
identify where the problems are, but will have to invest some time in
thinking about how to solve it.
My quick assessment is as follows. On the west side, the bump is a
function of creating a semicircle to round the corner because there is
a new line segment. Unfortunately because there was no change in
direction, this semi-circle should not have been created.
On the south, the opposite direction is a function of angle of the line
being misread as to which is the inside and the outside. The north end
problem is the same problem.
Well, I guess I need to solve these problems before committing changes
to v.buffer. I take it that the general feeling is that enhancing
v.buffer is better than adding another module.
This may take a few days. I'll keep you posted.
T
--
Trevor Wiens
twiens@interbaun.com
The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)