[GRASS-dev] Fwd: Re: [GRASS GIS] #2531: v.parallel/v.segment: strange output
Moritz Lennert
mlennert at club.worldonline.be
Wed Feb 11 16:13:01 PST 2015
Markus,
As you are probably the one that knows the buffer code the best: do you
have any idea about this ?
Moritz
-------- Forwarded Message --------
Subject: Re: [GRASS GIS] #2531: v.parallel/v.segment: strange output
Date: Fri, 09 Jan 2015 11:32:27 -0000
From: GRASS GIS <trac at osgeo.org>
Reply-To: grass-dev at lists.osgeo.org
To: undisclosed-recipients:;
#2531: v.parallel/v.segment: strange output
-----------------------------------+----------------------------------------
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: Vector | Version: svn-trunk
Keywords: v.parallel, v.segment | Platform: MSWindows Vista
Cpu: Unspecified |
-----------------------------------+----------------------------------------
Comment(by mlennert):
In Vect_line_parallel2 in
[http://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/Vlib/buffer2.c#L1181
lib/vector/Vlib/buffer2.c], a call to clean_parallel is commented out.
clean_parallel exists in buffer.c, not in buffer2.c. Maybe this might be a
path to a solution.
What seems to be the issue (AFAIU) is that the length of the parallel line
segments is longer than that of the original line segments, as if the
lines as projected outward. This seems to be what leads to the loops.
Don't know why such a projection is done... I'll attach a screenshot to
show what I mean.
Have you checked out the -b flag ? And possibly tried to generalize the
line before creating using v.parallel. Both might actually give you what
you are looking for ?
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2531#comment:11>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list