[GRASS-dev] Keywords in module descriptions

Markus_Neteler1 · August 17, 2006, 7:49pm

Hi,

a proposal for a better navigatable documentation of GRASS:
I would like to add

module->keywords = _("a, b, c, d");

to each command. These keywords would then
- automatically appear in each HTML/MAN page
- be content of the XML output by --interface-description
(maybe parsable then <keywords>a, b, c, d</keywords> for
automated GUI arranging?)
- probably made visible in the TclTk GUI if we want that
- visible in the "help" text, example:

r.cost help

Description:
Outputs a raster map layer showing the cumulative cost of moving between different geographic locations on an input raster map layer whose cell category values represent cost.

Keywords:
raster map, cost surface, cumulative costs

Usage:
r.cost [-vknr] input=name output=name [start_points=string]
   [stop_points=string] [start_rast=string] [coordinate=x,y[,x,y,...]]
   [stop_coordinate=x,y[,x,y,...]] [max_cost=cost] [null_cost=null cost]
   [percent_memory=percent memory] [--overwrite]

...

I have it running on my PC for r.cost.
With a sed job I could substitute all
module->description = ...

by
module->keywords = _("a, b, c, d");
module->description = ...
automatically.

Maybe we could make a Web application to visualize the keywords
like a navigatable tree or "TouchGraph" [1] or whatever appropriate.

Any objections?

Markus

[1] Just as an selfish example (needs Java):
http://www.citeulike.org/nocrawl/touchgraph_applet.adp?article_id=172900
(double click on the floating objects to navigate)

cmbarton · August 18, 2006, 5:02pm

Markus,

I think this is an excellent idea. If we get these keywords arranged right
(it will probably take some experimentation, but you might start with the
current menu hierarchy), it will not only help documentation but could serve
as the basis for an autogenerated menu/toolbox.

Michale
__________________________________________
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: Markus Neteler <neteler@itc.it>
Date: Thu, 17 Aug 2006 21:49:32 +0200
To: GRASS developers list <grass-dev@grass.itc.it>
Subject: [GRASS-dev] Keywords in module descriptions

Hi,

a proposal for a better navigatable documentation of GRASS:
I would like to add

    module->keywords = _("a, b, c, d");

to each command. These keywords would then
- automatically appear in each HTML/MAN page
- be content of the XML output by --interface-description
  (maybe parsable then <keywords>a, b, c, d</keywords> for
   automated GUI arranging?)
- probably made visible in the TclTk GUI if we want that
- visible in the "help" text, example:

r.cost help

Description:
Outputs a raster map layer showing the cumulative cost of moving between
different geographic locations on an input raster map layer whose cell
category values represent cost.

Keywords:
raster map, cost surface, cumulative costs

Usage:
r.cost [-vknr] input=name output=name [start_points=string]
   [stop_points=string] [start_rast=string] [coordinate=x,y[,x,y,...]]
   [stop_coordinate=x,y[,x,y,...]] [max_cost=cost] [null_cost=null cost]
   [percent_memory=percent memory] [--overwrite]

...

I have it running on my PC for r.cost.
With a sed job I could substitute all
   module->description = ...

by
   module->keywords = _("a, b, c, d");
   module->description = ...
automatically.

Maybe we could make a Web application to visualize the keywords
like a navigatable tree or "TouchGraph" [1] or whatever appropriate.

Any objections?

Markus

[1] Just as an selfish example (needs Java):
    http://www.citeulike.org/nocrawl/touchgraph_applet.adp?article_id=172900
    (double click on the floating objects to navigate)

Trevor_Wiens2 · August 19, 2006, 3:41am

On Fri, 18 Aug 2006 10:02:37 -0700
Michael Barton <michael.barton@asu.edu> wrote:

Markus,

I think this is an excellent idea. If we get these keywords arranged right
(it will probably take some experimentation, but you might start with the
current menu hierarchy), it will not only help documentation but could serve
as the basis for an autogenerated menu/toolbox.

