[GRASS-dev] Network Analysis

[Benjamin Ducke]

I think this should go at least into 6.5.svn for now.
We should also think about including Daniel's contribution
in 6.4.1.

It seems misplaced in the add-ons repository as it
covers some core functionality (and would go nicely
with the other v.net.* modules already in base).

If there are no major concerns, I will integrate the
code into 6.5 svn. But I don't know enough about 
the changes in the vector architecture for GRASS 7,
so someone else would need to sync with that branch
(or provide me with some information about the most
important things to keep in mind when porting vector
code to version 7).

In any case, Daniel, can you please put an entry with
a description on the add-ons Wiki page? Right now it
is hard to find your code.

Ben

Daniel Bundala wrote:
> Hello everyone,
> 
> during the past few months I worked on a Google Summer of Code project
> to extend GRASS network functionality. I sent a final summary report
> to OSGeo GSoC mailing list. Since there are people not subscribed to
> that mailing list who might be interested in the project, I was asked
> to sent the report to this list and stress the paragraph on inclusion
> into the main GRASS....
> 
> 
> 
> 
> The goal of my project, which I have successfully accomplished, was to
> implement modules for network analysis. This includes basic methods
> such as: strongly and weakly connected components, minimum spanning
> trees, bridges and articulation points as well as more complicated and
> advanced tools for calculating maximum flow, minimum cut or
> k-connectivity in a network. There is also a bunch of modules finding
> shortest paths in a network. One module computes all-pairs shortest
> paths, another finds the shortest paths between nodes and a given set
> of features and, finally, there is a module that finds fastest paths
> using timetables.
> All module follow standard GRASS conventions. This holds both for the
> code and user interface. I also tried to make the modules as flexible
> as possible -- each of them accepts a wide range of parameters, which
> can alter the behaviour. Moreover, the algorithms are separated from
> the modules and stored in a library. An effect of this is that the
> modules are mostly straightforward (only exception is v.net.timetable)
> and consist only of reading the input, calling a few library functions
> and writing an appropriate output. Another advantage of this approach
> is that the “core functionality” can be reused in other modules. Much
> more about the modules (a lot of pictures and link to code) can be
> found at mi wiki: http://grass.osgeo.org/wiki/GSoC_Network_Analysis.
> 
> I have learnt a lot about GRASS and its vector architecture however
> this was my second summer working on vector modules. This was the
> first time I really had to work with attributes data and so I have
> learnt a lot about the data management. At the beginning, I found the
> system with many layers and multiple categories a bit complicated but
> in the process of developing the modules I have discovered its
> expressiveness and enormous power.
> 
> At the moment, my code is stored in add-ons repository. I already know
> about several people using the modules for their work and I hope that
> the modules will eventually be integrated into the main distribution
> and bring eternal joy to all GRASS users.
> 
> Finally, I want to thank my mentor (Wolf Bergenheim), OSGEO project
> coordinator (Wolf Bergenheim) and the whole GRASS, OSGeo and Google
> Summer of Code community for support, T-shirts and for doing a
> wonderful job! Thanks!
> Daniel
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 
> 


-- 
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke at oxfordarch.co.uk




------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.