[GRASSLIST:4259] Releasing GRASS modules

GRASS GRASS user
1

I would like to release some GPL'd GRASS 5.3 modules
for spatial predictvie modelling into
the GRASS community. My questions are:

1. is there a way to set up a Gmakefile so that HTML
  manpages are merged into the GRASS documentation index?
  The way it is right now, the HTML pages get copied into
  the user's documentation/html directory, but there are
  no links from the main index.html file so that the user
  is left to point his webbrowser to the files explicitly.

2. once other people have tried and tested the modules
  and find them useful, is it possible to include them
  into the 5.3 CVS, so that people will not have to
  download the source from my homepage and have to install
  separately?

Cheers,

Benjamin.

2

On Thu, 26 Aug 2004, Benjamin Ducke wrote:

I would like to release some GPL'd GRASS 5.3 modules
for spatial predictvie modelling into
the GRASS community. My questions are:

1. is there a way to set up a Gmakefile so that HTML
manpages are merged into the GRASS documentation index?
The way it is right now, the HTML pages get copied into
the user's documentation/html directory, but there are
no links from the main index.html file so that the user
is left to point his webbrowser to the files explicitly.

No; this index is just maintained manually. Note that all the files in the html/html directory are converted into man pages during compilation so that you can read them with g.manual. This isn't done for 5.7 (although I
wish it was), which just has html pages.

2. once other people have tried and tested the modules
and find them useful, is it possible to include them
into the 5.3 CVS, so that people will not have to
download the source from my homepage and have to install
separately?

There will be no new modules in the 5.3 CVS before the 5.4.0 release. Do the modules use any special features of 5.3 that mean they can't be used directly or easily ported to 5.7?

Perhaps if things drag on for a long time, after the 5.4.0 release the
modules could be added to the '5.5 CVS', but CVS write access to that is
going to be closed so you would not be able to commit bugfixes. Better to
add them to 5.7 I think.

Paul

3

On Fri, Aug 27, 2004 at 12:18:22AM +0100, Paul Kelly wrote:

On Thu, 26 Aug 2004, Benjamin Ducke wrote:

>I would like to release some GPL'd GRASS 5.3 modules
>for spatial predictvie modelling into
>the GRASS community. My questions are:
>
>1. is there a way to set up a Gmakefile so that HTML
> manpages are merged into the GRASS documentation index?
> The way it is right now, the HTML pages get copied into
> the user's documentation/html directory, but there are
> no links from the main index.html file so that the user
> is left to point his webbrowser to the files explicitly.

No; this index is just maintained manually.

Note:
In GRASS 5.7 the index is generated automatically.
Any compile program appears in the index.

Note that all the files in the
html/html directory are converted into man pages during compilation so
that you can read them with g.manual. This isn't done for 5.7 (although I
wish it was), which just has html pages.

Should be no big story (g.html2man, using code from grass53/html/Gmakefile).

>2. once other people have tried and tested the modules
> and find them useful, is it possible to include them
> into the 5.3 CVS, so that people will not have to
> download the source from my homepage and have to install
> separately?

There will be no new modules in the 5.3 CVS before the 5.4.0 release.

Do you foresee the release date?

Do the modules use any special features of 5.3 that mean they can't be used
directly or easily ported to 5.7?

Perhaps if things drag on for a long time, after the 5.4.0 release the
modules could be added to the '5.5 CVS', but CVS write access to that is
going to be closed so you would not be able to commit bugfixes. Better to
add them to 5.7 I think.

Paul

Markus

4

Benjamin,

I am excited to hear about the predictive modeling modules you are
developing. This is an excellent use of GRASS for archaeology, as well as
other natural science fields that can use this.

I agree with Paul about encouraging you to write for 5.7. The raster format
for 5.3 and 5.7 are the same. There seems to be little needed to make a
raster module 5.7 'compliant'. And raster modules that work in 5.7 also work
in 5.3.

Vectors and sites are a different story of course. However, the linked
multi-attribute tables of GRASS 5.7 vectors make them much more flexible
than the 5.3 vector model. Vector points in 5.7 likewise have greater
potential than ascii sites in 5.3.

