[GRASS-dev] New directional buffering module or modified v.buffer

[Dylan Beaudette]

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