[GRASS-dev] v.net.allpairs seems broken

[Michael Barton]

This sounds like a very good idea to me.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu











On Oct 15, 2012, at 11:11 AM, Markus Metz <markus.metz.giswork at gmail.com<mailto:markus.metz.giswork at gmail.com>>
 wrote:


On Mon, Oct 15, 2012 at 4:34 PM, Michael Barton <Michael.Barton at asu.edu<mailto:Michael.Barton at asu.edu>> wrote:
One thing that is confusing is that the text for both entries alayer and nlayer shows up as "Layer number or name" instead of the text that is actually in the description field "Arc layer" and "Node layer". Any idea why this is so?


The label for the standard option G_OPT_V_FIELD is by default set to "Layer number or name", and the label, if set, is used as text next to the option key. Having "Arc layer" or "Node layer" next to the key can be easily done be making "Arc layer" or "Node layer" option labels, which should then be done for all v.net<http://v.net>.* modules.

Markus M








On Oct 13, 2012, at 5:15 AM, Markus Metz <markus.metz.giswork at gmail.com<mailto:markus.metz.giswork at gmail.com>> wrote:

On Mon, Oct 8, 2012 at 6:18 PM, Moritz Lennert
<mlennert at club.worldonline.be<mailto:mlennert at club.worldonline.be>> wrote:
On 08/10/12 18:09, Markus Metz wrote:

On Mon, Oct 8, 2012 at 5:28 PM, Moritz Lennert


In trunk, the result is a vector map of nodes with an attribute table
linked
to these nodes which provides a distance matrix across the network for
all
pairs of nodes.

I agree that this is suboptimal output. I think the following outputs
would
be interesting:

- a table with the distance matrix, but this does not have to be linked
to a
map (cf v.distance table option)


+1
I would prefer output as a matrix to a file (or stdout) with a custom
field separator instead of an attribute table. I guess (at least I
would take that route) that post-processing of that output is done
outside GRASS.


I guess that could be left to the user (e.g. table=- for stdout ?).
Sometimes it can be handy to have that table in the same database as the
vector attribute layers as you might want to use it in a view which you can
then attach back to the vector map or in another type SQL statement linked
to your mapset...



There is a bug in the current implementation of v.net.allpairs: there
are multiple entries for the same category and layer in the output
attribute table. This is not supported by GRASS.


Right. Didn't even think about that when I saw the table.



- a map with all the paths

I would guess that the code is in the v.net<http://v.net/> modules (notably v.net.path)
to
easily create a map of paths. MarkusM ?


Yes, that should be easy. I would suggest to change v.net.allpairs
such that the output contains all the paths. Each path gets its own
category, and the attribute table holds information about the start
node, end node, and cost to get from the start node to the end node.
Additionally, a matrix can be printed to file or stdout with the costs
of travelling from the start node to the end node. This matrix is not
symmetric because the cost of travelling from A to B is not
necessarily equal to the cost of travelling from B to A (one-way
streets for example).


+1, although I'm still not convinced that the matrix as a table cannot be
useful if you don't want the whole map, but only the info. But I won't make
an issue out of it, as you can use the attribute table of the map to get the
same results.

I have changed the output of v.net.allpairs in r53379 to hold the
selected nodes and all paths between them. The attribute table for the
paths has the entries cat, from_cat, to_cat, cost with cat = category
of path, from_cat and to_cat = categories of start and end point, and
cost = cost.

Printing the costs out in matrix form is not implemented, but would be
easy to add.

Markus M



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20121015/b7babcaa/attachment-0001.html>