I am looking forward to seeing these modules.

Michael

On 8/26/04 4:18 PM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

On Thu, 26 Aug 2004, Benjamin Ducke wrote:

I would like to release some GPL'd GRASS 5.3 modules
for spatial predictvie modelling into
the GRASS community. My questions are:

1. is there a way to set up a Gmakefile so that HTML
manpages are merged into the GRASS documentation index?
The way it is right now, the HTML pages get copied into
the user's documentation/html directory, but there are
no links from the main index.html file so that the user
is left to point his webbrowser to the files explicitly.

No; this index is just maintained manually. Note that all the files in the
html/html directory are converted into man pages during compilation so
that you can read them with g.manual. This isn't done for 5.7 (although I
wish it was), which just has html pages.

2. once other people have tried and tested the modules
and find them useful, is it possible to include them
into the 5.3 CVS, so that people will not have to
download the source from my homepage and have to install
separately?

There will be no new modules in the 5.3 CVS before the 5.4.0 release. Do
the modules use any special features of 5.3 that mean they can't be used
directly or easily ported to 5.7?

Perhaps if things drag on for a long time, after the 5.4.0 release the
modules could be added to the '5.5 CVS', but CVS write access to that is
going to be closed so you would not be able to commit bugfixes. Better to
add them to 5.7 I think.

Paul

____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

5

On Fri, 27 Aug 2004 00:18:22 +0100 (BST)
Paul Kelly <paul-grass@stjohnspoint.co.uk> wrote:

On Thu, 26 Aug 2004, Benjamin Ducke wrote:

> I would like to release some GPL'd GRASS 5.3 modules
> for spatial predictvie modelling into
> the GRASS community. My questions are:
>
> 1. is there a way to set up a Gmakefile so that HTML
> manpages are merged into the GRASS documentation index?
> The way it is right now, the HTML pages get copied into
> the user's documentation/html directory, but there are
> no links from the main index.html file so that the user
> is left to point his webbrowser to the files explicitly.

No; this index is just maintained manually. Note that all the files in the
html/html directory are converted into man pages during compilation so
that you can read them with g.manual. This isn't done for 5.7 (although I
wish it was), which just has html pages.

OK, so I take it there is no way to merge documentation automatically
for external modules in 5.3.

> 2. once other people have tried and tested the modules
> and find them useful, is it possible to include them
> into the 5.3 CVS, so that people will not have to
> download the source from my homepage and have to install
> separately?

There will be no new modules in the 5.3 CVS before the 5.4.0 release. Do
the modules use any special features of 5.3 that mean they can't be used
directly or easily ported to 5.7?

I make use of the site data format for representing the locations of known
objects. It should not be too much work to convert that to vector points
for 5.7 but I will have to find some time to do it.
Does 5.7 still include the site full sites API?

Perhaps if things drag on for a long time, after the 5.4.0 release the
modules could be added to the '5.5 CVS', but CVS write access to that is
going to be closed so you would not be able to commit bugfixes. Better to
add them to 5.7 I think.

I guess so. In the meantime I might set up a homepage of my own to distribute
my code. In the meantim, if anyone here is really interested in it, contact me
and I will send it to you via email.

Benjamin

6

Hello Benjamin,

could you explain briefly which methods you are using for your modules
(statistical methods like GAM, ANN)? Is it comparable to GRASP
(http://www.cscf.ch/grasp/grasp-r/index.html) - unfortunately not fully
implemented in GRASS (no easy export of raster to GRASP) - it sounds very
promising and I am looking forward to give it a try.

cheers Martin

[....]

I guess so. In the meantime I might set up a homepage of my own to
distribute my code. In the meantim, if anyone here is really interested in
it, contact me and I will send it to you via email.

Benjamin

7

Sure, here are some details:

The modules are a by-product of my work in an archaeological
predictive modelling project in North-east Germany.
Over a period of four years, I tried different approaches,
like regression statistics, geostatistics, explorative statistics,
neural networks classification and probability theory.

I finally settled for Dempster-Shafer Theory (DST) as a mathematical
framework. DST is a very flexible sort of generalised probabilit
theory.
With DST, the user first sets up a frame of hypotheses to check.
Next, he/she has to supply evidences that support one or several
of these hypotheses. Evidence is quantified using a basic probability
assignment (BPA). It is up to the user to define just how exactly
this has to be done.
Finally, all evidences are combined and a final "belief" value
is calculated for each hypothesis. Other useful metrics can be
calculated as well.
In theory, DST can be used for much more than just predictive modelling
and so can my modules.
But the tools are most straight-forward to use in predictive models,
were BPA calculation is easy and the frame of reference consists
only of two hypotheses ('SITE PRESENT' and 'NO SITE PRESENT').

DST also handles uncertainty, represented by the hypotheses set
{'SITE PRESENT', 'NO SITE PRESENT')} were you cannot decide between
the two.
It makes no assumptions about probability distributions and is
memory efficient (ran it with several thousand sites and
many millions of raster cells on a machine with 256MB RAM).

