[GRASS-dev] Google Summer Of Code Project

GRASS GIS GRASS GIS developer
1

Hello everyone, my name is Maximilian Maldacker and I’m currently a student in Imperial College London studying Mathematics and Computer Science. My project on “Shortest path in free (vector) space avoiding obstacles module in GRASS” was select by Google Summer of Code and I’m looking forward to it :-). I actually start on the 28th of May but I thought I’d introduce my self before and get involved with the community.

I have a few question concerning the development of the module. I see modules are organized in several folders and I thought I can create a new folder in the display folder named d.path_obstacles or something similar. Is it sufficient to create a new folder with a Makefile inside and a few *.c files to make a new module and will it be recognized by the command line?
The plan for now is to develop a module similar to the d.path one except it will start with a vector space containing obstacles ( i.e. polygons ) and it will construct a visibility graph out of it and compute the shortest path between two given points. Should the visibility graph construction algorithm be added to the Directed Graph Library?
What is the best way to test my code? Should I keep a fresh copy of GRASS on my computer, modify/create files, compile everything and test it using the spearfish example? Or is there another way?

Thank you for your help and I’m looking forward to help develop GRASS.

2

As most of you probably know I'm going to work as mentor for Maximilian
during the summer, but most (if not all) of the technical discussion is
going to take place here on this list, and we'd greatly appreciate any
comments and feedback you have.

On 17.04.2007 11:18, maximilian maldacker wrote:

I have a few question concerning the development of the module. I see
modules are organized in several folders and I thought I can create a
new folder in the display folder named d.path_obstacles or something
similar.

I'd recommend using a period, like
d.path.obstacles

Do we have any module naming conventions?

Is it sufficient to create a new folder with a Makefile inside
and a few *.c files to make a new module and will it be recognized by
the command line?

You can copy the makefile from another module, like d.path, and modify
it to suit your needs, or copy the example Makefile, and modify that.
The makefiles are set up so that they compile all C files into a module.

The plan for now is to develop a module similar to the d.path one except
it will start with a vector space containing obstacles ( i.e. polygons )
and it will construct a visibility graph out of it and compute the
shortest path between two given points. Should the visibility graph
construction algorithm be added to the Directed Graph Library?

I don't really see it being used anywhere else, so I'd just start by
putting it in a file of it's own, and developing it separately from the
module, so it can be integrated into the Directed Graph Library later,
if we choose to do that. Anybody else have views on this?

What is the best way to test my code? Should I keep a fresh copy of
GRASS on my computer, modify/create files, compile everything and test
it using the spearfish example? Or is there another way?

I only have the CVS version checked out. I know others have multiple
versions installed for testing, but I'd say it should be enough for you
to have only the CVS copy checked out. Spearfish data could be used, or
then you can make your own, or perhaps someone has a suitable data set,
like showing buildings in an area?

Thank you for your help and I'm looking forward to help develop GRASS.

Welcome, welcome. I think it will be an interesting summer (of code ;))

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

3

Wolf Bergenheim wrote:

As most of you probably know I'm going to work as mentor for Maximilian
during the summer, but most (if not all) of the technical discussion is
going to take place here on this list, and we'd greatly appreciate any
comments and feedback you have.

On 17.04.2007 11:18, maximilian maldacker wrote:

I have a few question concerning the development of the module. I see
modules are organized in several folders and I thought I can create a
new folder in the display folder named d.path_obstacles or something
similar.

I'd recommend using a period, like
d.path.obstacles

This implies that it's going to be a module that makes use of the
original GRASS display architecture in the style of d.path.
May I suggest at least creating a non-interactive, display-independent
version that simply outputs the path to a new vector map?
Sth. like v.path.obstacles.
This way we'll be able to make the contribution more portable, e.g.
for use with QGIS and GRASS under Windows.

Do we have any module naming conventions?

Is it sufficient to create a new folder with a Makefile inside
and a few *.c files to make a new module and will it be recognized by
the command line?

You can copy the makefile from another module, like d.path, and modify
it to suit your needs, or copy the example Makefile, and modify that.
The makefiles are set up so that they compile all C files into a module.

The plan for now is to develop a module similar to the d.path one except
it will start with a vector space containing obstacles ( i.e. polygons )
and it will construct a visibility graph out of it and compute the
shortest path between two given points. Should the visibility graph
construction algorithm be added to the Directed Graph Library?

I don't really see it being used anywhere else, so I'd just start by
putting it in a file of it's own, and developing it separately from the
module, so it can be integrated into the Directed Graph Library later,
if we choose to do that. Anybody else have views on this?

What is the best way to test my code? Should I keep a fresh copy of
GRASS on my computer, modify/create files, compile everything and test
it using the spearfish example? Or is there another way?

I only have the CVS version checked out. I know others have multiple
versions installed for testing, but I'd say it should be enough for you
to have only the CVS copy checked out. Spearfish data could be used, or
then you can make your own, or perhaps someone has a suitable data set,
like showing buildings in an area?

Thank you for your help and I'm looking forward to help develop GRASS.

Welcome, welcome. I think it will be an interesting summer (of code ;))

--Wolf

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

4

On 17.04.2007 16:46, Benjamin Ducke wrote:

This implies that it's going to be a module that makes use of the
original GRASS display architecture in the style of d.path.
May I suggest at least creating a non-interactive, display-independent
version that simply outputs the path to a new vector map?
Sth. like v.path.obstacles.
This way we'll be able to make the contribution more portable, e.g.
for use with QGIS and GRASS under Windows.

Right. I agree with you Benjamin. it should be a non-interactive module,
and output should be a vector map showing the shortest path. I also
think that maybe it could optionally take multiple start/end points just
like r.path does.

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

5

On 17/04/07 16:12, Wolf Bergenheim wrote:

On 17.04.2007 16:46, Benjamin Ducke wrote:

This implies that it's going to be a module that makes use of the
original GRASS display architecture in the style of d.path.
May I suggest at least creating a non-interactive, display-independent
version that simply outputs the path to a new vector map?
Sth. like v.path.obstacles.
This way we'll be able to make the contribution more portable, e.g.
for use with QGIS and GRASS under Windows.

Right. I agree with you Benjamin. it should be a non-interactive module,
and output should be a vector map showing the shortest path. I also
think that maybe it could optionally take multiple start/end points just
like r.path does.

Or like v.net.path, although I would plead for including startpoint=/endpoint= parameters, not only piping.

Moritz

6

Hi Maximilian, welcome aboard!

On 4/17/07, maximilian maldacker <mmaldacker@gmail.com> wrote:
[...]

Should the visibility graph construction algorithm
be added to the Directed Graph Library?

Eventually, but it should be coded as an independent library anyway,
agnostic of both GRASS internal data representation details and any
output code. Then you would go layer by layer to GRASS interfaces of
it, and then user interface (e.g. the module's parameters and options)
and then, eventually, some display features if need be.

What is the best way to test my code? Should I keep a fresh copy of GRASS on
my computer, modify/create files, compile everything and test it using the
spearfish example? Or is there another way?

That is roughly what everybody does who is not touching/refactoring
internals. Please also consider using Soeren Gebbert's test suite
(http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/ ;
other links? wiki?), possibly from the start to help you fix
representations, border cases, scalability and so on.

Thank you for your help and I'm looking forward to help develop GRASS.

We look forward to seeing you around for longer than the summer.

Daniel.

--
-- Daniel Calvelo Aros

7

We will try to get out a new, more modern data set that is planned as a replacement for spearfish,
it has been already tested with almost every raster module and most vector modules,
we just need to cleanup the names and add metadata. The data set has at least building footprints
so you can generate simple buildings using v.extrude, but I am working on getting
some real buildings data too. Let me discuss with Markus the best way to provide
the data set for early testers/developers.

Helena

Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~helena/

On Apr 17, 2007, at 4:18 AM, maximilian maldacker wrote:

Hello everyone, my name is Maximilian Maldacker and I'm currently a student in Imperial College London studying Mathematics and Computer Science. My project on "Shortest path in free (vector) space avoiding obstacles module in GRASS" was select by Google Summer of Code and I'm looking forward to it :-). I actually start on the 28th of May but I thought I'd introduce my self before and get involved with the community.

I have a few question concerning the development of the module. I see modules are organized in several folders and I thought I can create a new folder in the display folder named d.path_obstacles or something similar. Is it sufficient to create a new folder with a Makefile inside and a few *.c files to make a new module and will it be recognized by the command line?
The plan for now is to develop a module similar to the d.path one except it will start with a vector space containing obstacles ( i.e. polygons ) and it will construct a visibility graph out of it and compute the shortest path between two given points. Should the visibility graph construction algorithm be added to the Directed Graph Library?
What is the best way to test my code? Should I keep a fresh copy of GRASS on my computer, modify/create files, compile everything and test it using the spearfish example? Or is there another way?

Thank you for your help and I'm looking forward to help develop GRASS.
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev