[GRASS-dev] [GRASS GIS] #2936: v.net.distance: wrong directions in one-way streets

[GRASS GIS]

#2936: v.net.distance: wrong directions in one-way streets
-------------------------+-------------------------------------------------
  Reporter:  mlennert    |      Owner:  grass-dev@…
      Type:  defect      |     Status:  new
  Priority:  normal      |  Milestone:  7.0.4
 Component:  Vector      |    Version:  svn-trunk
Resolution:              |   Keywords:  v.net.distance network one-way
       CPU:              |  direction
  Unspecified            |   Platform:  Unspecified
-------------------------+-------------------------------------------------

Comment (by mmetz):

 Replying to [comment:2 mlennert]:
 > Replying to [comment:1 mmetz]:
 > > Manual:
 > >
 > > "Each path consist of several lines. If a line is on the shortest path
 from a point then the category of this point is assigned to the line. Note
 that every line may contain more than one category value since a single
 line may be on the shortest path for more than one from feature."
 > >
 > > That means lines are copied directly from input to output, line
 directions are not adjusted and lines are not merged to unique paths for
 each `from` category.
 > >
 > > Unfortunately, the paths as reported by v.net.distance (irrespective
 of the direction) are wrong: the shortest path from 7779 to 7780 should
 take the long route, and the shortest path from 7780 to 7779 should take
 the short route. Fixing this bug would require a new function in
 lib/vector/neta. Hopefully the dglib interface allows for an easy solution
 to provide an inverse to
 lib/vector/neta/path.c:NetA_distance_from_points().
 > >
 > > This ticket should be closed and a new ticket should be opened that
 v.net.distance calculates paths in reverse (from to to from instead of
 from from to to).
 >
 >
 > I don't understand why we need a new ticket. Maybe my formulation was a
 bit awkward, but the problem reported in the ticket is exactly that
 v.net.distance calculates paths in reverse...

 I understand. Just for emphasis, the output line directions are not wrong
 because they are not meant to be in accordance with the path directions.
 The paths themselves were wrong in case of one-way streets. Correct paths
 are created with trunk r67984,5. There is also a new -l flag that produces
 a single line for each path with appropriate line direction. The vector
 libs needed some modification in order to fix v.net.distance.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2936#comment:3>
GRASS GIS <https://grass.osgeo.org>