The tools also include modules for random sampling and
automatic generation of raster categories given interval width
or number (sth. that was asked for in the last GRASS newsletter,
if I remember right).

If you want to know more about belief-based modelling, read:

http://gis.esri.com/library/userconf/proc99/proceed/papers/pap295/p295.htm

and

http://websrv5.sdu.dk/ejstrud/forskning.html

On Fri, 27 Aug 2004 15:46:15 +0200
Martin Wegmann <wegmann@biozentrum.uni-wuerzburg.de> wrote:

Hello Benjamin,

could you explain briefly which methods you are using for your modules
(statistical methods like GAM, ANN)? Is it comparable to GRASP
(http://www.cscf.ch/grasp/grasp-r/index.html) - unfortunately not fully
implemented in GRASS (no easy export of raster to GRASP) - it sounds very
promising and I am looking forward to give it a try.

cheers Martin

[....]
> I guess so. In the meantime I might set up a homepage of my own to
> distribute my code. In the meantim, if anyone here is really interested in
> it, contact me and I will send it to you via email.
>
> Benjamin

(attachments)

grassDST53-1.0.tar.gz (116 KB)

8

On Friday 27 August 2004 15:12, Benjamin Ducke wrote:

Does 5.7 still include the site full sites API?

There is sites API in 5.7, but it reads points + attributes
from vector maps. Using this API it is very easy to port old s.*
modules. s.in/out.ascii in 5.7 are examples how to port old modules.
You have to use for example gisprompt = "old,vector,vector";
This is not prefered way how to update modules, it is better
to use vector API.

Radim

9

Benjamin,

I forgot to ask you about your algorithm, but I saw the post to someone else
with the same question. As a followup, is this only a deductive predictive
modeling algorithm or can it also do inductive? I am interested in a variant
of inductive modeling for an upcoming project because I am trying to model
overall site distribution/density in various topographic settings rather
than derive a prediction of where sites are most likely.

Michael

____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

10

Hmmmm, deductive, inductive, to tell you the truth,
I think every solid model involves both a data-driven,
inductive and a theory-based deductive approach.
After having been in the predictive modelling business
for almost five years, I can't see much sense in this
artifical separation any longer, especially since
the whole debatte seems to be going on only in archaeology.

Anyway, my modules allow you to put any amount of
inductive or deductive reasoning into your model
depending on how you quantify the evidence.
If you just go with the basic predictive modelling
tools provided, you will get a data-driven model
by default, but you can put any amount of a-priori
knowledge into it.

Please read the documentaion that comes with the
modules to see how this works.

For your purpose it seems to me all you need to do is
some surveying after running the model to establish
a regression equation for model (belief) output
vs. site density.

Cheers,

Benjamin

On Mon, 30 Aug 2004 20:51:32 -0700
Michael Barton <michael.barton@asu.edu> wrote:

Benjamin,

I forgot to ask you about your algorithm, but I saw the post to someone else
with the same question. As a followup, is this only a deductive predictive
modeling algorithm or can it also do inductive? I am interested in a variant
of inductive modeling for an upcoming project because I am trying to model
overall site distribution/density in various topographic settings rather
than derive a prediction of where sites are most likely.

Michael

____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

(attachments)

grassDST53-1.0.tar.gz (116 KB)