I am working on a shell script to calculate the multi-environmental similarity surface (MESS), which represents how similar a point is to a reference set of points, with respect to a set of predictor variables (V1, V2, …) (Elith, J., Kearney, M., & Phillips, S. 2010. The art of modelling range-shifting species. Methods in Ecology and Evolution 1: 330–342.). The MESS is implemented in Maxent, but having this function in GRASS allows for more flexibility and easier incorporation in other scripts.
I am completely new to shell scripting (or any other programming except a little bit of R scripting) so I am sure there is a lot to improve. For example, the script depends on R, and I am not sure if and how I can build in checks to make sure this runs on different platforms (I am working on Linux and have no easy way to check on Windows). There is also the issue of dealing with temporary data. I have used the approach I found in other scripts, but I am not sure it is all done properly as it is now. The part to be run in R can be improved for sure too, but that is something I can and will work on (but if people have suggestions, including how to do this completely in GRASS without R that would be great).
I have attached the current script + help file. It runs on my computer, but I hope somebody on the list wants to have a look at it to check / test it. I would also like to know what else is needed in case I want to add it to the addon wiki.
Thanks, I just uploaded the r.mess script to the grass-addons/grass7/raster. Any feedback is most welcome (adherence to grass and bash scripts coding standards is probably one of the thing to check as I am completely new to this).
Paulo
On Mon, Oct 15, 2012 at 6:36 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
I am working on a shell script to calculate the multi-environmental similarity surface (MESS), which represents how similar a point is to a reference set of points, with respect to a set of predictor variables (V1, V2, …) (Elith, J., Kearney, M., & Phillips, S. 2010. The art of modelling range-shifting species. Methods in Ecology and Evolution 1: 330–342.).
It would be great if I could get some feedback and to add it to the addon wiki eventually. Following the suggestion of Helmut, it would be good if I could add it to the GRASS-Addons-SVN repository. I therefore would like to request write access to the GRASS-Addons-SVN repository. I have read and understood the RFC2. My osgeo id is pvanbosgeo.
Cheers,
Paulo
On Mon, Oct 15, 2012 at 12:45 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
Hi Paulo,
please post it in the GRASS PSC-ML [1], so it’s getting official.
Gesendet: Sonntag, 14. Oktober 2012 um 13:21 Uhr Von: “Paulo van Breugel” <p.vanbreugel@gmail.com> An: “Helmut Kudrnovsky” <hellik@web.de> Betreff: Re: [GRASS-dev] working on a add on to calculate MESS
Hi Helmut
I have no problem having it in add-ons. That requires write access to the GRASS-Addons-SVN repository, for which I have to
[v] contact a GRASS developer [doing that right now ;-)]
[v] I have read and understood the RFC2.
[v] My osgeo id is pvanbosgeo
Cheers,
Paulo
On Sat, Oct 13, 2012 at 2:43 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
I would also like to know what else is needed in case I want to add it to
the addon wiki.
2012/10/16 Paulo van Breugel <p.vanbreugel@gmail.com>:
Thanks, I just uploaded the r.mess script to the grass-addons/grass7/raster.
Any feedback is most welcome (adherence to grass and bash scripts coding
standards is probably one of the thing to check as I am completely new to
this).
please bear in mind that your scripts cannot be currently installed in
GRASS 7 via g.extension. Building system of GRASS 7 doesn't support
Shell scripts [1]. Your script really requires GRASS 7? If not,
probably you should move your script to addons/grass6. Preferable
scripting language for GRASS 7 is Python not Bash.
Hi Martin, thanks for the info. Only reason it is in grass 7 is because that is what I use (I find it works better for me than grass64). I can move it to grass 6, I probably need to make one or two small changes first (separator tag).
Although I appreciate that the preferred language is Python, is it in the plans to make it possible to install shell extensions using g.extension later on? For me, I unfortunately I don’t know Python, and although I would love to work in Python, I simply do not have the time at the moment
Thanks, I just uploaded the r.mess script to the grass-addons/grass7/raster.
Any feedback is most welcome (adherence to grass and bash scripts coding
standards is probably one of the thing to check as I am completely new to
this).
please bear in mind that your scripts cannot be currently installed in
GRASS 7 via g.extension. Building system of GRASS 7 doesn’t support
Shell scripts [1]. Your script really requires GRASS 7? If not,
probably you should move your script to addons/grass6. Preferable
scripting language for GRASS 7 is Python not Bash.
Hi Martin, thanks for the info. Only reason it is in grass 7 is because
that is what I use (I find it works better for me than grass64). I can move
it to grass 6, I probably need to make one or two small changes first
(separator tag).
Although I appreciate that the preferred language is Python, is it in the
plans to make it possible to install shell extensions using g.extension
later on? For me, I unfortunately I don't know Python, and although I would
love to work in Python, I simply do not have the time at the moment
The main problem with using shell scripts in 7.0 is that they
typically won't work on Windows.
7.0 itself no longer requires a Unix shell or utilities to run; the
shell scripts have been replaced with Python versions, C code which
executes Unix utilities via system(), popen() etc has been re-written,
etc.
It is assumed that the Windows package for an eventual 7.0 release
won't include MSys, so a Unix shell and utilities won't necessarily be
available.
Also, Windows doesn't use a shebang (#!/bin/sh etc) to determine how
to run a script, it uses extensions. 6.x has some workarounds for
that, but those have been removed from 7.0 because they interfered
with running Python scripts.
OTOH, g.extension doesn't really work on Windows anyhow. Most users
won't have a compiler, make, or a Unix shell (which make requires).
Windows users are better served by having extensions pre-compiled and
packaged.
On Wed, Oct 17, 2012 at 10:02 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
...
OTOH, g.extension doesn't really work on Windows anyhow. Most users
won't have a compiler, make, or a Unix shell (which make requires).
Windows users are better served by having extensions pre-compiled and
packaged.
Yes - and this is how it is meanwhile implemented - for Windows users
precompiled packages are created overnight and downloaded/installed by
g.extension rather than locally compiled.
