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

[Michael Barton]

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 <markus.metz.giswork at gmail.com>
 wrote:

> 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