[GRASS-dev] vector network questions

Why does mouse querying of a vector network return “nothing found”? There is attribute data in the associated attribute table. (GRASS 7 svn, on Mac).

I thought I’d go over this in class tomorrow, but I can’t follow the manual. It is not clear how to transform a vector map (e.g., roadsmajor of the nc_08 data set) into a network. Run v.net with nodes? connect? arcs? some combination?

v.net path instructions seem to date from earliest GRASS 6 days and are for linux based terminal commands, pipe and stdin. It is not clear how to even enter start and end points. Or perhaps the interactive points entry control is broken. I can’t tell.

I’m interested to know how this works. Perhaps I can work with someone to update the docs.

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 05/10/12 07:37, Michael Barton wrote:

Why does mouse querying of a vector network return "nothing found"?
There is attribute data in the associated attribute table. (GRASS 7 svn,
on Mac).

A vector network is just normal vector data, so if you get a "nothing found" then there is a problem.

I thought I'd go over this in class tomorrow, but I can't follow the
manual. It is not clear how to transform a vector map (e.g., roadsmajor
of the nc_08 data set) into a network. Run v.net <http://v.net> with
nodes? connect? arcs? some combination?

The way the v.net.* modules are implemented, in order to be able to do network analysis with a network and specific nodes, you have to run v.net with operation connect (and a relevant threshold), connecting the nodes you are interested in with the network in a topologically correct way.

I guess it might be worth to develop some scripted fronted which allows you to just provide separate layers for network and nodes and the network analysis you want to do, and then the script does the v.net part for you. But for now you have to do this first. And from a pedagogical point of view I find it important to show the need for topologically correct data.

v.net <http://v.net> path instructions seem to date from earliest GRASS
6 days and are for linux based terminal commands, pipe and stdin. It is
not clear how to even enter start and end points. Or perhaps the
interactive points entry control is broken. I can't tell.

I have no problems entering points interactively in Debian Squeeze with 6.4.2.

Here's an example with the NC data set:

v.net input=streets_wake@PERMANENT points=schools_wake@PERMANENT output=streets_schools operation=connect thresh=100

Interactive use of v.net.path in GUI gives following command line:
v.net.path --overwrite input=streets_schools@user1 output=paths file=/home/mlennert/GRASS/DATA/nc_spm_08/user1/.tmp/geog-pc40/30065.1
(I entered the following into the interactive text field:

1 1 167
2 3 166
3 656688 234205 629030 217772

The same could be put into a text file called with the file= option. Often a good idea for students so that you can debug...).

Screenshot of the different GUI windows of the operation:

http://164.15.12.207/grass/v_net_path.png

I'm interested to know how this works. Perhaps I can work with someone
to update the docs.

At this stage, I don't really understand what is missing in the docs. Screenshots of GUI usage ?

Moritz

Hi Moritz,

I did some tests this evening after a long day over a beer (1 beer makes complex tasks easier, but more can make them more complex).

1. v.net.cent works once I realized that "between" was a reserved word. Thanks. I've changed the bug report to an enhancement request for better error messages.

2. The lack of ability to query a network vector is a bug I think. I'm guessing it's in v.what, but am not sure. Can you test to see if you cannot query it either?

3. v.net.path works fine with your example, but I still don't know what the format should be when using cat values. Why 2 integers before the cat value? Of course, it is very difficult to ID start and stop points if you cannot query the network vector. That aside, your example is much easier to follow than the dated Spearfish one that is currently in the docs for v.net.path.

4. I'm still not sure of the proper workflow to create a network from an existing vector of lines--like a road or stream network--assuming that I'm happy to use nodes at intersections in the original vector map as network nodes.

Thanks again for your help
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 5, 2012, at 12:30 AM, Moritz Lennert <mlennert@club.worldonline.be>
wrote:

On 05/10/12 07:37, Michael Barton wrote:

Why does mouse querying of a vector network return "nothing found"?
There is attribute data in the associated attribute table. (GRASS 7 svn,
on Mac).

A vector network is just normal vector data, so if you get a "nothing found" then there is a problem.

I thought I'd go over this in class tomorrow, but I can't follow the
manual. It is not clear how to transform a vector map (e.g., roadsmajor
of the nc_08 data set) into a network. Run v.net <http://v.net> with
nodes? connect? arcs? some combination?

The way the v.net.* modules are implemented, in order to be able to do network analysis with a network and specific nodes, you have to run v.net with operation connect (and a relevant threshold), connecting the nodes you are interested in with the network in a topologically correct way.

