[GRASS-dev] Google Summer Of Code Project

Benjamin Ducke benjamin.ducke at ufg.uni-kiel.de
Tue Apr 17 09:46:18 EDT 2007


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




More information about the grass-dev mailing list