Opened 11 years ago

Closed 3 years ago

Last modified 3 years ago

#386 closed enhancement (worksforme)

Thematic grouping of grass modules in the command line

Reported by: nikos Owned by: grass-dev@…
Priority: minor Milestone: 7.0.5
Component: Docs Version: svn-trunk
Keywords: grouping grass modules Cc: nikos.alexandris@…
CPU: Unspecified Platform: Unspecified

Description

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).
  1. 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

  1. What speaks against those ideas?

Kind Regards, Nikos

Attachments (1)

raster_modules.csv (2.3 KB) - added by nikos 11 years ago.
attempting to group the grass raster modules

Download all attachments as: .zip

Change History (22)

Changed 11 years ago by nikos

Attachment: raster_modules.csv added

attempting to group the grass raster modules

comment:1 Changed 11 years ago by 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.

comment:2 in reply to:  1 Changed 11 years ago by 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? ;-)

comment:3 in reply to:  description ; Changed 11 years ago by hamish

Replying to nikos:

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

comment:4 in reply to:  3 Changed 11 years ago by nikos

Replying to hamish:

Replying to nikos:

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

comment:5 Changed 7 years ago by neteler

Component: DefaultDocs
Milestone: 6.4.06.4.4

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

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

comment:6 Changed 7 years ago by 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.

comment:7 in reply to:  5 Changed 7 years ago by 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

comment:8 Changed 7 years ago by neteler

Milestone: 6.4.47.0.0
Resolution: fixed
Status: newclosed

comment:9 Changed 7 years ago by lucadelu

Resolution: fixed
Status: closedreopened

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

comment:10 in reply to:  9 Changed 7 years ago by neteler

Resolution: fixed
Status: reopenedclosed
Version: unspecifiedsvn-trunk

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.

comment:11 Changed 7 years ago by 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

comment:12 Changed 7 years ago by 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

comment:13 in reply to:  12 ; Changed 7 years ago by neteler

Resolution: fixed
Status: closedreopened

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

comment:14 Changed 7 years ago by madi

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

comment:15 in reply to:  14 Changed 7 years ago by 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

comment:16 in reply to:  13 ; Changed 7 years ago by 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

comment:17 in reply to:  16 Changed 7 years ago by 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.

comment:18 Changed 6 years ago by 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:

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:

and generated XML files:

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

comment:19 Changed 3 years ago by martinl

Milestone: 7.0.07.0.5

comment:20 Changed 3 years ago by martinl

Resolution: worksforme
Status: reopenedclosed

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

comment:21 Changed 3 years ago by 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.

Note: See TracTickets for help on using tickets.