GSoC Network Analysis

Abstract: [1]

report #5

Dear List,

I have finished v.net.connectivity module this week. The module computes the vertex connectivity of a graph (minimum cardinality set of vertices separating two given sets of vertices of the graph). The module also supports "node capacities". More precisely, as the edge capacities can be specified in the min-cut problem, node capacities are used to determine vertex connectivity. To have a better idea, please read my last week report that also has a couple of nice images. [1]

Also, I have done v.net.centrality module that computes several vertex centrality measures. Namely, degree, closeness, betweenness and eigenvector measure. Similar functionality is already present in v.generalize module. However, this module is more general. Firstly, it stores the measures in the database and secondly, it also takes edge lengths/costs into the account. (v.generalize assumes edge costs to be 1). The main difference is that v.generalize computes edge centrality measures. However, with code computing vertex measures already available, it is easy to extend the module to compute edge measures as well. Here is a couple of fancy pictures: http://people.ksp.sk/~dano/grass/close.png, http://people.ksp.sk/~dano/grass/betw.png. The pictures show closeness and betweenness measures respectively. The meaning of colours should be obvious: red-"nodes in the centre according to the measure", green-"middle", blue-"boundary".

Also, I have begun to work on v.net.distance module that will be a hybrid of v.distance and v.net.path modules. The module will compute the shortest path(length as well as the path itself) along the network between a set of "to" features and every "from" feature. I hope to finish it (early) next week, as I already know about one guy awaiting the module.

For the blocking issues: uploading centrality measures into the database takes an awful lot of time as I am doing it in a very naive way... I will look more into this next week.

Finally, I apologise that this report is too late. It is already 13 minutes past midnight in my timezone...., Daniel

[1] - http://grass.osgeo.org/wiki/GSoC_Network_Analysis

report #4

Dear all,

After a break I took because of my exams, I have started working on my GSoC project. I worked mostly on the (v.net.) flow module and related issues. I have extended the module so that it is possible to specify more than one point as the source and sink. Also, the module finds a minimum cut (edges with minimum capacities separating source(s) from sink(s)) in the network. Here is a picture of this: http://people.ksp.sk/~dano/grass/mfmult.png. Red crosses are sources and green ones are sinks (maybe, it is the other way round...) Blue edges correspond to small flow, green to medium flow and red to high flow. And the yellow edges are a minimum cut.

If the capacities of all edges are the same, minimum cut corresponds to the smallest number of edges separating two sets of vertices. By constructing an appropriate graph, it is also possible to find the smallest set of vertices separating sources and sinks. I have written code that does exactly this. In the next picture, orange points separate red points from green points: http://people.ksp.sk/~dano/grass/large.png. The next two pictures show details of the previous one: http://people.ksp.sk/~dano/grass/detail1.png, http://people.ksp.sk/~dano/grass/detail2.png. For the next week, I plan to turn this code into a module as the current version is more useful for debugging than using. Also, I will extend it to handle "node capacities". And I hope I will have time to start working on another new module.

Daniel

report #3

Hi List,

This week, I implemented a module that computes the shortest path between all pairs of nodes in the graph. You can also specify which pairs you are interested in, so that the module does not have to produce the entire NxN matrix. Also, I started on network flow modules. So far, I have implemented a flow algorithm and a simple module that finds the maximum flow between two given vertices(Well, for debugging purposes, it can handle only the flow between nodes 215 and 219, so far....) Anyway, here is couple of pictures: http://people.ksp.sk/~dano/grass/mfu.png, http://people.ksp.sk/~dano/grass/mfu2.png. One cross is source, the other one is sink. Blue edges correspond to low flow, green to medium and red to high flow. I used speed limit as edge capacities. Although it is not the case in the two pictures I posted, the forward and backward capacities of an edge can be different.

For the next weeks, I plan to revise for my exams. As you may be aware, I have started two weeks earlier and so I will take a short break now.... Currently, I have no blocking issues.

See you in July!

Daniel

(What an embarrasing mistake. By July, I mean June....)

report #2

Hello everyone,

While working on the module for computing articulation points, I found a bug in the code calculating bridges. So the first real thing I did this week was some bug fixing. Also, I have updated the module for connected components so that it outputs the computed values in a more useful way (Read: now it can be used for more than just producing nice pictures to the first weak report....). Anyway, everything is kept in a nice little database table. As the first sentence suggests, I have done a module for computing articulation points in the networks. Moreover, I have implemented a module that finds a minimum spanning tree in the graph. This pictures shows both new modules in work: red crosses are articulation points, green edges form a minimum spanning tree (all edges have equal weight) http://people.ksp.sk/~dano/grass/mstap.png. In the following picture, the green edges also form a minimum spanning tree, but this time, the speed limit is used as the weight of an edge. Note that the highway in the centre is not included in the spanning tree: http://people.ksp.sk/~dano/grass/mst.png. The latest version of the code will appear shortly in the add-ons repository.

Currently, I cannot persuade the compiler to compile the library correctly. So far, it does make cause any problems as no code is used by two modules. I will look into this later next week and I will probably start working on the family of modules using max-flows algorithm as well.

Daniel

report #1

Hello list,

I have agreed with my mentor, Wolf, to start working on my GSoC project bit earlier so that I can concentrate more on the exams later. Well, earlier means last Saturday and so this is my first week report. Just a short introduction: I am Daniel, 3rd year at Oxford doing Mathematics and Computer Science and some of you may remember me as the student working on GRASS v.generalize module two years ago. My project this year is about extending GRASS network/vector functionality by writing a couple of modules. I have created a wiki page: http://grass.osgeo.org/wiki/GSoC_Network_Analysis, which contains some useful information such as this email and a link to the abstract.

Anyway, after doing boring, but essential, tasks such as downloading and compiling GRASS (I use 6.4 developer branch) I have done more interesting stuff. I wrote a module for computing weakly and strongly connected components. Using this module, I found errors in the standard North Caroline datset. At least, I think that these are errors. For example, if you zoom to [north: 232051.61663403 south: 230521.9965903 east: 640369.10332306 west: 638669.65919416] and let GRASS draw roadsmajor map for you, you get something like this: http://people.ksp.sk/~dano/grass/wcc1.jpg. (colours correspond to different components, which I obtained using my module). Or, the same map, but different location [north: 239329.55684214 south: 238882.80682937 east: 630466.77182694 west: 629997.32746966], and you have another disconnected lines: http://people.ksp.sk/~dano/grass/wcc2.jpg

Then, I have also written a module for computing bridges(edges whose removal disconnects the graph) in the network and found another, probably error. This time, it is in map "railroads". The location is [north: 195851.98992388 south: 187604.09950596 east: 669691.16599023 west: 663129.724274] and the picture is: http://people.ksp.sk/~dano/grass/railroads.jpg. Note that the lines are not connected at the point the red arrow points at. Also, it seems, but I am not completely sure, that there is something wrong with the red segment the green arrow points at. I think, that the segment is not topologically connected to the network at both ends, although, visually, it seems that it is.

Finally, here is a random picture from a module for computing bridges: http://people.ksp.sk/~dano/grass/bridges.jpg. (The data is from streets_wake map). The red edges are bridges. Strictly speaking, the blue edges are bridges as well, but they are not the type of bridge you usually look for/consider important. So I wrote another module that can identify such chains hanging on the network and remove them.

The code should appear shortly in GRASS addons repository.

That is for the last week. I am not currently stuck at anything and I plan to develop another modules over the next week. For exampe, module for computing articulation points as the algorithm is almost the same as for bridges.

Cheers, Daniel