I guess it might be worth to develop some scripted fronted which allows you to just provide separate layers for network and nodes and the network analysis you want to do, and then the script does the v.net part for you. But for now you have to do this first. And from a pedagogical point of view I find it important to show the need for topologically correct data.

v.net <http://v.net> path instructions seem to date from earliest GRASS
6 days and are for linux based terminal commands, pipe and stdin. It is
not clear how to even enter start and end points. Or perhaps the
interactive points entry control is broken. I can't tell.

I have no problems entering points interactively in Debian Squeeze with 6.4.2.

Here's an example with the NC data set:

v.net input=streets_wake@PERMANENT points=schools_wake@PERMANENT output=streets_schools operation=connect thresh=100

Interactive use of v.net.path in GUI gives following command line:
v.net.path --overwrite input=streets_schools@user1 output=paths file=/home/mlennert/GRASS/DATA/nc_spm_08/user1/.tmp/geog-pc40/30065.1
(I entered the following into the interactive text field:

1 1 167
2 3 166
3 656688 234205 629030 217772

The same could be put into a text file called with the file= option. Often a good idea for students so that you can debug...).

Attached a screenshot of the different GUI windows of the operation.

I'm interested to know how this works. Perhaps I can work with someone
to update the docs.

At this stage, I don't really understand what is missing in the docs. Screenshots of GUI usage ?

Moritz
<v_net_path.png>

Hi both, all,

it would be nice to develop
http://grass.osgeo.org/wiki/Vector_network_analysis

further with updated screenshots and especially more general notes
about the workflow..

Markus

On 06/10/12 03:35, Michael Barton wrote:

2. The lack of ability to query a network vector is a bug I think.
I'm guessing it's in v.what, but am not sure. Can you test to see if
you cannot query it either?

I'll test when I get back to the office on Monday, but as a network vector is not different in essence from any other vector, either you can reproduce this querying issue with all vectors, or I would need much more precise info about what you are doing and what exactly is not working.

3. v.net.path works fine with your example, but I still don't know
what the format should be when using cat values. Why 2 integers
before the cat value?

As the man page indicates, you have the choice of two formats to feed the module the info about the path you want.

1) When you want to use nodes with cat values as start and end point, just indicate the cat of each.

id start_cat end_cat

2) When you want to use coordinates as start and end point, you indicate x,y of start then x,y of end

id start_x start_y end_x end_y

The 'id' is an arbitrary cat value that you attribute to the resulting path.

Each line represents one path going from its start to its end through the network.

4. I'm still not sure of the proper workflow to create a network from
an existing vector of lines--like a road or stream network--assuming
that I'm happy to use nodes at intersections in the original vector
map as network nodes.

If you just want to use the intersections of the network, then v.net operation=nodes is what you need.
If you want to connect points to a network (example: points representing schools to the network of streets) then you have to use operation=connect.

The reasoning behind the second is that network analysis needs a topologically clean network, meaning that if you want to find the path form one node to another, these nodes have to be connected to the network for this to work. operation=connect does exactly that. If display your network after connection with nodes, displaying both the network on layer 1 and the nodes on layer 2, and you zoom very close to one of the nodes you connected, you will see that there is now a short line segment connecting the node to the nearest line of the network.

Moritz

See below.

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Oct 6, 2012, at 1:52 PM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 06/10/12 03:35, Michael Barton wrote:

2. The lack of ability to query a network vector is a bug I think.
I'm guessing it's in v.what, but am not sure. Can you test to see if
you cannot query it either?

I'll test when I get back to the office on Monday, but as a network vector is not different in essence from any other vector, either you can reproduce this querying issue with all vectors, or I would need much more precise info about what you are doing and what exactly is not working.

I did this and filed a bug report.

3. v.net.path works fine with your example, but I still don't know
what the format should be when using cat values. Why 2 integers
before the cat value?

As the man page indicates, you have the choice of two formats to feed the module the info about the path you want.

1) When you want to use nodes with cat values as start and end point, just indicate the cat of each.

id start_cat end_cat

2) When you want to use coordinates as start and end point, you indicate x,y of start then x,y of end

id start_x start_y end_x end_y

The 'id' is an arbitrary cat value that you attribute to the resulting path.

Each line represents one path going from its start to its end through the network.

Thanks. I don't know why this was not working. But it is now.

