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
