As my first attempt to contact dev list failed (my mail was eaten by
mail daemons ;), I resend my first mail.
Hi,
I send to You my first peace of C code (after hello world ;). As a
newbie I would like to hear any feedback about this code:
1) Is idea worth to be included in GRASS some day?
2) Any comments about programming in GRASS and C in general.
NAME: r.lake (original
PURPOSE: This module fills lake at given level from start point (seed) on DEM.
HOW it works: it assigns depth value to all cells which are connected
to start point and are below water level. Filling is done by moving
window multiple times (as necessary) across map. Output map depth
values are positive, but it is possible to output negative values
(units below water surface) for visualisation purposes.
TODOs:
- 3d output. Current output is 2d + depth value;
- nice blue gradient for output map;
- documentation with examples - in progress.
- other ideas?
BUGs:
- seed map cannot be negative - cannot use negative lake output maps as input.
HOW to use:
input = DEM
seed = raster with at least one cell below water level with value > 0
lake = new output raster file
wl = water level in DEM units
-n = output map will have negative values
-o = overwrite seedmap instead of using "lake"
HISTORY:
Last spring I was working on my master thesis and needed way how to
find lake shape, depth if only single bank point is known. As I could
not find existing method in GRASS, someone on GRASS user list
suggested to use r.mapcalc. I wrote script that calls r.mapcalc and
fills lake cell by cell. On 3 GHz P4 it took about 24 - 48 h to finish
single lake map. This autumn I read "teachyourself C in 24h" and
rewrote it in C. Now - after some testing and improving - here it is Now I can get my lake in less than minute even on my 800 MHz
Celeron
There has been request from users for such functionality on GRASS user
list, so, IMHO after this module will be checked, tested etc, it could
be useful for other ppl too.
CHANGES: Added gettext support by Markus Neteler;
-o flag = in/out separated.
I noticed that quite a few useful modules are being developed (such as the below r.lake)
and it would be great to have them submitted into add-ons so that people can see what
is available, test it and if it is great and important it could be included into next release.
Also - do we have any rules on when an add-on module can be submitted to CVS?
thanks, Helena
On Jan 9, 2006, at 9:18 AM, Māris Nartišs wrote:
As my first attempt to contact dev list failed (my mail was eaten by
mail daemons ;), I resend my first mail.
Hi,
I send to You my first peace of C code (after hello world ;). As a
newbie I would like to hear any feedback about this code:
1) Is idea worth to be included in GRASS some day?
2) Any comments about programming in GRASS and C in general.
NAME: r.lake (original
PURPOSE: This module fills lake at given level from start point (seed) on DEM.
HOW it works: it assigns depth value to all cells which are connected
to start point and are below water level. Filling is done by moving
window multiple times (as necessary) across map. Output map depth
values are positive, but it is possible to output negative values
(units below water surface) for visualisation purposes.
TODOs:
- 3d output. Current output is 2d + depth value;
- nice blue gradient for output map;
- documentation with examples - in progress.
- other ideas?
BUGs:
- seed map cannot be negative - cannot use negative lake output maps as input.
HOW to use:
input = DEM
seed = raster with at least one cell below water level with value > 0
lake = new output raster file
wl = water level in DEM units
-n = output map will have negative values
-o = overwrite seedmap instead of using "lake"
HISTORY:
Last spring I was working on my master thesis and needed way how to
find lake shape, depth if only single bank point is known. As I could
not find existing method in GRASS, someone on GRASS user list
suggested to use r.mapcalc. I wrote script that calls r.mapcalc and
fills lake cell by cell. On 3 GHz P4 it took about 24 - 48 h to finish
single lake map. This autumn I read "teachyourself C in 24h" and
rewrote it in C. Now - after some testing and improving - here it is Now I can get my lake in less than minute even on my 800 MHz
Celeron
There has been request from users for such functionality on GRASS user
list, so, IMHO after this module will be checked, tested etc, it could
be useful for other ppl too.
CHANGES: Added gettext support by Markus Neteler;
-o flag = in/out separated.
IMHO, the best solution to this is Benjamin Ducke's new GRASS Extensions
Manager (GEM). This is nearing final release. It allows users to add new
modules (i.e., extensions) in a special extension directory. These will
automatically be added to a special xtn menu in the GIS Manager or (of
course) be accessible via the command line. These can be added to a binary
installation of GRASS.
This way we *CAN* have some kind of control over what goes into a base GRASS
installation AND users can install all the really neat add-ins you're
seeing. Most importantly, they can add these without compiling GRASS.
Michael
On 3/11/06 10:49 PM, "Helena Mitasova" <hmitaso@unity.ncsu.edu> wrote:
I have a question about Add-ons - Do we have any restrictions /
official rules for what can go into GRASS add ons?
I noticed that quite a few useful modules are being developed (such
as the below r.lake)
and it would be great to have them submitted into add-ons so that
people can see what
is available, test it and if it is great and important it could be
included into next release.
Also - do we have any rules on when an add-on module can be submitted
to CVS?
thanks, Helena
On Jan 9, 2006, at 9:18 AM, M?ris Narti¹s wrote:
As my first attempt to contact dev list failed (my mail was eaten by
mail daemons ;), I resend my first mail.
Hi,
I send to You my first peace of C code (after hello world ;). As a
newbie I would like to hear any feedback about this code:
1) Is idea worth to be included in GRASS some day?
2) Any comments about programming in GRASS and C in general.
NAME: r.lake (original
PURPOSE: This module fills lake at given level from start point
(seed) on DEM.
HOW it works: it assigns depth value to all cells which are connected
to start point and are below water level. Filling is done by moving
window multiple times (as necessary) across map. Output map depth
values are positive, but it is possible to output negative values
(units below water surface) for visualisation purposes.
TODOs:
- 3d output. Current output is 2d + depth value;
- nice blue gradient for output map;
- documentation with examples - in progress.
- other ideas?
BUGs:
- seed map cannot be negative - cannot use negative lake output
maps as input.
HOW to use:
input = DEM
seed = raster with at least one cell below water level with value > 0
lake = new output raster file
wl = water level in DEM units
-n = output map will have negative values
-o = overwrite seedmap instead of using "lake"
HISTORY:
Last spring I was working on my master thesis and needed way how to
find lake shape, depth if only single bank point is known. As I could
not find existing method in GRASS, someone on GRASS user list
suggested to use r.mapcalc. I wrote script that calls r.mapcalc and
fills lake cell by cell. On 3 GHz P4 it took about 24 - 48 h to finish
single lake map. This autumn I read "teachyourself C in 24h" and
rewrote it in C. Now - after some testing and improving - here it is Now I can get my lake in less than minute even on my 800 MHz
Celeron
There has been request from users for such functionality on GRASS user
list, so, IMHO after this module will be checked, tested etc, it could
be useful for other ppl too.
CHANGES: Added gettext support by Markus Neteler;
-o flag = in/out separated.
WBR,
Maris Nartiss
<r_lake.zip>
___________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287
I think that this is open to all GRASS contributors.
The program/script should be non-distructive, well tested, documented
and of some interest to the public.
> I noticed that quite a few useful modules are being developed (such
> as the below r.lake)
> and it would be great to have them submitted into add-ons so that
> people can see what
> is available, test it and if it is great and important it could be
> included into next release.
> Also - do we have any rules on when an add-on module can be submitted
> to CVS?
Here it should be of general interest to the GRASS community,
non-distructive, and well tested + documented. It also has
to conform to the SUBMITTING rules.
On 3/13/06 6:14 AM, "Markus Neteler" <neteler@itc.it> wrote:
On Sun, Mar 12, 2006 at 01:09:42PM -0700, Michael Barton wrote:
Helena,
IMHO, the best solution to this is Benjamin Ducke's new GRASS Extensions
Manager (GEM). This is nearing final release.
Would it make sense to develop the GRASS Extensions Manager in
GRASS CVS?
Yes. I believe that Benjamin is planning to suggest this go into the CVS
when it finishes the next round of testing. If this could be part of the
GRASS standard distribution, it would open up GRASS to a wide variety of
contributions that did not need to depend on the GRASS CVS.
...
On 3/11/06 10:49 PM, "Helena Mitasova" <hmitaso@unity.ncsu.edu> wrote:
I have a question about Add-ons - Do we have any restrictions /
official rules for what can go into GRASS add ons?
I think that this is open to all GRASS contributors.
The program/script should be non-distructive, well tested, documented
and of some interest to the public.
I noticed that quite a few useful modules are being developed (such
as the below r.lake)
and it would be great to have them submitted into add-ons so that
people can see what
is available, test it and if it is great and important it could be
included into next release.
Also - do we have any rules on when an add-on module can be submitted
to CVS?
Here it should be of general interest to the GRASS community,
non-distructive, and well tested + documented. It also has
to conform to the SUBMITTING rules.
Markus
___________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287
My question was about something different and it will be even more pressing with the extensions - what will be the rules for extension submission?
e.g.
- will everybody in world be allowed to submit ?
- who will test the extensions - are users going to use them at their own risk, will there be some incubation period when people will be able to use it but it is not yet official extension,
- how do you say whether
"The program/script is non-distructive, well tested, documented
and of some interest to the public."
I am talking from my own experience as I too often push for "unfinished" stuff being submitted hoping that making it available will help to finish it, this may work if there are 2-3 people like that, but with many contributors with this behavior it could create a pretty big mess.
If half of the submitted extensions do not work properly, this may discourage people from using them at all (I have seen this happening with ArcGIS extensions).
I will leave this for now and I am sure that it will come up when the extension support becomes available.
Helena
-andMichael Barton wrote:
Markus and Helena,
On 3/13/06 6:14 AM, "Markus Neteler" <neteler@itc.it> wrote:
On Sun, Mar 12, 2006 at 01:09:42PM -0700, Michael Barton wrote:
Helena,
IMHO, the best solution to this is Benjamin Ducke's new GRASS Extensions
Manager (GEM). This is nearing final release.
Would it make sense to develop the GRASS Extensions Manager in
GRASS CVS?
Yes. I believe that Benjamin is planning to suggest this go into the CVS
when it finishes the next round of testing. If this could be part of the
GRASS standard distribution, it would open up GRASS to a wide variety of
contributions that did not need to depend on the GRASS CVS.
...
On 3/11/06 10:49 PM, "Helena Mitasova" <hmitaso@unity.ncsu.edu> wrote:
I have a question about Add-ons - Do we have any restrictions /
official rules for what can go into GRASS add ons?
I think that this is open to all GRASS contributors.
The program/script should be non-distructive, well tested, documented
and of some interest to the public.
I noticed that quite a few useful modules are being developed (such
as the below r.lake)
and it would be great to have them submitted into add-ons so that
people can see what
is available, test it and if it is great and important it could be
included into next release.
Also - do we have any rules on when an add-on module can be submitted
to CVS?
Here it should be of general interest to the GRASS community,
non-distructive, and well tested + documented. It also has
to conform to the SUBMITTING rules.
Markus
___________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287
On Mon, Mar 13, 2006 at 03:41:55PM -0500, Helena Mitasova wrote:
My question was about something different and it will be even more
pressing with the extensions - what will be the rules for extension
submission?
e.g.
- will everybody in world be allowed to submit ?
In general yes, but we need a submission manager to get out
tha "spam".
- who will test the extensions - are users going to use them at their
own risk, will there be some incubation period when people will be able
to use it but it is not yet official extension,
We have to assure high quality. Maybe Benjamin's extension manager
will help?
- how do you say whether
"The program/script is non-distructive, well tested, documented
and of some interest to the public."
Sorry - I just wanted to give an idea. "non-distructive" is really
important (I don't like scripts which erase my home dir).
Documented is nothing impossible. Well tested is hard, we could
says, well tested against Spearfish and other known datasets.
I am talking from my own experience as I too often push for "unfinished"
stuff being submitted hoping that making it available will help to
finish it, this may work if there are 2-3 people like that, but with
many contributors with this behavior it could create a pretty big mess.
If half of the submitted extensions do not work properly, this may
discourage people from using them at all (I have seen this happening
with ArcGIS extensions).
It's the release-often against the release-good-stuff paradigm.
Probably there is no solution. We have in fact to define
rules as exist in SUBMITTING and SUBMITTING_SCRIPTS.
Markus
I will leave this for now and I am sure that it will come up when the
extension support becomes available.
Helena
-andMichael Barton wrote:
>Markus and Helena,
>
>
>On 3/13/06 6:14 AM, "Markus Neteler" <neteler@itc.it> wrote:
>
>
>>On Sun, Mar 12, 2006 at 01:09:42PM -0700, Michael Barton wrote:
>>
>>>Helena,
>>>
>>>IMHO, the best solution to this is Benjamin Ducke's new GRASS Extensions
>>>Manager (GEM). This is nearing final release.
>>
>>Would it make sense to develop the GRASS Extensions Manager in
>>GRASS CVS?
>
>
>Yes. I believe that Benjamin is planning to suggest this go into the CVS
>when it finishes the next round of testing. If this could be part of the
>GRASS standard distribution, it would open up GRASS to a wide variety of
>contributions that did not need to depend on the GRASS CVS.
>
>
>>...
>>
>>>On 3/11/06 10:49 PM, "Helena Mitasova" <hmitaso@unity.ncsu.edu> wrote:
>>>
>>>
>>>>I have a question about Add-ons - Do we have any restrictions /
>>>>official rules for what can go into GRASS add ons?
>>>>
>>>>http://grass.gdf-hannover.de/twiki/bin/view/GRASS/GrassAddOns
>>
>>I think that this is open to all GRASS contributors.
>>The program/script should be non-distructive, well tested, documented
>>and of some interest to the public.
>>
>>
>>>>I noticed that quite a few useful modules are being developed (such
>>>>as the below r.lake)
>>>>and it would be great to have them submitted into add-ons so that
>>>>people can see what
>>>>is available, test it and if it is great and important it could be
>>>>included into next release.
>>>>Also - do we have any rules on when an add-on module can be submitted
>>>>to CVS?
>>
>>Here it should be of general interest to the GRASS community,
>>non-distructive, and well tested + documented. It also has
>>to conform to the SUBMITTING rules.
>>
>>Markus
>>
>
>
>___________________________
>Michael Barton, Professor of Anthropology
>School of Human Evolution & Social Change
>Arizona State University
>Tempe, AZ 85287
>
>WWW - http://www.public.asu.edu/~cmbarton
>Phone: 480-965-6262
>Fax: 480-965-7671
>
My question was about something different and it will be even more
pressing with the extensions - what will be the rules for extension
submission?
e.g.
- will everybody in world be allowed to submit ?
- who will test the extensions - are users going to use them at their
own risk, will there be some incubation period when people will be able
to use it but it is not yet official extension,
- how do you say whether
"The program/script is non-distructive, well tested, documented
and of some interest to the public."
I am talking from my own experience as I too often push for "unfinished"
stuff being submitted hoping that making it available will help to
finish it, this may work if there are 2-3 people like that, but with
many contributors with this behavior it could create a pretty big mess.
If half of the submitted extensions do not work properly, this may
discourage people from using them at all (I have seen this happening
with ArcGIS extensions).
I will leave this for now and I am sure that it will come up when the
extension support becomes available.
The CRAN example from R is worth examining, and is pretty demanding in
terms of requiring submitted add-ons to pass specific tests, and to
fulfill license requirements if distributed from CRAN. It has the benefit
that the tests also reveal whether changes in GRASS CVS core would break
contributed add-ons. It isn't substantive QA (it doesn't check whether the
contributed code adequately implements what it claims to - the online JSS
and R-News can do that if add-on (package) authors submit papers - only
that it completes a set of tests on its code, documentation, and examples.
It's a lot of work, but is worth it when the add-on mechanism gathers
momentum.
Roger
Helena
-andMichael Barton wrote:
> Markus and Helena,
>
>
> On 3/13/06 6:14 AM, "Markus Neteler" <neteler@itc.it> wrote:
>
>
>>On Sun, Mar 12, 2006 at 01:09:42PM -0700, Michael Barton wrote:
>>
>>>Helena,
>>>
>>>IMHO, the best solution to this is Benjamin Ducke's new GRASS Extensions
>>>Manager (GEM). This is nearing final release.
>>
>>Would it make sense to develop the GRASS Extensions Manager in
>>GRASS CVS?
>
>
> Yes. I believe that Benjamin is planning to suggest this go into the CVS
> when it finishes the next round of testing. If this could be part of the
> GRASS standard distribution, it would open up GRASS to a wide variety of
> contributions that did not need to depend on the GRASS CVS.
>
>
>>...
>>
>>>On 3/11/06 10:49 PM, "Helena Mitasova" <hmitaso@unity.ncsu.edu> wrote:
>>>
>>>
>>>>I have a question about Add-ons - Do we have any restrictions /
>>>>official rules for what can go into GRASS add ons?
>>>>
>>>>http://grass.gdf-hannover.de/twiki/bin/view/GRASS/GrassAddOns
>>
>>I think that this is open to all GRASS contributors.
>>The program/script should be non-distructive, well tested, documented
>>and of some interest to the public.
>>
>>
>>>>I noticed that quite a few useful modules are being developed (such
>>>>as the below r.lake)
>>>>and it would be great to have them submitted into add-ons so that
>>>>people can see what
>>>>is available, test it and if it is great and important it could be
>>>>included into next release.
>>>>Also - do we have any rules on when an add-on module can be submitted
>>>>to CVS?
>>
>>Here it should be of general interest to the GRASS community,
>>non-distructive, and well tested + documented. It also has
>>to conform to the SUBMITTING rules.
>>
>>Markus
>>
>
>
> ___________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Arizona State University
> Tempe, AZ 85287
>
> WWW - http://www.public.asu.edu/~cmbarton
> Phone: 480-965-6262
> Fax: 480-965-7671
>
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no
Now I can get my lake in less than minute even on my 800 MHz
Now I can get my lake in less than minute even on my 800 MHz