For searching it would be invaluable. I also like Michael's thinking
about a way to approach this problem of organizing the vast number of
modules we have. If seen as a method for this organization of a menu /
toolbox, then it might be advisable to come up with a formal list of
keywords that all modules will need to include at least one or two
(depending on how this is organized) as well as any others to help in
searching.

T

Michale
__________________________________________
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: Markus Neteler <neteler@itc.it>
> Date: Thu, 17 Aug 2006 21:49:32 +0200
> To: GRASS developers list <grass-dev@grass.itc.it>
> Subject: [GRASS-dev] Keywords in module descriptions
>
> Hi,
>
> a proposal for a better navigatable documentation of GRASS:
> I would like to add
>
> module->keywords = _("a, b, c, d");
>
> to each command. These keywords would then
> - automatically appear in each HTML/MAN page
> - be content of the XML output by --interface-description
> (maybe parsable then <keywords>a, b, c, d</keywords> for
> automated GUI arranging?)
> - probably made visible in the TclTk GUI if we want that
> - visible in the "help" text, example:
>
> r.cost help
>
> Description:
> Outputs a raster map layer showing the cumulative cost of moving between
> different geographic locations on an input raster map layer whose cell
> category values represent cost.
>
> Keywords:
> raster map, cost surface, cumulative costs
>
> Usage:
> r.cost [-vknr] input=name output=name [start_points=string]
> [stop_points=string] [start_rast=string] [coordinate=x,y[,x,y,...]]
> [stop_coordinate=x,y[,x,y,...]] [max_cost=cost] [null_cost=null cost]
> [percent_memory=percent memory] [--overwrite]
>
> ...
>
> I have it running on my PC for r.cost.
> With a sed job I could substitute all
> module->description = ...
>
> by
> module->keywords = _("a, b, c, d");
> module->description = ...
> automatically.
>
> Maybe we could make a Web application to visualize the keywords
> like a navigatable tree or "TouchGraph" [1] or whatever appropriate.
>
> Any objections?
>
> Markus
>
> [1] Just as an selfish example (needs Java):
> http://www.citeulike.org/nocrawl/touchgraph_applet.adp?article_id=172900
> (double click on the floating objects to navigate)
>
>

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

--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

Markus_Neteler1 · August 19, 2006, 1:50pm

Hi,

I have added the keywords now in GRASS 6.3-CVS.
Each command has at least 1 keyword. We need to add
more of course, but they should be selected from a list
or so to avoid that identical things get different
keywords. Here the Wiki may be of use.

I have also updated all scripts for keyword support.

So far I didn't touch the TclTk interface to make
the keywords visible. I am not sure if this is really
desired.

Next week the HTML Web pages will contain the keywords.

Please extend them, it's simply done by adding them:

- in C programs:
module->keywords = _("a, b, ...");

- in shell scripts:
keywords: a, b, ...

Question: Should I apply the patch to GRASS 6.2-release branch
as well?

Enjoy,

Markus

On Thu, Aug 17, 2006 at 09:49:32PM +0200, Markus Neteler wrote:

Hi,

a proposal for a better navigatable documentation of GRASS:
I would like to add

    module->keywords = _("a, b, c, d");

to each command. These keywords would then
- automatically appear in each HTML/MAN page
- be content of the XML output by --interface-description
  (maybe parsable then <keywords>a, b, c, d</keywords> for
   automated GUI arranging?)
- probably made visible in the TclTk GUI if we want that
- visible in the "help" text, example:

r.cost help

Description:
Outputs a raster map layer showing the cumulative cost of moving between different geographic locations on an input raster map layer whose cell category values represent cost.

Keywords:
raster map, cost surface, cumulative costs

Usage:
r.cost [-vknr] input=name output=name [start_points=string]
   [stop_points=string] [start_rast=string] [coordinate=x,y[,x,y,...]]
   [stop_coordinate=x,y[,x,y,...]] [max_cost=cost] [null_cost=null cost]
   [percent_memory=percent memory] [--overwrite]

...

I have it running on my PC for r.cost.
With a sed job I could substitute all
   module->description = ...

