[SoC] Re: [GRASS-dev] SoC Report: v.buffer/v.parallel reimplementation

[Росен Матев]

---------- Forwarded message ----------
From: Росен Матев <r.matev at gmail.com>
Date: Sun, Jun 15, 2008 at 12:09 PM
Subject: Re: [GRASS-dev] SoC Report: v.buffer/v.parallel reimplementation
To: hamish_b at yahoo.com


Hi Hamish,

Thanks for the suggestions. I'll strip out those G_message calls. I
like the 'both' option and I'll add it. Generating lines which are
parallel "on the ground" is much tougher than simply changing the
LENGTH function. The first thing I'll do after I finish the
traditional parallel lines and buffers is to do some research on this
topic (making parallel lines on ellipsoids' surface).

Regards,
Rosen

On Sat, Jun 14, 2008 at 5:19 AM, Hamish <hamish_b at yahoo.com> wrote:
> Hi,
>
> I know it is very much a work in progress, but some minor comments/suggestions.
>
> http://trac.osgeo.org/grass/changeset/31708
>
> v.parallel2/main.c
> -side_opt->options = "left,right";
> +side_opt->options = "both,left,right";
> ?
>
> v.parallel2/vlib_buffer.c
> +#define LENGTH(DX, DY) (sqrt((DX*DX)+(DY*DY)))
>
> why not use hypot() ? There are vector library versions too, for both Cartesian and lat/lon. Vect_line_length(), Vect_line_geodesic_length() and the rest in lib/vector/Vlib/line.c
> Vect_line_geodesic_length() will switch to hypot if location is not lat/lon, otherwise it uses the great circle calc.
>
> any thoughts in general on how to deal with parallel lines in lat/lon? I would guess to make them parallel "on the ground" rather than as simple parallel rhumblines.
>
> 3D?
>
>
> +G_message("tol=%f atol=%f", tol, angular_tol);
> I would recommend making good use of G_debug() there. You can set the level to "0" to always show the message when developing then adjust that to something higher later on.
>
>
> that's all,
> Hamish
>
>
>
>
>
>
>