[GRASS-dev] Re: [GRASS-user] updating kriging modules for grass 62

GRASS GIS GRASS GIS developer
1

While I would really like to see someone except for
myself use GEM, I think kriging is really core GIS
functionality and should be part of the base modules
set.

I would also expect a lot of statistical modules in the
future to depend on R, seeing how powerful the R
spatial analysis stuff is.
There are so many useless dependencies in GRASS (Motif,
BLAS, LAPACK,...), so why not add one that is actually very
useful for a lot of people?

Or even better: why not include an up-to-date R shell and
the best spatial stat libraries in the GRASS base
distribution to make it easier for everyone to add
powerful spatial statistics modules to GRASS and use them
out-of-the-box?

I think R is excellent quality code that runs on all major
OS's and has no dependencies itself.

Benjamin

Michael Barton wrote:

Pierluigi,

Could you make these installable via GEM?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Pierluigi De Rosa <pierluigi.derosa@gfosservices.it>
Date: Mon, 27 Nov 2006 11:06:59 +0100
To: GRASS LIST <grassuser@grass.itc.it>
Subject: [GRASS-user] updating kriging modules for grass 62

Dear User,
I have updated on GRASS addons v.variogram anv v.krige run on spgrass6 >= 0.3
and sp >= 0.9
I created a new one module v.krige.cv to perform leave-one-out- Cross
Validation of variogram model. Obviously this modules have to be run before
v.krige.
I know my explanation is really short but if anyone is interested to this
modules and he wont to undestand better how they works please let me kwon it
and I will write a better tutorial
Pierluigi

--

Pierluigi De Rosa

GFosServices S.A.

--
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

2

On Tue, Nov 28, 2006 at 09:32:59AM +0100, Benjamin Ducke wrote:

While I would really like to see someone except for
myself use GEM, I think kriging is really core GIS
functionality and should be part of the base modules
set.

+1

Kriging is very importand and many people are asking for it. What do
other developer think? What about adding this module in future GRASS
7.0?

Jachym

I would also expect a lot of statistical modules in the
future to depend on R, seeing how powerful the R
spatial analysis stuff is.
There are so many useless dependencies in GRASS (Motif,
BLAS, LAPACK,...), so why not add one that is actually very
useful for a lot of people?

Or even better: why not include an up-to-date R shell and
the best spatial stat libraries in the GRASS base
distribution to make it easier for everyone to add
powerful spatial statistics modules to GRASS and use them
out-of-the-box?

I think R is excellent quality code that runs on all major
OS's and has no dependencies itself.

Benjamin

Michael Barton wrote:
> Pierluigi,
>
> Could you make these installable via GEM?
>
> Michael
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics and Complexity
> Arizona State University
>
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
>
>
>> From: Pierluigi De Rosa <pierluigi.derosa@gfosservices.it>
>> Date: Mon, 27 Nov 2006 11:06:59 +0100
>> To: GRASS LIST <grassuser@grass.itc.it>
>> Subject: [GRASS-user] updating kriging modules for grass 62
>>
>> Dear User,
>> I have updated on GRASS addons v.variogram anv v.krige run on spgrass6 >= 0.3
>> and sp >= 0.9
>> I created a new one module v.krige.cv to perform leave-one-out- Cross
>> Validation of variogram model. Obviously this modules have to be run before
>> v.krige.
>> I know my explanation is really short but if anyone is interested to this
>> modules and he wont to undestand better how they works please let me kwon it
>> and I will write a better tutorial
>> Pierluigi
>>
>> --
>>
>> Pierluigi De Rosa
>>
>> GFosServices S.A.
>>
>>
>
>
>

--
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

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
-----------------------------------------
OFFICE:
Department of Geoinformation Technologies
Zemedelska 3
613 00, Brno
Czech Republick
e-mail: xcepicky@node.mendelu.cz
URL: http://mapserver.mendelu.cz
Tel.: +420 545 134 514

3

+ 2
Kriging is an interpolation methods that absolutely should be included.
And leave-one-out validation can be really useful too.
I wuold be happy to see it in the core of GRASS modules....
Massimiliano

Jachym Cepicky wrote:

On Tue, Nov 28, 2006 at 09:32:59AM +0100, Benjamin Ducke wrote:
  

While I would really like to see someone except for
myself use GEM, I think kriging is really core GIS
functionality and should be part of the base modules
set.
    
+1

Kriging is very importand and many people are asking for it. What do
other developer think? What about adding this module in future GRASS
7.0?

Jachym

I would also expect a lot of statistical modules in the
future to depend on R, seeing how powerful the R
spatial analysis stuff is.
There are so many useless dependencies in GRASS (Motif,
BLAS, LAPACK,...), so why not add one that is actually very
useful for a lot of people?

