[GRASS-dev] proposal for g.search module

Jachym Cepicky jachym.cepicky at gmail.com
Sat Nov 28 02:09:00 PST 2015

Vašku, if we agree on adding more search engines to g.search, I suggest to
define the features and interface (--help output) now and I can start think
about more generic concept of the code

maps, groups

OR and AND flag

terminal output, shell script output, json output

this starts to be pretty heavy module :-)

On Sat, Nov 28, 2015, 02:25 Vaclav Petras <wenzeslaus at gmail.com> wrote:

> On Fri, Nov 27, 2015 at 6:06 PM, Jachym Cepicky <jachym.cepicky at gmail.com>
> wrote:
>> ahoj Vašku,
>> not sure about the maps. wouldn't be better to extend g.list?
> Perhaps, the search could include title names as well - this would be the
> extension to g.list. This makes sense as you usually know if you are
> searching maps/groups/... or modules.
> On the other hand, g.search could provide unified simple search interface
> for searching/listing maps and modules - a simple "fulltext" search for
> word. This would wrap more general g.list pattern search interface. There
> is few other things we could search: Mapsets, Locations, and color tables.
> But let's ignore this for now.
>> about the name: g.module.search?
> g.search aspect
> g.module.search aspect
> g.search.module aspect
> g.module.search sounds good. In GUI the tree and search tab is called
> Search modules, renamed from ambiguous Module search. Your original
> g.search is shorter and since it will be used in the command line, we
> should probably keep it short. So, at the end, I would keep g.search unless
> somebody is against that.
>> need to work on the output a bit more...
> Also, keep in mind that the XML may change at one point. See explanations
> in:
> [GRASS-dev] wxgui_items.xml: outdated
> https://lists.osgeo.org/pipermail/grass-dev/2015-October/077137.html
>> would -g flag be useful as well?
> Certainly, although not for me now.
>> glad you like it
> I suggest to put it to trunk as soon as you are comfortable with the code
> and basic features.
>> jachym
>> On Fri, Nov 27, 2015, 17:13 Vaclav Petras <wenzeslaus at gmail.com> wrote:
>>> On Fri, Nov 27, 2015 at 10:51 AM, Jachym Cepicky <
>>> jachym.cepicky at gmail.com> wrote:
>>>> Hi all,
>>>> I've tried to implement command line alternative to module search based
>>>> on keywords, which is available in the gui - it's called g.search
>>>> Any chance, you might find this useful ? Any comment to the source code
>>>> and outputs?
>>>> https://github.com/jachym/g.search
>>> I think it is awesome:
>>> $ g.extension extension=g.search url=https://github.com/jachym/g.search
>>> $ g.search MLC
>>> i.gensig
>>>     Description: Generates statistics for i.maxlik from raster map.
>>>     Keywords: imagery,classification,supervised classification,Maximum
>>> Likelihood Classification,MLC,signatures
>>> i.maxlik
>>>     Description: Classifies the cell spectral reflectances in imagery
>>> data. Classification is based on the spectral signature information
>>> generated by either i.cluster, g.gui.iclass, or i.gensig.
>>>     Keywords: imagery,classification,Maximum Likelihood
>>> Classification,MLC
>>> The code is minimalistic, so the duplication with GUI code is minimal or
>>> none.
>>> I suggest to put it to trunk, but to consider the name first. g.search
>>> sounds good but does it search modules or maps or both? Are the maps a
>>> possible extension of the current functionality?
>>> Vaclav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20151128/68c4cab9/attachment.html>

More information about the grass-dev mailing list