by
   module->keywords = _("a, b, c, d");
   module->description = ...
automatically.

Maybe we could make a Web application to visualize the keywords
like a navigatable tree or "TouchGraph" [1] or whatever appropriate.

Any objections?

Markus

[1] Just as an selfish example (needs Java):
    http://www.citeulike.org/nocrawl/touchgraph_applet.adp?article_id=172900
    (double click on the floating objects to navigate)

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

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

Yann4 · August 20, 2006, 11:08am

This is great for auto-generation of menus, but also to try to find a
tool we dont know the name but we know what it should do.

On 19/08/06, Markus Neteler <neteler@itc.it> wrote:

Hi,

I have added the keywords now in GRASS 6.3-CVS.
Each command has at least 1 keyword. We need to add
more of course, but they should be selected from a list
or so to avoid that identical things get different
keywords. Here the Wiki may be of use.

I have also updated all scripts for keyword support.

So far I didn't touch the TclTk interface to make
the keywords visible. I am not sure if this is really
desired.

Next week the HTML Web pages will contain the keywords.

Please extend them, it's simply done by adding them:

- in C programs:
module->keywords = _("a, b, ...");

- in shell scripts:
keywords: a, b, ...

Question: Should I apply the patch to GRASS 6.2-release branch
as well?

Enjoy,

Markus

On Thu, Aug 17, 2006 at 09:49:32PM +0200, Markus Neteler wrote:
> Hi,
>
> a proposal for a better navigatable documentation of GRASS:
> I would like to add
>
> module->keywords = _("a, b, c, d");
>
> to each command. These keywords would then
> - automatically appear in each HTML/MAN page
> - be content of the XML output by --interface-description
> (maybe parsable then <keywords>a, b, c, d</keywords> for
> automated GUI arranging?)
> - probably made visible in the TclTk GUI if we want that
> - visible in the "help" text, example:
>
> r.cost help
>
> Description:
> Outputs a raster map layer showing the cumulative cost of moving between different geographic locations on an input raster map layer whose cell category values represent cost.
>
> Keywords:
> raster map, cost surface, cumulative costs
>
> Usage:
> r.cost [-vknr] input=name output=name [start_points=string]
> [stop_points=string] [start_rast=string] [coordinate=x,y[,x,y,...]]
> [stop_coordinate=x,y[,x,y,...]] [max_cost=cost] [null_cost=null cost]
> [percent_memory=percent memory] [--overwrite]
>
> ...
>
> I have it running on my PC for r.cost.
> With a sed job I could substitute all
> module->description = ...
>
> by
> module->keywords = _("a, b, c, d");
> module->description = ...
> automatically.
>
> Maybe we could make a Web application to visualize the keywords
> like a navigatable tree or "TouchGraph" [1] or whatever appropriate.
>
> Any objections?
>
> Markus
>
> [1] Just as an selfish example (needs Java):
> http://www.citeulike.org/nocrawl/touchgraph_applet.adp?article_id=172900
> (double click on the floating objects to navigate)
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

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

Joel_Pitt · August 20, 2006, 11:43am

Hi,

Nice idea.

At the very least I think adding "raster" or "vector" keywords is an
easily scriptable addition. Plus for those modules that import data
"input" would be useful and similarly "output".

Cheers

On 8/20/06, Markus Neteler <neteler@itc.it> wrote:

Hi,

I have added the keywords now in GRASS 6.3-CVS.
Each command has at least 1 keyword. We need to add
more of course, but they should be selected from a list
or so to avoid that identical things get different
keywords. Here the Wiki may be of use.

I have also updated all scripts for keyword support.

So far I didn't touch the TclTk interface to make
the keywords visible. I am not sure if this is really
desired.

Next week the HTML Web pages will contain the keywords.

Please extend them, it's simply done by adding them:

- in C programs:
module->keywords = _("a, b, ...");

- in shell scripts:
keywords: a, b, ...

Question: Should I apply the patch to GRASS 6.2-release branch
as well?

