[GRASS-dev] [GRASS GIS] #2936: v.net.distance: wrong directions in one-way streets
trac at osgeo.org
Sat Mar 5 15:14:33 PST 2016
#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
> 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
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
> Sorry for my ignorance, but what are version 2 and 3 ?
"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
> 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.
Ticket URL: <https://trac.osgeo.org/grass/ticket/2936#comment:7>
GRASS GIS <https://grass.osgeo.org>
More information about the grass-dev