Or even better: why not include an up-to-date R shell and
the best spatial stat libraries in the GRASS base
distribution to make it easier for everyone to add
powerful spatial statistics modules to GRASS and use them
out-of-the-box?

I think R is excellent quality code that runs on all major
OS's and has no dependencies itself.

Benjamin

Michael Barton wrote:
    

Pierluigi,

Could you make these installable via GEM?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Pierluigi De Rosa <pierluigi.derosa@gfosservices.it>
Date: Mon, 27 Nov 2006 11:06:59 +0100
To: GRASS LIST <grassuser@grass.itc.it>
Subject: [GRASS-user] updating kriging modules for grass 62

Dear User,
I have updated on GRASS addons v.variogram anv v.krige run on spgrass6 >= 0.3
and sp >= 0.9
I created a new one module v.krige.cv to perform leave-one-out- Cross
Validation of variogram model. Obviously this modules have to be run before
v.krige.
I know my explanation is really short but if anyone is interested to this
modules and he wont to undestand better how they works please let me kwon it
and I will write a better tutorial
Pierluigi

--

Pierluigi De Rosa

GFosServices S.A.

--
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

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
    
  ------------------------------------------------------------------------

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--

Dr. Eng. Massimiliano Cannata
Responsabile Area Geomatica
Istituto Scienze della Terra
Scuola Universitaria Professionale della Svizzera Italiana
Via Trevano, c.p. 72
CH-6952 Canobbio-Lugano
Tel: +41 (0)58 666 62 14
Fax +41 (0)58 666 62 09

4

From: Jachym Cepicky <jachym.cepicky@centrum.cz>
Date: Tue, 28 Nov 2006 19:14:12 +0100
To: Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>
Cc: GRASS LIST <grassuser@grass.itc.it>, GRASS devel <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: [GRASS-user] updating kriging modules for grass
62

Kriging is very importand and many people are asking for it. What do
other developer think? What about adding this module in future GRASS
7.0?

Jachym

That's a +1 for me too.

I'd suggested GEM previously to make sure it was widely available to GRASS
users. Making it part of the main distribution is even better.

Why do we need to wait for GRASS 7?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

5

On 28/11/06 09:32, Benjamin Ducke wrote:

I would also expect a lot of statistical modules in the
future to depend on R, seeing how powerful the R
spatial analysis stuff is.
There are so many useless dependencies in GRASS (Motif,
BLAS, LAPACK,...), so why not add one that is actually very
useful for a lot of people?

Are you thinking about using the Mathlib of R within GRASS C-code, or of calling R commands from within GRASS modules or scripts ?

How easy is it to call fonctions from R libraries in non-R code ?

Or even better: why not include an up-to-date R shell and
the best spatial stat libraries in the GRASS base
distribution to make it easier for everyone to add
powerful spatial statistics modules to GRASS and use them
out-of-the-box?

Well you can run an R shell within GRASS, so what exactly do you mean by including one ?

I think R is excellent quality code that runs on all major
OS's and has no dependencies itself.

I agree and as we are working on a C-version of d.vect.thematic, and Roger referred me to R for potential relevant code, actually including R
in the dependencies might makes things easier. At this stage I just don't know enough of R internals to know what the best approach would be.

Moritz

6

On Wed, 29 Nov 2006, Moritz Lennert wrote:

On 28/11/06 09:32, Benjamin Ducke wrote:
> I would also expect a lot of statistical modules in the
> future to depend on R, seeing how powerful the R
> spatial analysis stuff is.
> There are so many useless dependencies in GRASS (Motif,
> BLAS, LAPACK,...), so why not add one that is actually very
> useful for a lot of people?

Are you thinking about using the Mathlib of R within GRASS C-code, or of
calling R commands from within GRASS modules or scripts ?

How easy is it to call fonctions from R libraries in non-R code ?

> Or even better: why not include an up-to-date R shell and
> the best spatial stat libraries in the GRASS base
> distribution to make it easier for everyone to add
> powerful spatial statistics modules to GRASS and use them
> out-of-the-box?

It isn't obvious how to do this in a clean and easily maintainable way. R
and the associated spatial packages are quite large, and perhaps ought to
be installed by users themselves when needed (understood as for use
running the R command line within GRASS and with the interface as an R
package).

On the other hand, an optional GRASS "module" might involve downloading
and installing R components in GRASS (under scripts, share, whatever),
where the R command line is not visible, and R is a compute engine behind
GRASS front-end(s). Now we have scripts in the Wiki, but the suggestion
that started this thread was to formalise them. In a medium-term future,
I'd see a place for the R engine being available as an *.so or *.DLL,
probably accessed from Python on the GRASS side through Rpy, although C
could also be used to pass in commands.

The maintenance aspect is important - the R engine "steps" twice a year,
and contributed packages - where the functionality is - can be updated
very frequently, sometimes with incompatibilities in function argument
names and types, updates triggered by bug reports and enhancement
requests. In making choices, getting the maintenance/update mode right
would be very important.

