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

[Markus Metz]

On Mon, Oct 15, 2012 at 4:34 PM, Michael Barton <Michael.Barton at asu.edu>wrote:

>  One thing that is confusing is that the text for both entries alayer and
> nlayer shows up as "Layer number or name" instead of the text that is
> actually in the description field "Arc layer" and "Node layer". Any idea
> why this is so?
>
>
The label for the standard option G_OPT_V_FIELD is by default set to "Layer
number or name", and the label, if set, is used as text next to the option
key. Having "Arc layer" or "Node layer" next to the key can be easily done
be making "Arc layer" or "Node layer" option labels, which should then be
done for all v.net.* modules.

Markus M

>
>
>
>
>
>
>
>
>  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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20121015/deba491a/attachment.html>