[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 mlennert):

 Replying to [comment:3 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.

 That's exactly what I meant by wrong directions: path directions, not line
 directions :-). I don't have a problem with line directions remaining as
 in the original

 >Correct paths are created with trunk r67984,5.

 Thanks, works great now !


 > There is also a new -l flag that produces a single line for each path
 with appropriate line direction.

 Nice. Just one remark: the line seems to only have a category value in
 layer 2, not in layer 1. Is that intended ? It's a bit counter-intuitive,
 especially since default display in the GUI is of layer 1 and so you don't
 see anything until you specify layer 2 in the select tab...

 The command line used (follow-up of the above example code):


 {{{
 v.net.distance -l --overwrite input=mynet output=distance_7779_7780
 from_layer=2 from_cats=7779 to_layer=2 to_cats=7780 arc_column=FT_COST
 arc_backward_column=TF_COST --o
 v.category input=distance_7779_7780 at user1 option=report
 Layer: 2
 type       count        min        max
 point          1       7779       7779
 line           1       7779       7779
 boundary       0          0          0
 centroid       0          0          0
 area           0          0          0
 face           0          0          0
 kernel         0          0          0
 all            2       7779       7779
 }}}

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