Submitting module to addons - r.sundenoise - mentor required

[John A Stevenson]

Hi,

I have written an add-on module.  It is called r.sundenoise and it is
for denoising/despeckling DEMs to improve the quality of slope maps and
other geomorphic products derived from them.  The denoising is carried
out by Sun's denoising algorithm, a GPL'd mesh filtering algorithm that
I have been testing on topographic data as part of a research project.  
It does a very nice job.

My module is a shell script that works as a wrapper to the algorithm so
that it can be run from within GRASS, in much the same way as
r.surf.nnbathy works as a wrapper for nn.  I would like to submit it to
the add-ons repository.

I have read and will abide by the document RFC2 - Legal aspects of code
contributions.  I have an osgeo_id: stevensj

Would someone like to be my mentor?  You can try the module at:
http://personalpages.manchester.ac.uk/staff/john.stevenson

Cheers

John

--


Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. [phone]; fax. [phone];
[hidden email]

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Hi,

2009/7/2 John A Stevenson <[hidden email]>:
> My module is a shell script that works as a wrapper to the algorithm so that
> it can be run from within GRASS, in much the same way as r.surf.nnbathy

too much work to rewrite it to Python? (If I can suggest please write
new modules in Python). In GRASS7 there is no extra support for shell
scripts.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[John A Stevenson]

Hi Martin,

Martin Landa wrote:
> too much work to rewrite it to Python?
I have in my mind to write a python version at some stage, as it isn't a
complicated script.  But first I need to learn python...

I uploaded a shell script first as I have had a paper accepted about the
denoising algorithm and I want to mention in the paper that it can be
run via a GRASS module.  I need to send the revised draft back to the
editor next week, so I wanted to have a working version online as soon
as possible.  Once a working version is up and available  I can have a
look at making a python version.

Cheers

John

--


Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. [phone]; fax. [phone];
[hidden email]

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[hamish-2]

Martin wrote:
> In GRASS7 there is no extra support for shell scripts.

This is IMO a huge, huge mistake.

I am fine that all future run-time scripts shipped with GRASS 7+ be written
in python, but I think it is a serious strategic error to force users to
learn python and rewrite all their private & likely tested+trusted shell
scripts to a new language for what is essentially zero gain for them.
Encourage python for first-class addon scripts, yes; force it, no way.

I feel the same way about banning upper case option names in the parser.
Fine for official modules, but we should let the users do whatever they
please.

analogy: ensure that grass compiles with 'gcc -ansi' but don't mandate
that users' personal addon C programs do as well.

If users with a large investment/library of personal shell scripts will
have to rewrite all their scripts in python, and they already know some
Visual Basic, ... it's one thing for proprietary vendors to lock their
users in, it seems ridiculous to do the opposite and act to drive them
away.


So (IIU this C*), why should the removal of shell script support not be
reverted?  What does it cost us to keep shell script support?**

[*] & I suspect I may not.
[**] loss of focus is a cost which must be balanced against continuity


Hamish



     

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Hi,

2009/7/3 Hamish <[hidden email]>:
>> In GRASS7 there is no extra support for shell scripts.
>
> This is IMO a huge, huge mistake.

I do not claim that it shouldn't be possible to run shell scripts in
GRASS7. Most of the restrictions in our lives are bad at the end;-)
Anyway I highly suggest to write new scripts in Python, see [1].
Probably it's personal point of view, but writing shell scripts was
always pain for me and I can hardly imagine person (without previous
scripting experience) who prefers to learn how to write shell scripts
rather then to learn Python. Python is quite easy language to learn
for newcomers. Shell scripts are simply not good choice for writing
sometimes quite complicated GRASS scripts.

Martin

[1] http://download.osgeo.org/grass/grass6_progman/pythonlib.html

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Helena Mitasova]

Martin,

the discussion here is not about whether to write NEW scripts as  
shell scripts
but whether anybody who has many shell scripts will have to rewrite
them into Python to be able to run them in GRASS7. Imagine you have  
20 old,
stable, well tested scripts doing complex workflows and a lot of new  
work
to do, would you want to spend your time rewriting these old shell  
scripts
into Python or rather develop new capabilities? Some scripts may be  
worth
rewriting, some not. I think this is what Hamish had in mind.
BTW I am not the person who has lost of shell scripts so for me it  
does not matter,
but there are many people who do.
It may slow down adoption of GRASS7 and people may prefer to stick with
GRASS6*, rather than rewrite.

