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 guess it's time for an enhancement ticket.
I agree. Even though I regard the output of v.net.allpairs in GRASS 6
as nearly unusable, the memory allocation error should be fixed, which
would be a separate ticket.
I'll try to find the time to write a nice reproducible bug...
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
