I'm working at Finnish Geodetic Insitute where we have
developed software and algorithms for delineating drainage
basins from DEM (raster) data. Recently, we decided to
contribute the code to GRASS.
Now there are existing (hydrologic) modules in Grass that have
similar functionalities but they seem to be more than 10 years old and
are quite inefficient when comparing against newer algorithms.
Also, in our delineation method we allow user to add error
parameters to elevation data and the computations then
calculate the most likely locations for delineations.
What I have is existing C++ code that do the calculations
which should be integrated to GRASS.
After studying GRASS implementation a bit it seems
that I need only to create independent software modules
for each functionality (r.* module) where I define
interface for transferring parameters and data between
GRASS and our c++ code.
Is this correct?
There seem to be 3 different places where I could
add the code, "grass6.4, grass7 and grass-addons".
Which repository should I be using?
When I have finally get the modules working,
where should I sent the patches?
Can I get write access to a repository?
It may be possible that we will contribute more
code in the future.
Thanks in advance,
--
Tomas Ukkonen
Finnish Geodetic Institute
PL 15 (Geodeetinrinne 2)
02431 MASALA, FINLAND
There seem to be 3 different places where I could
add the code, "grass6.4, grass7 and grass-addons".
Which repository should I be using?
I guess for now 'grass-addons', if your module(s) covers&extent
current GRASS module functionality, it could be moved to grass7 (svn
trunk) in the future.
When I have finally get the modules working,
where should I sent the patches?
Can I get write access to a repository?
I'm working at Finnish Geodetic Insitute where we have
developed software and algorithms for delineating drainage
basins from DEM (raster) data. Recently, we decided to
contribute the code to GRASS.
Glad to hear it
After studying GRASS implementation a bit it seems
that I need only to create independent software modules
for each functionality (r.* module) where I define
interface for transferring parameters and data between
GRASS and our c++ code.
Is this correct?
Yes. In grass each functionality is wrapped in a stand-alone module. There are library functions that will allow you to set up a standard GRASS command line interface. See [1] for the programmer's manual. Also have a look at the example raster module to get an idea on how to set up the module to be a GRASS module, and how to access the GRASS raster files.
There seem to be 3 different places where I could
add the code, "grass6.4, grass7 and grass-addons".
Which repository should I be using?
Definitely grass-addons for now.
It may be possible that we will contribute more
code in the future.
Looking forward to it. In the meanwhile I'll be happy to help you in case you have any more questions.
I'm working at Finnish Geodetic Insitute where we have
developed software and algorithms for delineating drainage
basins from DEM (raster) data. Recently, we decided to
contribute the code to GRASS.
Glad to hear it
After studying GRASS implementation a bit it seems
that I need only to create independent software modules
for each functionality (r.* module) where I define
interface for transferring parameters and data between
GRASS and our c++ code.
Is this correct?
Yes. In grass each functionality is wrapped in a stand-alone module. There are library functions that will allow you to set up a standard GRASS command line interface. See [1] for the programmer's manual. Also have a look at the example raster module to get an idea on how to set up the module to be a GRASS module, and how to access the GRASS raster files.
There seem to be 3 different places where I could
add the code, "grass6.4, grass7 and grass-addons".
Which repository should I be using?
Definitely grass-addons for now.
It may be possible that we will contribute more
code in the future.
Looking forward to it. In the meanwhile I'll be happy to help you in case you have any more questions.
After studying GRASS implementation a bit it seems
that I need only to create independent software modules
for each functionality (r.* module) where I define
interface for transferring parameters and data between
GRASS and our c++ code.
Is this correct?
Yes. In grass each functionality is wrapped in a stand-alone module. There are library functions that will allow you to set up a standard GRASS command line interface. See [1] for the programmer’s manual. Also have a look at the example raster module to get an idea on how to set up the module to be a GRASS module, and how to access the GRASS raster files.
Yes I have read GRASS documents and source code to see
how code should be modularized.
Looking forward to it. In the meanwhile I’ll be happy to help you in case you have any more questions.
Thanks. I’m currently in the process of GRASSificating our methods
into GRASS modules. I also already contacted Hamish (see below) for
getting access to GRASS-addons. This will take a while however, because
I have other more pressing duties (writing research papers etc.) to do
before I have time to do some coding. But I will ask you if I need any help.
···
--
Tomas Ukkonen
Finnish Geodetic Institute
PL 15 (Geodeetinrinne 2)
02431 MASALA, FINLAND
Hi Tomas,
> Sometime ago I send an email to the GRASS-dev list and
> asked for instructions to contribute code to GRASS and was told
> to get a mentor/sponsor who can grant access to GRASS-Addons
> repository.
Sure. please post a message to the grass-psc mailing list stating that you have read and agree to GRASS's RFC2 document regarding our software license terms (the GPL) and wish to have access to the grass-addons repo. Please also post the OSGeo user ID you would like to use. if you don't have an OSGeo login, you can create yourself one:
[http://www.osgeo.org/osgeo_userid](http://www.osgeo.org/osgeo_userid)
After that we can add you to the list!
> I'm currently working in a project where we have
> developed/programmed drainage basin delineation
> (terrain analysis) methods(*) that work better/differently
> than their GRASS counterparts. There have been decision to
> contribute some of this code to GRASS.
Yes I remember your post well and was meaning to respond to it. At the time you sent it I was 4 days into a r.watershed calculation.
[5000x5000 cell region (10m DEM, 1000 sq km in catchments of interest) r.watershed took about 4-5 days to run and used 1.0-1.5 gb RAM, and I had to run it a few times to get the threshold as I liked]
I would mention out of interest that the original author of r.watershed stops by the grass mailing list now and then, even though the code is very many years old now.
> For that we need write access to GRASS-Addons
> repository and sponsor/mentor. Based on the
> postings you seem to be fairly active in the community.
>
> Could you help us get the write access to the repository or
> point someone else who can?
RFC2: [http://download.osgeo.org/grass/grass6_progman/rfc/](http://download.osgeo.org/grass/grass6_progman/rfc/)
PSC mailing list: [http://lists.osgeo.org/mailman/listinfo/grass-psc](http://lists.osgeo.org/mailman/listinfo/grass-psc)
It is requested that code conforms to SUBMITTING standards,
[http://trac.osgeo.org/grass/browser/grass/trunk](http://trac.osgeo.org/grass/browser/grass/trunk)
For the grass-addons it is only suggested, for inclusion in main GRASS source code it is required.
I look forward to seeing your contributions!
thanks,
Hamish
