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

[mlennert]

On 07/10/12 09:12, Michael Barton wrote:

v.net.allpairs only produces nodes. It calculates the cost of the
shortest paths between all nodes but does not create the paths. Is this
correct? Seems like it also ought to create the paths too.

In 6.4.2 I get an alloc error:

v.net.allpairs street_schools out=allpaths cats=5000-50009
ERREUR :G_calloc: unable to allocate 42020 * 4 bytes at main.c:173

Don't have the time to look into this at the moment.

In trunk I get it to work. There was an issue with many of the v.net modules that came out of GSoC: they did not distinguish between an arc and a node layer. Maybe that's the reason for the G_calloc issue.

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)
- 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 ?

I guess it's time for an enhancement ticket.

Moritz

[Markus_Metz]

On Mon, Oct 8, 2012 at 5:28 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 07/10/12 09:12, Michael Barton wrote:

v.net.allpairs only produces nodes. It calculates the cost of the
shortest paths between all nodes but does not create the paths. Is this
correct? Seems like it also ought to create the paths too.

In 6.4.2 I get an alloc error:

v.net.allpairs street_schools out=allpaths cats=5000-50009
ERREUR :G_calloc: unable to allocate 42020 * 4 bytes at main.c:173

Don't have the time to look into this at the moment.

In trunk I get it to work. There was an issue with many of the v.net modules
that came out of GSoC: they did not distinguish between an arc and a node
layer. Maybe that's the reason for the G_calloc issue.

I have fixed most of the new v.net.* modules trunk to support
different arc and node layers, i.e. to work with the output of v.net
which creates networks suitable for GRASS network analysis. I do not
know an easy way to create vectors in GRASS 6 to work with the new
network analysis modules.

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.

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.

- 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).

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.

Markus M

[mlennert]

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

[Markus_Metz]

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

[cmbarton]

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@gmail.com>
wrote:

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

[cmbarton]

I just tried v.net.allpairs and it is really nice now. Thanks much.

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?

I’ve attached a saved display for the results of v.net.allpairs with the streets_wake map (nc_08 demo data) for the arcs and highschools for the nodes.

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@gmail.com> wrote:

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

[Markus_Metz]

On Mon, Oct 15, 2012 at 4:34 PM, Michael Barton <Michael.Barton@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@gmail.com> wrote:

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

[cmbarton]

This sounds like a very good idea to me.

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 15, 2012, at 11:11 AM, Markus Metz <markus.metz.giswork@gmail.com>
wrote:

On Mon, Oct 15, 2012 at 4:34 PM, Michael Barton <Michael.Barton@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@gmail.com> wrote:

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

[mlennert]

On 08/10/12 18:18, Moritz Lennert wrote:

On 08/10/12 18:09, Markus Metz wrote:

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...

Well, actually, the error only appears in 6.4.2, but not in 6.4 release branch. Here's what I did:

v.category schools_wake out=schools op=sum cat=50000
v.net streets_wake points=schools op=connect thresh=200 out=network nlayer=1
v.net.allpairs network cats=50000-50167 out=allpairs

Works fine relase branch, but in 6.4.2 I get:

Flattening the graph...
Graph was built
ERROR: G_calloc: unable to allocate 42122 * 4 bytes at main.c:173

But, not worth filing a ticket as it already seems solved.

However, we should probably put a hint into the v.net man page and/or the relevant modules man pages that all modules that were coded by Daniel do not differentiate alayer and nlayer in the grass6 line and so you have to differentiate them by cat numbers in the map.

Or we decide to break the rule to not change options and backport the alayer/nlayer patches from grass 7 to grass 6, as it is such an obvious design flaw compared to the general logic of the v.net.* modules.

What do you think ?

Moritz

[cmbarton]

Fixing this makes the module usable. The flaw is near to a bug.

+1

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 16, 2012, at 4:12 AM, Moritz Lennert <mlennert@club.worldonline.be>
wrote:

Or we decide to break the rule to not change options and backport the alayer/nlayer patches from grass 7 to grass 6, as it is such an obvious design flaw compared to the general logic of the v.net.* modules.

What do you think ?

[mlennert]

On 16/10/12 15:34, Michael Barton wrote:

Fixing this makes the module usable. The flaw is near to a bug.

Well, you can use the module as-is. You just have to make sure that
nodes and arcs have different cat values, e.g.:

#check cat values in arcs layer (streets_wake here):
v.category streets_waks op=report

#take the existing cat values of the points in schools_wake and add 50000 (because the cat values in streets_wake go up to just under 50000)
v.category schools_wake out=schools op=sum cat=50000

#now link the nodes with their new categories to the arcs
v.net streets_wake points=schools op=connect thresh=200 out=network nlayer=1

