This sounds great. Look forward to trying this out. 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 13, 2012, at 5:15 AM, Markus Metz <[email protected]> wrote: > On Mon, Oct 8, 2012 at 6:18 PM, Moritz Lennert > <[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 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