Enjoy,

Markus

On Thu, Aug 17, 2006 at 09:49:32PM +0200, Markus Neteler wrote:
> Hi,
>
> a proposal for a better navigatable documentation of GRASS:
> I would like to add
>
> module->keywords = _("a, b, c, d");
>
> to each command. These keywords would then
> - automatically appear in each HTML/MAN page
> - be content of the XML output by --interface-description
> (maybe parsable then <keywords>a, b, c, d</keywords> for
> automated GUI arranging?)
> - probably made visible in the TclTk GUI if we want that
> - visible in the "help" text, example:
>
> r.cost help
>
> Description:
> Outputs a raster map layer showing the cumulative cost of moving between different geographic locations on an input raster map layer whose cell category values represent cost.
>
> Keywords:
> raster map, cost surface, cumulative costs
>
> Usage:
> r.cost [-vknr] input=name output=name [start_points=string]
> [stop_points=string] [start_rast=string] [coordinate=x,y[,x,y,...]]
> [stop_coordinate=x,y[,x,y,...]] [max_cost=cost] [null_cost=null cost]
> [percent_memory=percent memory] [--overwrite]
>
> ...
>
> I have it running on my PC for r.cost.
> With a sed job I could substitute all
> module->description = ...
>
> by
> module->keywords = _("a, b, c, d");
> module->description = ...
> automatically.
>
> Maybe we could make a Web application to visualize the keywords
> like a navigatable tree or "TouchGraph" [1] or whatever appropriate.
>
> Any objections?
>
> Markus
>
> [1] Just as an selfish example (needs Java):
> http://www.citeulike.org/nocrawl/touchgraph_applet.adp?article_id=172900
> (double click on the floating objects to navigate)
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

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

--
-Joel

"Wish not to seem, but to be, the best."
-- Aeschylus

Markus_Neteler1 · August 20, 2006, 1:01pm

On Sun, Aug 20, 2006 at 11:43:56PM +1200, Joel Pitt wrote:

Hi,

Nice idea.

At the very least I think adding "raster" or "vector" keywords is an
easily scriptable addition.

This I have already done.

Plus for those modules that import data
"input" would be useful and similarly "output".

Right.

*.in.*: import
*.out.*: export
etc

Volunteers (patches) welcome...

Markus

H_B · August 23, 2006, 7:32am

Markus wrote:

I have added the keywords now in GRASS 6.3-CVS.
Each command has at least 1 keyword.

Sorry if I am thick, but in the age of Google what's the point of
defining keywords?

Dynamic self-organization of menu items (even if that's a good idea)
should probably get their own hinting mechanism.

Is giving each r.* module the "raster" keyword really needed?
Or giving each "*.in.*" an "input" keyword?

(answering self) I guess GUI users often don't see the module names or
know the m.in.* meanings.

one that comes to mind is the "Thiessen polygons" for v.voronoi.

We need to add more of course, but they should be selected from a list
or so to avoid that identical things get different keywords. Here the
Wiki may be of use.

For keywords to be useful, the list needs to be well planned and tightly
enforced, IMO.

Question: Should I apply the patch to GRASS 6.2-release branch
as well?

My vote would be "no". A lot of work to backport and result will be
only slightly finished by the time 6.2 is released, which looks bad and
a half-done list isn't nearly as useful (can't trust a keyword search).
I don't mind them in 6.3 if others think they are useful.. I'd just like
to hear a real example of how they would be used. e.g. could they help
with a Google ranking so a man page comes before a mailing list question?

Hamish