#then launch your analysis indicating the cat values of the points
v.net.allpairs network cats=50000-50167 out=allpairs

So it is possible, but should be documented.

I do agree though that it's a real PINA compared to the simple two-layer system in other modules.

Moritz

+1

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 16, 2012, at 4:12 AM, Moritz
Lennert<mlennert@club.worldonline.be> wrote:

Or we decide to break the rule to not change options and backport
the alayer/nlayer patches from grass 7 to grass 6, as it is such an
obvious design flaw compared to the general logic of the v.net.*
modules.

What do you think ?

[Markus_Metz]

On Wed, Oct 17, 2012 at 10:52 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 16/10/12 15:34, Michael Barton wrote:

Fixing this makes the module usable. The flaw is near to a bug.

Well, you can use the module as-is. You just have to make sure that
nodes and arcs have different cat values, e.g.:

#check cat values in arcs layer (streets_wake here):
v.category streets_waks op=report

#take the existing cat values of the points in schools_wake and add 50000
(because the cat values in streets_wake go up to just under 50000)

v.category schools_wake out=schools op=sum cat=50000

#now link the nodes with their new categories to the arcs

v.net streets_wake points=schools op=connect thresh=200 out=network nlayer=1

#then launch your analysis indicating the cat values of the points
v.net.allpairs network cats=50000-50167 out=allpairs

I would prefer to update the documentation for GRASS 6. I started
backporting the changes to the v.net.* modules coming from the GSoC
project to my local copy of devbr6, but the changes are too
fundamental. IOW I did not yet find the time to do proper backporting
to GRASS 6, which must obviously include proper testing. Therefore I
would suggest to update the manuals for GRASS 6 with your example and
equivalent for the other affected modules.

In this case, if someone (probably me) manages to properly backport
the changes in trunk I would support the exception from the rule to
break script compatibility. These modules have been added only
recently anyway, and do not conform to GRASS vector network analysis
standards.

So it is possible, but should be documented.

I do agree though that it's a real PINA compared to the simple two-layer
system in other modules.

I guess you mean PIT* (your choice).

Markus M

Moritz

+1

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 16, 2012, at 4:12 AM, Moritz
Lennert<mlennert@club.worldonline.be> wrote:

Or we decide to break the rule to not change options and backport
the alayer/nlayer patches from grass 7 to grass 6, as it is such an
obvious design flaw compared to the general logic of the v.net.*
modules.

What do you think ?

[mlennert]

On 17/10/12 22:42, Markus Metz wrote:

On Wed, Oct 17, 2012 at 10:52 AM, Moritz Lennert

I would prefer to update the documentation for GRASS 6. I started
backporting the changes to the v.net.* modules coming from the GSoC
project to my local copy of devbr6, but the changes are too
fundamental. IOW I did not yet find the time to do proper backporting
to GRASS 6, which must obviously include proper testing. Therefore I
would suggest to update the manuals for GRASS 6 with your example and
equivalent for the other affected modules.

Ok, I'm a bit short on time right now, but I'll try to do this little by little in the next days.

I do agree though that it's a real PINA compared to the simple two-layer
system in other modules.

I guess you mean PIT* (your choice).

Obviously

Moritz

[mlennert]

On 18/10/12 10:08, Moritz Lennert wrote:

On 17/10/12 22:42, Markus Metz wrote:

On Wed, Oct 17, 2012 at 10:52 AM, Moritz Lennert

I would prefer to update the documentation for GRASS 6. I started
backporting the changes to the v.net.* modules coming from the GSoC
project to my local copy of devbr6, but the changes are too
fundamental. IOW I did not yet find the time to do proper backporting
to GRASS 6, which must obviously include proper testing. Therefore I
would suggest to update the manuals for GRASS 6 with your example and
equivalent for the other affected modules.

Ok, I'm a bit short on time right now, but I'll try to do this little by
little in the next days.

Done for v.net.allpairs. For the other v.net.* modules from Daniel, I'll have to look at each in detail to understand functioning and whether there is a need for such explanation.

Moritz

[Markus_Metz]

On Mon, Oct 15, 2012 at 5:11 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Mon, Oct 15, 2012 at 4:34 PM, Michael Barton <Michael.Barton@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.

Done for trunk in r53630.

Markus M

[cmbarton]

Excellent!

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
    http://www.public.asu.edu/~cmbarton

On Oct 31, 2012, at 2:29 PM, Markus Metz <markus.metz.giswork@gmail.com>
wrote:

On Mon, Oct 15, 2012 at 5:11 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Mon, Oct 15, 2012 at 4:34 PM, Michael Barton <Michael.Barton@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.

Done for trunk in r53630.

Markus M