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

[Moritz Lennert]

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