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

[Markus Metz]

On Mon, Oct 8, 2012 at 6:18 PM, Moritz Lennert
<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 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