4. I'm still not sure of the proper workflow to create a network from
an existing vector of lines--like a road or stream network--assuming
that I'm happy to use nodes at intersections in the original vector
map as network nodes.

If you just want to use the intersections of the network, then v.net operation=nodes is what you need.
If you want to connect points to a network (example: points representing schools to the network of streets) then you have to use operation=connect.

The reasoning behind the second is that network analysis needs a topologically clean network, meaning that if you want to find the path form one node to another, these nodes have to be connected to the network for this to work. operation=connect does exactly that. If display your network after connection with nodes, displaying both the network on layer 1 and the nodes on layer 2, and you zoom very close to one of the nodes you connected, you will see that there is now a short line segment connecting the node to the nearest line of the network.

This is a BIG help for this key module. NOW I understand how it is supposed to work.

Michael

Moritz

First of all, thanks for using GRASS network analysis tools in a
course, Michael!

I have updated the manual for v.net, explaining the different
operation options in some more detail.

I have updated the manuals of many of the v.net.* modules last year,
testing and if necessary fixing bugs in the v.net.* modules.
Apparently, my updates to the manuals were not sufficient for you. You
object to the use of stdin pipes | which AFAICT work on Linux, Mac,
and Windows. We can update the manuals to not use stdin pipes such
that the creation of a text file in your favourite text editor is
suggested first, then use this file as input for the modules affected.

An IMHO more serious issue for GRASS 7 is the need to change the
manuals to use examples from the North Carolina sample dataset, not
from the spearfish dataset. But using e.g. streets_wake from the North
Carolina sample dataset can cause out-of-memory errors in some v.net.*
modules, for which there is no easy fix. The vector map roadsmajor is
OTOH too simple to demonstrate GRASS vector network capabilities. We
would need something like roadsmajor for all of North Carolina.

Markus M

Markus, Michael

I have the new streets data for wake ready, updated based on 2011 data - I will post the location for grass7 with the new streets later today,
you can try it out, if there are still problems there are some other versions that I can try,

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

On Oct 10, 2012, at 3:04 PM, Markus Metz wrote:

First of all, thanks for using GRASS network analysis tools in a
course, Michael!

I have updated the manual for v.net, explaining the different
operation options in some more detail.

I have updated the manuals of many of the v.net.* modules last year,
testing and if necessary fixing bugs in the v.net.* modules.
Apparently, my updates to the manuals were not sufficient for you. You
object to the use of stdin pipes | which AFAICT work on Linux, Mac,
and Windows. We can update the manuals to not use stdin pipes such
that the creation of a text file in your favourite text editor is
suggested first, then use this file as input for the modules affected.

An IMHO more serious issue for GRASS 7 is the need to change the
manuals to use examples from the North Carolina sample dataset, not
from the spearfish dataset. But using e.g. streets_wake from the North
Carolina sample dataset can cause out-of-memory errors in some v.net.*
modules, for which there is no easy fix. The vector map roadsmajor is
OTOH too simple to demonstrate GRASS vector network capabilities. We
would need something like roadsmajor for all of North Carolina.

Markus M
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Markus,

Thanks. It is good that you did this. When teaching it, however, is when I can really find out what is more and less understandable. I'm trying to make some additional suggested enhancements to the documentation to make this complex but useful set of modules more accessible. I'll copy you along with Moritz and Markus.

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 10, 2012, at 12:04 PM, Markus Metz <markus.metz.giswork@gmail.com>
wrote:

First of all, thanks for using GRASS network analysis tools in a
course, Michael!

I have updated the manual for v.net, explaining the different
operation options in some more detail.

I have updated the manuals of many of the v.net.* modules last year,
testing and if necessary fixing bugs in the v.net.* modules.
Apparently, my updates to the manuals were not sufficient for you. You
object to the use of stdin pipes | which AFAICT work on Linux, Mac,
and Windows. We can update the manuals to not use stdin pipes such
that the creation of a text file in your favourite text editor is
suggested first, then use this file as input for the modules affected.

An IMHO more serious issue for GRASS 7 is the need to change the
manuals to use examples from the North Carolina sample dataset, not
from the spearfish dataset. But using e.g. streets_wake from the North
Carolina sample dataset can cause out-of-memory errors in some v.net.*
modules, for which there is no easy fix. The vector map roadsmajor is
OTOH too simple to demonstrate GRASS vector network capabilities. We
would need something like roadsmajor for all of North Carolina.

Markus M