> a proposal for a better navigatable documentation of GRASS:
> I would like to add
>
> module->keywords = _("a, b, c, d");
>
> to each command. These keywords would then
> - automatically appear in each HTML/MAN page
> - be content of the XML output by --interface-description
> (maybe parsable then <keywords>a, b, c, d</keywords> for
> automated GUI arranging?)
> - probably made visible in the TclTk GUI if we want that
> - visible in the "help" text, example:
>
> r.cost help
>
> Description:
> Outputs a raster map layer showing the cumulative cost of moving
> between different geographic locations on an input raster map layer
> whose cell category values represent cost.
>
> Keywords:
> raster map, cost surface, cumulative costs
>
> Usage:
> r.cost [-vknr] input=name output=name [start_points=string]
> [stop_points=string] [start_rast=string]
> [coordinate=x,y[,x,y,...]] [stop_coordinate=x,y[,x,y,...]]
> [max_cost=cost] [null_cost=null cost] [percent_memory=percent
> memory] [--overwrite]
>
> ...
>
> I have it running on my PC for r.cost.
> With a sed job I could substitute all
> module->description = ...
>
> by
> module->keywords = _("a, b, c, d");
> module->description = ...
> automatically.
>
> Maybe we could make a Web application to visualize the keywords
> like a navigatable tree or "TouchGraph" [1] or whatever appropriate.
>
> Any objections?
>
> Markus
>
> [1] Just as an selfish example (needs Java):
> http://www.citeulike.org/nocrawl/touchgraph_applet.adp?article_id=172900
> (double click on the floating objects to navigate)

Markus_Neteler1 · August 23, 2006, 8:17am

On Wed, Aug 23, 2006 at 07:32:16PM +1200, Hamish wrote:

Markus wrote:
> I have added the keywords now in GRASS 6.3-CVS.
> Each command has at least 1 keyword.

Sorry if I am thick, but in the age of Google what's the point of
defining keywords?

Call it "tag" for a modernized version
Everybody is tagging nowadays.

Dynamic self-organization of menu items (even if that's a good idea)
should probably get their own hinting mechanism.

Is giving each r.* module the "raster" keyword really needed?
Or giving each "*.in.*" an "input" keyword?

This is what could be completely automated.

(answering self) I guess GUI users often don't see the module names or
know the m.in.* meanings.

one that comes to mind is the "Thiessen polygons" for v.voronoi.

right, please submit!

> We need to add more of course, but they should be selected from a list
> or so to avoid that identical things get different keywords. Here the
> Wiki may be of use.

For keywords to be useful, the list needs to be well planned and tightly
enforced, IMO.

yes, as suggested.

> Question: Should I apply the patch to GRASS 6.2-release branch
> as well?

My vote would be "no". A lot of work to backport and result will be
only slightly finished by the time 6.2 is released, which looks bad and
a half-done list isn't nearly as useful (can't trust a keyword search).

Sorry, too late. 30 minutes ago I have submitted it. The main reason was to
not make backporting of changes from > 6.2 a continuous pain. I have already
submitted twice changes where the keywords creeped it (and then broke the release
branch). Now this cannot happen any more. And there weren't any negative
responses so far. Luckily the keyword search isn't implemented at all and
could be limited to 6.3. Also adding more in 6.2 isn't a big deal.

Feel free to revert.

I don't mind them in 6.3 if others think they are useful.. I'd just like
to hear a real example of how they would be used. e.g. could they help
with a Google ranking so a man page comes before a mailing list question?

Example:
The HTML man pages could use the keyword as metatag which hopefully
improves the ranking. Things can grow in my opinion.

Markus

Hamish

> > a proposal for a better navigatable documentation of GRASS:
> > I would like to add
> >
> > module->keywords = _("a, b, c, d");
> >
> > to each command. These keywords would then
> > - automatically appear in each HTML/MAN page
> > - be content of the XML output by --interface-description
> > (maybe parsable then <keywords>a, b, c, d</keywords> for
> > automated GUI arranging?)
> > - probably made visible in the TclTk GUI if we want that
> > - visible in the "help" text, example:
> >
> > r.cost help
> >
> > Description:
> > Outputs a raster map layer showing the cumulative cost of moving
> > between different geographic locations on an input raster map layer
> > whose cell category values represent cost.
> >
> > Keywords:
> > raster map, cost surface, cumulative costs
> >
> > Usage:
> > r.cost [-vknr] input=name output=name [start_points=string]
> > [stop_points=string] [start_rast=string]
> > [coordinate=x,y[,x,y,...]] [stop_coordinate=x,y[,x,y,...]]
> > [max_cost=cost] [null_cost=null cost] [percent_memory=percent
> > memory] [--overwrite]
> >
> > ...
> >
> > I have it running on my PC for r.cost.
> > With a sed job I could substitute all
> > module->description = ...
> >
> > by
> > module->keywords = _("a, b, c, d");
> > module->description = ...
> > automatically.
> >
> > Maybe we could make a Web application to visualize the keywords
> > like a navigatable tree or "TouchGraph" [1] or whatever appropriate.
> >
> > Any objections?
> >
> > Markus
> >
> > [1] Just as an selfish example (needs Java):
> > http://www.citeulike.org/nocrawl/touchgraph_applet.adp?article_id=172900
> > (double click on the floating objects to navigate)

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

