[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