[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

modules
maps, groups
mapsets
locations?
regions
...

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