Thematic grouping of grass modules in the command line

[nikos]

Some weeks ago I started grouping the grass (raster) modules in order to have a rough overview table of "what is there to use and for what". I find the grouping of the modules in the GUI good. But I would like some helpful commands in the CL.

1. Is it feasible to have some sort of another (deeper) level of grouping (of the grass-modules)?
   Something like a "thematic" grouping (see atached .csv file).

2. Would it be useful to have commands that will list available modules for a specific "group"? For example, I want to get listed all modules that are related directly with "landscape analysis" or to know which modules are available for "statistical analysis".

The following naming(s) are just ideas... :-)

For example:

# listing "groups of modules"
g.list -c(ategories)

import
metadata manipulation
queries
categories/classes/codes
editing
pre-processing
resampling
conversion
processing
topographic analysis (+ surface + volume...)
statistics
irradiation
agro(...)
hydrological modelling
landscape analysis
validation
export

# listing the "statistics" group
g.listmod -stat(istics)
# etc. Use your imagination & logic for more names/groups

3. What speaks against those ideas?

Kind Regards, Nikos

[nikos]

attempting to group the grass raster modules

[marisn]

This idea is not new and it's partly implemented as keywords. Many GRASS modules are universal and thus keyword approach fits better. Only current issue is lack of user-visible/friendly keyword list/search etc. infrastructure.

[martinl]

Replying to marisn:

Only current issue is lack of user-visible/friendly keyword list/search etc. infrastructure.

yes, such kind of search engine is part of wxGUI roadmap, any volunteer? ;-)

[hamish]

Replying to nikos:

2. Would it be useful to have commands that will list available modules for a specific "group"? For example, I want to get listed all modules that are related directly with "landscape analysis" or to know which modules are available for "statistical analysis".

e.g. the GUI menu grouping? (module names given in the status line)

Hamish

[nikos]

Replying to hamish:

Replying to nikos:

2. Would it be useful to have commands that will list available modules for a specific "group"? For example, I want to get listed all modules that are related directly with "landscape analysis" or to know which modules are available for "statistical analysis".

e.g. the GUI menu grouping? (module names given in the status line)

Hamish

Well, it's true the "groups" are there. Why starting from scratch? It will also make easier the transition from the GUI to the CLI (for those who are thirsty to learn to use the CL) ;-)

Though, I might file another ticket for a few changes concerning the grouping of modules in the GUI's menu(s). It gives sometimes an *overloaded* feeling.

Thanks to all for your time to respond.

Nikos

[neteler]

See this prototype for topic oriented command grouping using keyword extraction:

​http://gis.cri.fmach.it/download/grass_html/topics.html

[lucadelu]

I committed in r52931 a python script to fix this for grass7. It works with the second keyword of documentation, maybe we should use also the third. It is impossible to backported this script to grass6 so or we change the milestone to 7.0.0 and sign as fixed or someone as to convert it to bash script. You can see a preview here

​http://geodati.fmach.it/grass70/topics.html

next week you should see it also in the main grass70 documentation.

[martinl]

Replying to neteler:

See this prototype for topic oriented command grouping using keyword extraction:

​http://gis.cri.fmach.it/download/grass_html/topics.html

cool! very useful... Martin

[neteler]

It is now part of standard GRASS 7:

​http://grass.osgeo.org/grass70/manuals/html70_user/topics.html

[lucadelu]

Do you think that Topics link should be also in the bottom of every command as "Main index"/"Full index" ?

[neteler]

Replying to lucadelu:

Do you think that Topics link should be also in the bottom of every command as "Main index"/"Full index" ?

Yes. I have implemented it.

[hamish]

Hi there,

How about splitting it up into 3 columns?

To get the balance correct it would have to know the number of elements in the list before it began writing the page.

If you sorted alphabetically by row first, maybe you don't have to know that before hand, just do a 'carriage return' maneuver after every n'th column, then pad empty cells at the end of the table as needed.

thanks, Hamish

[mlennert]

I think such as list is very useful, but the result is still quite unsatisfactory at this point. E.g.

• database only links to v.db.* modules, none of the db.* modules
  

• imagery only lists r.in.aster
  

• raster links to a series of diverse modules, none of them r.*
  

• interpolation only links to t.rast.gapfill
  

etc

I guess this means that many modules do not have the right (or any?) keywords. But IMHO, as much as I like the idea, I'm afraid that in its current state this list might be counterproductive for new users. I definitely would not recommend my students to use it right now when trying to find modules by topics.

Moritz

[neteler]

Replying to mlennert:

I think such as list is very useful, but the result is still quite unsatisfactory at this point. E.g.

• database only links to v.db.* modules, none of the db.* modules
  