H_B · August 23, 2006, 8:18am

Markus Neteler <neteler@itc.it> wrote:

> Plus for those modules that import data
> "input" would be useful and similarly "output".

Right.

*.in.*: import
*.out.*: export
etc

I see the keywords were just backported to 6.2. (I don't really mind
that)

*.to.* modules: conversion
???

After obvious scripted keywords are added, perhaps set up a web-input
page, with module names from the master help page list, so users can
submit keyword suggestions. That could be written to a text file on a
server (after auto-clean/length/alpha check) and later parsed for
addition-by-script? Might help spread the devel load for this.

Hamish

H_B · August 23, 2006, 9:10am

> Sorry if I am thick, but in the age of Google what's the point of
> defining keywords?

Call it "tag" for a modernized version
Everybody is tagging nowadays.

maybe so, but what's the reason? There are lots of moves to the XML-
ificaition of everything these days as well, but I don't always see a
purpose in doing that for everything either.

Sorry, too late. 30 minutes ago I have submitted it. The main reason
was to not make backporting of changes from > 6.2 a continuous pain.

no worries. I am not really against them or trying to be negative. I am
just trying to understand how keywords can be used before deciding to
spend time working on them.

Feel free to revert.

I won't.

Example:
The HTML man pages could use the keyword as metatag which hopefully
improves the ranking.

ok.

fyi, http://www.google.com/support/webmasters/bin/answer.py?answer=34434&topic=8523
"We do not manually assign keywords to sites, nor can webmasters submit
a list of preferred keywords for which their sites will appear."

Hamish

Markus_Neteler1 · August 23, 2006, 9:23am

On Wed, Aug 23, 2006 at 09:10:20PM +1200, Hamish wrote:

> > Sorry if I am thick, but in the age of Google what's the point of
> > defining keywords?
>
> Call it "tag" for a modernized version
> Everybody is tagging nowadays.

maybe so, but what's the reason? There are lots of moves to the XML-
ificaition of everything these days as well, but I don't always see a
purpose in doing that for everything either.

The whole idea was triggered again by user mails where people
found it hard to find the right command.

Examples
- d.grid vs v.mkgrid
- d.rgb vs r.composite
- the group of the topology vector tools
- one click to find all import modules
- find all vector|raster statistic tools
- find all aggregation tools

the latter aren't easily found just using a search engine.

> Sorry, too late. 30 minutes ago I have submitted it. The main reason
> was to not make backporting of changes from > 6.2 a continuous pain.

no worries. I am not really against them or trying to be negative. I am
just trying to understand how keywords can be used before deciding to
spend time working on them.

> Feel free to revert.

I won't.

> Example:
> The HTML man pages could use the keyword as metatag which hopefully
> improves the ranking.

ok.

fyi, http://www.google.com/support/webmasters/bin/answer.py?answer=34434&topic=8523
"We do not manually assign keywords to sites, nor can webmasters submit
a list of preferred keywords for which their sites will appear."

No problem for me

I was thinking of
<meta name="keywords" content="...">
http://www.w3.org/TR/html4/appendix/notes.html#h-B.4
http://www.w3.org/TR/html4/struct/global.html#edef-META

Markus