[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:6 mlennert]:
 > Replying to [comment:5 mmetz]:
 > > Replying to [comment:4 mlennert]:
 > > > Nice. Just one remark: the line seems to only have a category value
 in layer 2, not in layer 1. Is that intended ?
 > >
 > > Not really intended, paths got all categories of their from feature.
 Changed in r67990 to match the default output of paths consisting of
 different lines.
 >
 > Works great now, thanks !
 >
 > As this is a bug, I believe that r67984, r67985 and r67990 are
 backporting candidates for grass70. At the same time they also introduce
 new functionality (line = path direction). What do you think ?

 Since this is a bugfix, and the new feature makes the output more similar
 to v.net.path (I regard it as the reference module), I agree that the
 changes should be backported.

 I have introduced another new feature: node costs are now considered, and
 closed nodes are not traversed. This new feature requires IMHO a bit more
 testing.

 5 years ago, I have added options to define arc forward and backward costs
 as well as node costs to all v.net.* modules added by the GSoC 2009
 project. Unfortunately, I did not update the underlying algorithms which
 sometimes assumed undirected graphs (e.g. v.net.distance). I am doing this
 now (sorry for being so late), which will require further testing. Quite
 interesting could be a working v.net.components module (trunk r68006)
 which now also requires directed graphs version 2 (see below). The output
 of v.net.components has been wrong ever since it has been added to GRASS.
 > >
 > > AFAICT, v.net.distance is now the only module using version 2 directed
 graphs. All other v.net.* modules use version 1 directed graphs. The
 directed graph library offers to create graphs (networks) of version 1, 2,
 and 3. Only version 1 graphs have been used and tested since 2003 within
 GRASS GIS.
 >
 > Sorry for my ignorance, but what are version 2 and 3 ?

 https://grass.osgeo.org/programming7/dglib.html

 "DGLib defines three different graph versions, version 1 supports directed
 graph with a weak concept of the edge, it can support many applications
 where one doesn't need to know about the input edges of a node (in-degree)
 and where there is no requirement to directly retrieve edges by their
 identifier but only by head/tail combinations. Version 2 adds in-degree
 support and a true edge addressing, yet supporting directed graph. Version
 3 uses the same internal representation of version 2 but activates code
 branches to support undirected graphs."

 v.net.distance needs to process input (incoming) edges for each node, not
 output (outgoing) edges. Therefore directed graphs version 2 are required.
 v.net.components processes both outgoing and incoming edges, therefore it
 also requires graphs version 2. Technically, weakly connected components
 could be determined using only GRASS vector topology (equivalent to an
 undirected graph), but then nodes could not be closed by setting nodes'
 costs to -1.

 >
 > > It is not clear to me why v.net.distance copies 'from' features to the
 output but not 'to' features. Any opinion?
 >
 > I have to admit that I had never noticed that it did this... For this is
 not necessary.

 OK.

 > I would rather see v.net.distance offer the possibility to just output
 the fcat,tcat,distance values to stdout or to file, without creating the
 path vector map (which should be optional). That way it would even more be
 a network equivalent of v.distance.
 >
 > But that's for a different ticket.

 OK.

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