I have posted a grass7 location for what should eventually become a new baseline NC data set
http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat/loc_ncarolina_spm_base0.2.zip
it has easy to understand names for basic raster and vector map layers and the roadsmajor
and streets data are updated based on 2011 data provided by Wake county. Please let me know
if these street data still have problems, there are other versions of this data set available, e.g. for LRS
applications etc.

The more complex data available in the current nc_spm_08, such as different types of DEMs and elevation point data,
landsat, and any other more specialized or complex data will be
provided as separate mapsets (distributed separately or in a NC-complete location).

This is very much work in progress with a long TODO list (e.g. incorporation of metadata)
aimed to be ready for grass7 release, but feedback is always appreciated.

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

On Oct 10, 2012, at 6:25 PM, Michael Barton wrote:

Markus,

Thanks. It is good that you did this. When teaching it, however, is when I can really find out what is more and less understandable. I'm trying to make some additional suggested enhancements to the documentation to make this complex but useful set of modules more accessible. I'll copy you along with Moritz and Markus.

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 10, 2012, at 12:04 PM, Markus Metz <markus.metz.giswork@gmail.com>
wrote:

First of all, thanks for using GRASS network analysis tools in a
course, Michael!

I have updated the manual for v.net, explaining the different
operation options in some more detail.

I have updated the manuals of many of the v.net.* modules last year,
testing and if necessary fixing bugs in the v.net.* modules.
Apparently, my updates to the manuals were not sufficient for you. You
object to the use of stdin pipes | which AFAICT work on Linux, Mac,
and Windows. We can update the manuals to not use stdin pipes such
that the creation of a text file in your favourite text editor is
suggested first, then use this file as input for the modules affected.

An IMHO more serious issue for GRASS 7 is the need to change the
manuals to use examples from the North Carolina sample dataset, not
from the spearfish dataset. But using e.g. streets_wake from the North
Carolina sample dataset can cause out-of-memory errors in some v.net.*
modules, for which there is no easy fix. The vector map roadsmajor is
OTOH too simple to demonstrate GRASS vector network capabilities. We
would need something like roadsmajor for all of North Carolina.

Markus M

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Thanks Helena. Nothing wrong with the current street data. It is v.net.steiner that has a problem.

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 10, 2012, at 4:43 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

I have posted a grass7 location for what should eventually become a new baseline NC data set
http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat/loc_ncarolina_spm_base0.2.zip
it has easy to understand names for basic raster and vector map layers and the roadsmajor
and streets data are updated based on 2011 data provided by Wake county. Please let me know
if these street data still have problems, there are other versions of this data set available, e.g. for LRS
applications etc.

The more complex data available in the current nc_spm_08, such as different types of DEMs and elevation point data,
landsat, and any other more specialized or complex data will be
provided as separate mapsets (distributed separately or in a NC-complete location).

This is very much work in progress with a long TODO list (e.g. incorporation of metadata)
aimed to be ready for grass7 release, but feedback is always appreciated.

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

On Oct 10, 2012, at 6:25 PM, Michael Barton wrote:

Markus,

Thanks. It is good that you did this. When teaching it, however, is when I can really find out what is more and less understandable. I'm trying to make some additional suggested enhancements to the documentation to make this complex but useful set of modules more accessible. I'll copy you along with Moritz and Markus.

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 10, 2012, at 12:04 PM, Markus Metz <markus.metz.giswork@gmail.com>
wrote:

First of all, thanks for using GRASS network analysis tools in a
course, Michael!

I have updated the manual for v.net, explaining the different
operation options in some more detail.

I have updated the manuals of many of the v.net.* modules last year,
testing and if necessary fixing bugs in the v.net.* modules.
Apparently, my updates to the manuals were not sufficient for you. You
object to the use of stdin pipes | which AFAICT work on Linux, Mac,
and Windows. We can update the manuals to not use stdin pipes such
that the creation of a text file in your favourite text editor is
suggested first, then use this file as input for the modules affected.

An IMHO more serious issue for GRASS 7 is the need to change the
manuals to use examples from the North Carolina sample dataset, not
from the spearfish dataset. But using e.g. streets_wake from the North
Carolina sample dataset can cause out-of-memory errors in some v.net.*
modules, for which there is no easy fix. The vector map roadsmajor is
OTOH too simple to demonstrate GRASS vector network capabilities. We
would need something like roadsmajor for all of North Carolina.

Markus M

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
grass-dev Info Page