As written, the current mechanism is based on the second keyword. Each topic corresponds to this. The db.* have: "attribute table" there, while the v.db.* have "database". It is a trivial change to reorder this, just some agreement is needed first.

• imagery only lists r.in.aster
  

Fixed in r , now it results in "Import".

• raster links to a series of diverse modules, none of them r.*
  

Right, all have the wrong second keyword. Working on it.

• interpolation only links to t.rast.gapfill
  

The others under "surface". This requires some more discussion how to classify them.

etc

I guess this means that many modules do not have the right (or any?) keywords. But IMHO, as much as I like the idea, I'm afraid that in its current state this list might be counterproductive for new users. I definitely would not recommend my students to use it right now when trying to find modules by topics.

Ok, it exists for a few days only - tell them to wait a week :-)

Markus

[madi]

Ciao, would it be possible to include somehow also add-ons in the search? this could be very useful as well. Thanks

[martinl]

Replying to madi:

Ciao, would it be possible to include somehow also add-ons in the search? this could be very useful as well. Thanks

probably yes, see auto-generated modules.xml (1) which contains keywords tag.

Martin

(1) ​http://grass.osgeo.org/addons/grass7/modules.xml

[neteler]

Replying to neteler:

Replying to mlennert:

• database only links to v.db.* modules, none of the db.* modules
  

Fixed in r52973m using "attribute table" everywhere since "database" is already the first category.

• raster links to a series of diverse modules, none of them r.*
  

Right, all have the wrong second keyword. Working on it.

Done.

• interpolation only links to t.rast.gapfill
  

The others under "surface". This requires some more discussion how to classify them.

Remains open for discussion.

Updated list here: ​http://grass.osgeo.org/grass70/manuals/html70_user/topics.html

[mlennert]

Replying to neteler:

Replying to neteler:

Replying to mlennert:

• database only links to v.db.* modules, none of the db.* modules
  

Fixed in r52973m using "attribute table" everywhere since "database" is already the first category.

• raster links to a series of diverse modules, none of them r.*
  

Right, all have the wrong second keyword. Working on it.

Done.

• interpolation only links to t.rast.gapfill
  

The others under "surface". This requires some more discussion how to classify them.

Thanks for all the work on the keywords. At least now things are more consistent. I would have looked first for database, and would probably not have thought of looking for "attribute table" as a keyword, but that's me. What this does raise as a question is why do we have to limit ourselves to one keyword per module. Can't you just create this list with all the key words, with modules appearing under different keywords ? Thus you multiply the chance of people finding the module.

Moritz

P.S. Sorry if my comment about my students using the list sounded harsh. I'm aware that this is a new effort, but was a bit surprised that it was published so quickly on the web site. Then again, GRASS7 _is_ a development version.

[wenzeslaus]

What needs to be done to close this ticket?

I suggest to revise original description and also create new tickets (or update relevant existing tickets) if some of the ideas in discussion have clear shape.

Currently we have Topics and Keywords index in manual:

• ​http://grass.osgeo.org/grass70/manuals/topics.html
• ​http://grass.osgeo.org/grass70/manuals/keywords.html

tickets with similar requests:

• #645 link documentation to new GUI developments
• #762 add menu location to help pages
• #1203 explain command mapping to wxGUI menus

XML files in source code:

• source:grass/trunk/gui/wxpython/xml/main_menu.xml​
• source:grass/trunk/gui/wxpython/xml/module_tree.xml​
• source:grass/trunk/gui/wxpython/xml/toolboxes.xml​
• (these follow definition source:grass/trunk/gui/wxpython/xml/toolboxes.dtd​)

and generated XML files:

• ​http://grass.osgeo.org/addons/grass7/modules.xml (only on addons server)

There are some other XMLs but I don't think that they are important for the discussion.

If you want to do extend the list above with details and examples, I suggest to create a wiki page on Trac, e.g. wiki:Toolboxes/GeneratingDocumentation.

[martinl]

No activity last 2 years, closing, feel free to reopen if needed.

[wenzeslaus]

I don't know what worksforme refers to here but this was actually fixed for 7.2, not exactly in the originally suggested way but perhaps in a better one, see G72:g.search.modules (and also comment:5:ticket:343).

> g.search.modules "landscape"
g.gui.rlisetup
    keywords: general,GUI,raster,landscape structure analysis
    description: Configuration tool for r.li modules.

r.li.cwed
    keywords: raster,landscape structure analysis,patch index
    description: Calculates contrast weighted edge density index on a raster
                 map

r.li.dominance
    keywords: raster,landscape structure analysis,diversity index
    description: Calculates dominance's diversity index on a raster map
...

The attached CSV can be used to review the existing keywords for modules.