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 <[email protected]<mailto:[email protected]>> wrote: On Mon, Oct 15, 2012 at 4:34 PM, Michael Barton <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: On Mon, Oct 8, 2012 at 6:18 PM, Moritz Lennert <[email protected]<mailto:[email protected]>> 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
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