The Lausanne LiveCD worked very nicely because of a lot of hard work done
by the team who put it together, including R and its packages in
predictable places. It can be done, but I think the alternatives need
thinking through. I'm a bit reserved about having GRASS depend on R, and
until there is more experience with shell scripts handing computation off
to R would prefer not to "weld down the hood/bonnet".

Best wishes,

Roger

Well you can run an R shell within GRASS, so what exactly do you mean by
including one ?

>
> I think R is excellent quality code that runs on all major
> OS's and has no dependencies itself.

I agree and as we are working on a C-version of d.vect.thematic, and
Roger referred me to R for potential relevant code, actually including R
in the dependencies might makes things easier. At this stage I just
don't know enough of R internals to know what the best approach would be.

Moritz

--
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

7

I understand that R is evolving pretty quickly and that
everything, including the spatial libraries is in constant
flux.
So maybe we could make snapshots in intervals for inclusion
in GRASS?
E.g. we could take the current version 2.4 of R, add the
libraries for spatial analysis and provide some guidelines
for module authors as to what functions are stable and should
be used in GRASS-R modules.

From time to time, we would update the base R interpreter,

all libraries and modules.
We could include such snapshots in the GRASS distribution
or package everything as an "R spatial statistics" extension
to GRASS 6.2
For the later case, I could wrap up R, the spatial libraries,
documentation and modules like v.krige into one extension
package.

Benjamin

Roger Bivand wrote:

On Wed, 29 Nov 2006, Moritz Lennert wrote:

On 28/11/06 09:32, Benjamin Ducke wrote:

I would also expect a lot of statistical modules in the
future to depend on R, seeing how powerful the R
spatial analysis stuff is.
There are so many useless dependencies in GRASS (Motif,
BLAS, LAPACK,...), so why not add one that is actually very
useful for a lot of people?

Are you thinking about using the Mathlib of R within GRASS C-code, or of
calling R commands from within GRASS modules or scripts ?

How easy is it to call fonctions from R libraries in non-R code ?

Or even better: why not include an up-to-date R shell and
the best spatial stat libraries in the GRASS base
distribution to make it easier for everyone to add
powerful spatial statistics modules to GRASS and use them
out-of-the-box?

It isn't obvious how to do this in a clean and easily maintainable way. R
and the associated spatial packages are quite large, and perhaps ought to
be installed by users themselves when needed (understood as for use
running the R command line within GRASS and with the interface as an R
package).

On the other hand, an optional GRASS "module" might involve downloading
and installing R components in GRASS (under scripts, share, whatever),
where the R command line is not visible, and R is a compute engine behind
GRASS front-end(s). Now we have scripts in the Wiki, but the suggestion
that started this thread was to formalise them. In a medium-term future,
I'd see a place for the R engine being available as an *.so or *.DLL,
probably accessed from Python on the GRASS side through Rpy, although C
could also be used to pass in commands.

The maintenance aspect is important - the R engine "steps" twice a year,
and contributed packages - where the functionality is - can be updated
very frequently, sometimes with incompatibilities in function argument
names and types, updates triggered by bug reports and enhancement
requests. In making choices, getting the maintenance/update mode right
would be very important.

The Lausanne LiveCD worked very nicely because of a lot of hard work done
by the team who put it together, including R and its packages in
predictable places. It can be done, but I think the alternatives need
thinking through. I'm a bit reserved about having GRASS depend on R, and
until there is more experience with shell scripts handing computation off
to R would prefer not to "weld down the hood/bonnet".

Best wishes,

Roger

Well you can run an R shell within GRASS, so what exactly do you mean by
including one ?

I think R is excellent quality code that runs on all major
OS's and has no dependencies itself.

I agree and as we are working on a C-version of d.vect.thematic, and
Roger referred me to R for potential relevant code, actually including R
in the dependencies might makes things easier. At this stage I just
don't know enough of R internals to know what the best approach would be.

Moritz

--
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

8

As a start I would really really like to include "Launch QGIS" and
"Launch R" menus items in the GUI's "Xtns" menu* automatically.
That would encourage folks to explore. Some sort of GMT intergration
would be nice too.

[*] If the program wasn't found it should grey out the menu item (test
at gis startup to set a HAVE_QGIS variable: if [ -x `which qgis` ]
(whatever the tcl equivalent of that is)

On one hand I'd prefer binary packagers to use GEM to do this, on the
other hand this is a general need, needless duplication of effort, extra
work for the packagers...

A GEM package to enable this would be a cool first start.

Hamish

ps - I would suggest renaming the Xtns menu to "Extensions". It's easier
to understand, especially by non-english speakers who already have
enough work trying to decode the language anyway and IMO looks more
professional.