just a few words to support Hamish's view,

Helena



On Jul 3, 2009, at 12:26 PM, Martin Landa wrote:

> Hi,
>
> 2009/7/3 Hamish <[hidden email]>:
>>> In GRASS7 there is no extra support for shell scripts.
>>
>> This is IMO a huge, huge mistake.
>
> I do not claim that it shouldn't be possible to run shell scripts in
> GRASS7. Most of the restrictions in our lives are bad at the end;-)
> Anyway I highly suggest to write new scripts in Python, see [1].
> Probably it's personal point of view, but writing shell scripts was
> always pain for me and I can hardly imagine person (without previous
> scripting experience) who prefers to learn how to write shell scripts
> rather then to learn Python. Python is quite easy language to learn
> for newcomers. Shell scripts are simply not good choice for writing
> sometimes quite complicated GRASS scripts.
>
> Martin
>
> [1] http://download.osgeo.org/grass/grass6_progman/pythonlib.html
>
> --
> Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
> _______________________________________________
> grass-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Markus Neteler]

On Fri, Jul 3, 2009 at 6:26 PM, Martin Landa<[hidden email]> wrote:
> 2009/7/3 Hamish <[hidden email]>:
>>> In GRASS7 there is no extra support for shell scripts.
>>
>> This is IMO a huge, huge mistake.
>
> I do not claim that it shouldn't be possible to run shell scripts in
> GRASS7.

Hi (just digging through too many emails almost randomly):

so do you *assume* that it still works in 7 or do shell scripts work?
The latter is the aim in my opinion.

If GRASS 7 would refuse to work with shell scripts I had to stick
with GRASS 6 for my work since I have hundreds of them including
very complex workflows. Most likely I'll switch to Python later this
year but certainly I won't rewrite working scripts if there is no need.

So, just confirm that my existing scripts still run [1] and I am happy
supporter of a "Python preferred" policy for GRASS 7.

cheers
Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Glynn Clements]

Hamish wrote:

> So (IIU this C*), why should the removal of shell script support not be
> reverted?  What does it cost us to keep shell script support?**
>
> [*] & I suspect I may not.

The "support" which has been removed is limited to the build system.

If you include Script.make, the directory must contain $(PGM).py or
you get an error.

People are free to script GRASS commands in whatever language they
choose, but shell scripts don't belong in the GRASS 7 repository, so
there's no need for the build system to provide any support for them.

If something doesn't work unless you install /bin/sh and a dozen other
Unix utilities, that's a critical bug. Ditto for anything which
doesn't work if $GISBASE or GISDBASE contain spaces.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[hamish-2]

Martin wrote:
> Anyway I highly suggest to write new scripts in Python, see
> [1]. Probably it's personal point of view, but writing shell
> scripts was always pain for me and I can hardly imagine person
> (without previous scripting experience) who prefers to learn
> how to write shell scripts rather then to learn Python. Python
> is quite easy language to learn for newcomers. Shell scripts
> are simply not good choice for writing sometimes quite
> complicated GRASS scripts.

I completely agree. All the same, often they are quite useful
and powerful.


regards,
Hamish



     

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[hamish-2]

Hamish:
> > So (IIU this C*), why should the removal of shell script
> > support not be reverted?  What does it cost us to keep shell
> > script support?**
> >
> > [*] & I suspect I may not.

Glynn:
> The "support" which has been removed is limited to the
> build system.

Thank you for the clarification; sorry for any noise.

> If you include Script.make, the directory must contain
> $(PGM).py or you get an error.
>
> People are free to script GRASS commands in whatever language
> they choose, but shell scripts don't belong in the GRASS 7
> repository, so there's no need for the build system to provide
> any support for them.

I am not sure how much people use Makefiles with addon scripts,
I suspect it is often easier just to copy them into
GRASS_ADDON_PATH. (typically I just symlink from the grass-addons
svn into there and install nothing)


regards,
Hamish





_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev