Hello,
I'm currently reimplementing v.parallel/v.buffer. There are some
strange inputs with no apparent behavior. Please suggest what should
v.parallel do on such inputs.
I've attached a simple input. Try to make a parallel line on right
side of the given line; distance is greater than 5m (let's say 7m).
v.parallel outputs strange things, given such input.
v.in.ascii -n format=standard output=test1 input=test1.txt
test1.txt:
L 6
600000.00000000 5670020.00000000
600030.00000000 5670020.00000000
600030.00000000 5670050.00000000
600040.00000000 5670050.00000000
600040.00000000 5670000.00000000
600080.00000000 5670000.00000000
v.parallel input=test1 output=test1_par7 distance=7
On Mon, May 26, 2008 at 3:02 PM, Росен Матев <r.matev@gmail.com> wrote:
Hello,
I'm currently reimplementing v.parallel/v.buffer. There are some
strange inputs with no apparent behavior. Please suggest what should
v.parallel do on such inputs.
I've attached a simple input. Try to make a parallel line on right
side of the given line; distance is greater than 5m (let's say 7m).
Hello Росен,
actually it's quite interesting case from two aspects:
1) should line overlap (cross with it self)?
2) should parallel line corners be round? One could expect, that
parallel line is parallel and not curved around corners. I understand
that current v.parallel behavior is meant for creating buffers but
that doesn't mean it's correct.
Let's see what others will say.
Maris.
Hi!
IMHO it should loop back, and by default the loop should be detected and removed. An option to not remove the loop could be cool.
See attached image. The part that should be removed is drawn with a dashed line.
--Wolf
On 26.05.2008 15:02, Росен Матев wrote:
Hello,
I'm currently reimplementing v.parallel/v.buffer. There are some
strange inputs with no apparent behavior. Please suggest what should
v.parallel do on such inputs.
I've attached a simple input. Try to make a parallel line on right
side of the given line; distance is greater than 5m (let's say 7m).------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
<:3 )---- Wolf Bergenheim ----( 8:>
Hi Maris,
I'll add option for round/straight corners. I think v.parallel should
default to straight corners, current behavior doesn't look
'parallelish'. We'll wait for others to say what they think. Wolf
already suggested that the output should look like a step( -----i____
ugly ascii art).
Hi Wolf,
The thing that bothers me is the upper line segment of the loop. It's
parallel to the corresponding segment of input line but it's direction
is the opposite. That is quite "non-algorithmic".
By the way, I'm pretty sure that I figured out an algorithm, which
will create 'proper' parallel line s (without loops as in Wolf's
non-dashed example). Unlike the old method of creating parallel lines
with loops and then cleaning the mess, my algorithm works in one
piece. (I think the old method doesn't work because you cannot remove
the loops properly by only using the line-with-loops itself)
Rosen
On Mon, May 26, 2008 at 9:15 PM, Wolf Bergenheim
<wolf+grass@bergenheim.net> wrote:
Hi!
IMHO it should loop back, and by default the loop should be detected and
removed. An option to not remove the loop could be cool.See attached image. The part that should be removed is drawn with a dashed
line.--Wolf
On 26.05.2008 15:02, Росен Матев wrote:
Hello,
I'm currently reimplementing v.parallel/v.buffer. There are some
strange inputs with no apparent behavior. Please suggest what should
v.parallel do on such inputs.
I've attached a simple input. Try to make a parallel line on right
side of the given line; distance is greater than 5m (let's say 7m).------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev--
<:3 )---- Wolf Bergenheim ----( 8:>
Hi,
IMHO, the wolf`s approach is the good one, since the 'proper'
parallel line must be choosen by users.
i prefere it because it is flexible and can be very fast if there is
no need to remove the loop or no loop are expected.
marco
2008/5/26, Росен Матев <r.matev@gmail.com>:
Hi Wolf,
The thing that bothers me is the upper line segment of the loop. It's
parallel to the corresponding segment of input line but it's direction
is the opposite. That is quite "non-algorithmic".
By the way, I'm pretty sure that I figured out an algorithm, which
will create 'proper' parallel line s (without loops as in Wolf's
non-dashed example). Unlike the old method of creating parallel lines
with loops and then cleaning the mess, my algorithm works in one
piece. (I think the old method doesn't work because you cannot remove
the loops properly by only using the line-with-loops itself)Rosen
On Mon, May 26, 2008 at 9:15 PM, Wolf Bergenheim
<wolf+grass@bergenheim.net> wrote:
> Hi!
>
> IMHO it should loop back, and by default the loop should be detected and
> removed. An option to not remove the loop could be cool.
>
> See attached image. The part that should be removed is drawn with a dashed
> line.
>
> --Wolf
>
> On 26.05.2008 15:02, Росен Матев wrote:
>>
>> Hello,
>> I'm currently reimplementing v.parallel/v.buffer. There are some
>> strange inputs with no apparent behavior. Please suggest what should
>> v.parallel do on such inputs.
>> I've attached a simple input. Try to make a parallel line on right
>> side of the given line; distance is greater than 5m (let's say 7m).
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> --
>
> <:3 )---- Wolf Bergenheim ----( 8:>
>
>_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
Ok, I'll try to figure out how to generate such looped parallel line.
I'll note again that my algorithm, which generates non-looped parallel
lines (like the ones that should be generated when making buffers),
does not go through stage, in which there are loops. Therefore,
generating those looped lines will need another separate algorithm
(with some familiarities, but not much).
Rosen
On Mon, May 26, 2008 at 11:14 PM, Marco Alicera <marco.alicera@gmail.com> wrote:
Hi,
IMHO, the wolf`s approach is the good one, since the 'proper'
parallel line must be choosen by users.i prefere it because it is flexible and can be very fast if there is
no need to remove the loop or no loop are expected.marco
2008/5/26, Росен Матев <r.matev@gmail.com>:
Hi Wolf,
The thing that bothers me is the upper line segment of the loop. It's
parallel to the corresponding segment of input line but it's direction
is the opposite. That is quite "non-algorithmic".
By the way, I'm pretty sure that I figured out an algorithm, which
will create 'proper' parallel line s (without loops as in Wolf's
non-dashed example). Unlike the old method of creating parallel lines
with loops and then cleaning the mess, my algorithm works in one
piece. (I think the old method doesn't work because you cannot remove
the loops properly by only using the line-with-loops itself)Rosen
On Mon, May 26, 2008 at 9:15 PM, Wolf Bergenheim
<wolf+grass@bergenheim.net> wrote:
> Hi!
>
> IMHO it should loop back, and by default the loop should be detected and
> removed. An option to not remove the loop could be cool.
>
> See attached image. The part that should be removed is drawn with a dashed
> line.
>
> --Wolf
>
> On 26.05.2008 15:02, Росен Матев wrote:
>>
>> Hello,
>> I'm currently reimplementing v.parallel/v.buffer. There are some
>> strange inputs with no apparent behavior. Please suggest what should
>> v.parallel do on such inputs.
>> I've attached a simple input. Try to make a parallel line on right
>> side of the given line; distance is greater than 5m (let's say 7m).
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> --
>
> <:3 )---- Wolf Bergenheim ----( 8:>
>
>_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi Rosen,
On 26.05.2008 22:50, Росен Матев wrote:
Hi Wolf,
The thing that bothers me is the upper line segment of the loop. It's
parallel to the corresponding segment of input line but it's direction
is the opposite. That is quite "non-algorithmic".
It is a result of the precondition that the parallel line cannot cross the line to the left side when following. It is allowed for it to cross the original line when going in the opposite direction.
Hope this vague explanation helps.
--Wolf
By the way, I'm pretty sure that I figured out an algorithm, which
will create 'proper' parallel line s (without loops as in Wolf's
non-dashed example). Unlike the old method of creating parallel lines
with loops and then cleaning the mess, my algorithm works in one
piece. (I think the old method doesn't work because you cannot remove
the loops properly by only using the line-with-loops itself)
Cool. Looking forward to seeing it 
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
Росен wrote:
Ok, I'll try to figure out how to generate such looped
parallel line.
I'll note again that my algorithm, which generates
non-looped parallel
lines (like the ones that should be generated when making
buffers),
does not go through stage, in which there are loops.
Therefore,
generating those looped lines will need another separate
algorithm
(with some familiarities, but not much).
I think it is often useful to think of things from the application point of view. ie what are we trying to model? telephone wires some distance from a road? coverage of a long lawn-mower arm? that can help put the task in perspective.
2c,
Hamish
Hi again,
This time I'm challenging you with another strange line. What should
v.parallel output, with options dist=7, side=left and straight corners
(round corners), given that input? I won't give you current behavior
of v.parallel2 (or other suggestions), cause I don't want to influence
on your opinion.
Rosen
And here is the input
Absently,
Rosen
On Tue, Jun 17, 2008 at 12:31 AM, Росен Матев <r.matev@gmail.com> wrote:
Hi again,
This time I'm challenging you with another strange line. What should
v.parallel output, with options dist=7, side=left and straight corners
(round corners), given that input? I won't give you current behavior
of v.parallel2 (or other suggestions), cause I don't want to influence
on your opinion.Rosen
Hi
Note that this particular input produces wrong buffers when using the
old v.buffer and vlib/buffer.c (no matter what the specified distance
is: dist < 5, 5 < dist < 10, dist > 10, it outputs wrong things).
Similar issues will arise when using the new buffer.c. As I was
thinking how to resolve them, I've come to the conclusion that it
might not be possible to use the parallel line generation to make
buffers. I'll think over it a little more and then I'll decide
(hopefully with your help) whether it is inevitable to separate
v.buffer from parallel line generation.
Actually, when dist <= 1.61, v.buffer works fine.
Waiting for suggestions,
Rosen
On Wed, Jun 18, 2008 at 3:17 PM, Росен Матев <r.matev@gmail.com> wrote:
Hi
Note that this particular input produces wrong buffers when using the
old v.buffer and vlib/buffer.c (no matter what the specified distance
is: dist < 5, 5 < dist < 10, dist > 10, it outputs wrong things).
Similar issues will arise when using the new buffer.c. As I was
thinking how to resolve them, I've come to the conclusion that it
might not be possible to use the parallel line generation to make
buffers. I'll think over it a little more and then I'll decide
(hopefully with your help) whether it is inevitable to separate
v.buffer from parallel line generation.
I have 2 solutions depending on what you need. Solution A stays true to the direction of the line and follows it regardless of loops and what not.
Solution B will not cross the line. To get this solution you will probably have to find all the internal intersections of the line and at each intersection go so that you don't cross the line. Solution A is not concerned with intersections. It would be cool if v.parallel can support both, maybe via a switch.
--Wolf
On 17.06.2008 00:37, Росен Матев wrote:
And here is the input
Absently,
RosenOn Tue, Jun 17, 2008 at 12:31 AM, Росен Матев <r.matev@gmail.com> wrote:
Hi again,
This time I'm challenging you with another strange line. What should
v.parallel output, with options dist=7, side=left and straight corners
(round corners), given that input? I won't give you current behavior
of v.parallel2 (or other suggestions), cause I don't want to influence
on your opinion.Rosen
------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
<:3 )---- Wolf Bergenheim ----( 8:>
Solution B may require option to create a hole within that loop, if
buffer not fully covers whole loop (like in attached sketch).
IMHO it's clear now, that buffers and parallel lines are similar but
not same. New v.buffer could offer list of available buffer creation
algorithms - buffer whole feature; with holes; respect line
directions. Just an idea.
Rosen - start with simplest one and leave possibility to add different
ones in future?
Just my 0.002.
Maris.
2008/6/18, Wolf Bergenheim <wolf+grass@bergenheim.net>:
I have 2 solutions depending on what you need. Solution A stays true to
the direction of the line and follows it regardless of loops and what not.Solution B will not cross the line. To get this solution you will
probably have to find all the internal intersections of the line and at
each intersection go so that you don't cross the line. Solution A is not
concerned with intersections. It would be cool if v.parallel can support
both, maybe via a switch.--Wolf
On 17.06.2008 00:37, Росен Матев wrote:
And here is the input
Absently,
RosenOn Tue, Jun 17, 2008 at 12:31 AM, Росен Матев <r.matev@gmail.com> wrote:
Hi again,
This time I'm challenging you with another strange line. What should
v.parallel output, with options dist=7, side=left and straight corners
(round corners), given that input? I won't give you current behavior
of v.parallel2 (or other suggestions), cause I don't want to influence
on your opinion.Rosen
------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev--
<:3 )---- Wolf Bergenheim ----( 8:>
Hi,
I propose that I cancel development of "clean_parallel()" (the
function which removes loops), cause its proper behavior is not
determined now (and it might not be possible to determine it).
Instead, I'll start making function which generates "type B" lines,
which will be more useful in buffer generation. What do you think
about it?
Rosen
Hello, Росен!
I think, it's OK for You to do only buffering related stuff and leave
parallel line generation for future. Still I think, correct solution
for buffers is C (see attached example).
Good luck,
Maris.
2008/6/18, Росен Матев <r.matev@gmail.com>:
Hi,
I propose that I cancel development of "clean_parallel()" (the
function which removes loops), cause its proper behavior is not
determined now (and it might not be possible to determine it).
Instead, I'll start making function which generates "type B" lines,
which will be more useful in buffer generation. What do you think
about it?Rosen
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 18.06.2008 22:24, Росен Матев wrote:
Hi,
I propose that I cancel development of "clean_parallel()" (the
function which removes loops), cause its proper behavior is not
determined now (and it might not be possible to determine it).
Instead, I'll start making function which generates "type B" lines,
which will be more useful in buffer generation. What do you think
about it?
I still think that both A and B have merit, depending on what you want to do with the parallel lines. If it is meant to mark the the side of the road that gets cleared for installation of say phone wires, and all lines go in the direction of the traffic, then A is the way to go. If you want to make buffers then B, no sorry C (B with holes), is the correct way to go. Once you are dine with making parallel lines according to B you need to go through the original line again to find loops and for those loops punch holes.
As for the loop removal, ell if you can produce a function that can produce loopless parallel lines, then by all means drop clean_parallel(). Note that the the previous problem case also needs to work ;). I'll also ponder on the parallel line algorithm.
Another way to go would be to emulate a CNC machine and place a circular "tool" on top of the line and calculate a tangent at each corner to connect two balls on the left and right side. But that might actually be harder then going via parallel lines. I'm not sure. But it would allow for all kinds of interesting buffer shapes.
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
I'm trying to say that I can't figure out what should loopless lines
look like. The criteria currently used in clean_parallel() is bad,
cause it removes loops, for which common sense says they shouldn't be
removed. (See my triangular loop example with parallel line on the
right. Currently clean_parallel() removes the formed loop). I doubt
that there is sensible criteria for removal of loops. That's why I'll
remove the "-l" option (for now and probably forever) and then I'll
work on type B/C lines.
Rosen
On Thu, Jun 19, 2008 at 3:25 PM, Wolf Bergenheim
<wolf+grass@bergenheim.net> wrote:
On 18.06.2008 22:24, Росен Матев wrote:
Hi,
I propose that I cancel development of "clean_parallel()" (the
function which removes loops), cause its proper behavior is not
determined now (and it might not be possible to determine it).
Instead, I'll start making function which generates "type B" lines,
which will be more useful in buffer generation. What do you think
about it?I still think that both A and B have merit, depending on what you want to do
with the parallel lines. If it is meant to mark the the side of the road
that gets cleared for installation of say phone wires, and all lines go in
the direction of the traffic, then A is the way to go. If you want to make
buffers then B, no sorry C (B with holes), is the correct way to go. Once
you are dine with making parallel lines according to B you need to go
through the original line again to find loops and for those loops punch
holes.As for the loop removal, ell if you can produce a function that can produce
loopless parallel lines, then by all means drop clean_parallel(). Note that
the the previous problem case also needs to work ;). I'll also ponder on the
parallel line algorithm.Another way to go would be to emulate a CNC machine and place a circular
"tool" on top of the line and calculate a tangent at each corner to connect
two balls on the left and right side. But that might actually be harder then
going via parallel lines. I'm not sure. But it would allow for all kinds of
interesting buffer shapes.--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>