Would you consider adding an optional "-r" (as "remove") switch to the
<g.mapsets> module?
Or, add an optional switch "-s" or "-x" (as "select-ive/-ed" or as
"exclusive") which will add the specified mapsets (parameter "mapset=") and
remove the rest (but the current, of course)?
Justification
I work with Landsat imagery, many tiles, imported in individual Mapsets (per
Landsat scene) and I often want to run/loop over many Mapsets. I require to
ensure that, while loopen over Mapsets (=individual Landsat scenes) and,
working on each of the bands that pertain to a Landsat scene, raster
processing modules wont touch any bands out of the current Mapset. Even avoid
WARNING mesages that a raster map A has been found elsewhere, but the raster
map B in Mapset B will be used.
A use case is, for example, that I need to selectively use i.landsat.toar on
many Mapsets (that is, on many Landsat scenes) with the default
method(=uncorrected) and produce At-Sensor-Reflectances while performing
conversion to Top-of-Atmosphere Radiance with i.landsat.toar's "-r" switch.
Currently, in bash-scripting G7, I try first to remove access to all mapsets
but the current (of course) as follows:
Would you consider adding an optional "-r" (as "remove") switch to the
<g.mapsets> module?
there is already `operation=remove`.
Or, add an optional switch "-s" or "-x" (as "select-ive/-ed" or as
"exclusive") which will add the specified mapsets (parameter "mapset=") and
remove the rest (but the current, of course)?
you can use `operation=set` to define search path from scratch. See the manual.
Or, add an optional switch "-s" or "-x" (as "select-ive/-ed" or as
"exclusive") which will add the specified mapsets (parameter "mapset=") and
remove the rest (but the current, of course)?
A use case is, for example, that I need to selectively use i.landsat.toar on
many Mapsets (that is, on many Landsat scenes) with the default
method(=uncorrected) and produce At-Sensor-Reflectances while performing
conversion to Top-of-Atmosphere Radiance with i.landsat.toar's "-r" switch.
Currently, in bash-scripting G7, I try first to remove access to all mapsets
but the current (of course) as follows:
> Would you consider adding an optional "-r" (as "remove")
> switch to the <g.mapsets> module?
There is already operation=remove available.. ?
> Or, add an optional switch "-s" or
fwiw there is already a "-s" switch to launch the selection GUI,
> Currently, in bash-scripting G7, I try first to remove
> access to all mapsets but the current (of course) as
> follows:
>
> # one-liner!
> g.mapsets mapset=$(g.mapsets -p sep=newline | \
> grep -v `g.mapset -p` | tr "\n" ",") operation=remove
why not just like:
g.mapsets mapset=nikos,PERMANENT op=set
?
op=set is a replacing action.
Martin wrote:
If I understood well, you want something like
g.mapsets set=<current_mapset>
?
note that in many places in grass we have:
g.mlist mapset=.
to reference the current mapset. That doesn't seem to work in
g.mapsets yet, but it would be pretty easy to add. Then you
could have in your script a generic:
g.mapsets mapset=.,PERMANENT op=set
if you want to avoid the `eval g.gisenv` step to get the current
$MAPSET name to feed into g.mapsets's mapset= option.
Hamish
ps- should failure to include PERMANENT in a new search path
produce a warning G_message()? (hushed by --quiet)
> A use case is, for example, that I need to selectively use i.landsat.toar
> on many Mapsets (that is, on many Landsat scenes) with the default
> method(=uncorrected) and produce At-Sensor-Reflectances while performing
> conversion to Top-of-Atmosphere Radiance with i.landsat.toar's "-r"
> switch.
> Currently, in bash-scripting G7, I try first to remove access to all
> mapsets but the current (of course) as follows:
If I understood well, you want something like
g.mapsets set=<current_mapset>
?
I think yes!
But maybe "set" is enough? Didn't play with it much.
e.g.:
- available Mapsets: A, B , C, D, E1, E2, E3, E4
- accessible Mapsets: A, B, E1, E4
- the task is to loop over all E?s (that is, E1, E2, E3, E4) and do something
so:
- inside A
- launch loop
- enter in E1, remove all but E1 from being accessible, do something
- enter in E2 and, keep access only to E2, do something
- and so on...
fwiw there is already a "-s" switch to launch the selection GUI,
This is cool & handy
> > Currently, in bash-scripting G7, I try first to remove
> > access to all mapsets but the current (of course) as
> > follows:
> > # one-liner!
> > g.mapsets mapset=$(g.mapsets -p sep=newline | \
> > grep -v `g.mapset -p` | tr "\n" ",") operation=remove
why not just like:
g.mapsets mapset=nikos,PERMANENT op=set>
?
op=set is a replacing action.
yes, why not?
Martin wrote:
> If I understood well, you want something like
> g.mapsets set=<current_mapset>
> ?
note that in many places in grass we have:
g.mlist mapset=.
to reference the current mapset. That doesn't seem to work in
g.mapsets yet, but it would be pretty easy to add. Then you
could have in your script a generic:
g.mapsets mapset=.,PERMANENT op=set
if you want to avoid the `eval g.gisenv` step to get the current
$MAPSET name to feed into g.mapsets's mapset= option.
Yes, much easier with "mapset=."
ps- should failure to include PERMANENT in a new search path
produce a warning G_message()? (hushed by --quiet)
you mean in case of "mapset=WhatEverMapset,PERMANENT op=set", right?
> ps- should failure to include PERMANENT in a new search path
> produce a warning G_message()? (hushed by --quiet)
Nikos:
you mean in case of "mapset=WhatEverMapset,PERMANENT op=set",
right?
no, when you use op=set the entire mapset search list is replaced
in full, so "mapset=WhatEverMapset op=set" removes PERMANENT
from the search list, which while possible, isn't usually the
expected behaviour.
On Sun, Feb 17, 2013 at 1:56 AM, Hamish <hamish_b@yahoo.com> wrote:
> Or, add an optional switch "-s" or
fwiw there is already a "-s" switch to launch the selection GUI,
I didn't know about this option. From the layer manager menu you can
launch the same dialog. The problem is that the code is duplicated (in
wxpython/gui_core/preferences.py and
general/g.mapsets/g.mapsets_picker.py). There are some differences but
I think there is no reason for that. Also, this g.mapsets -s is not
really consistent with the new g.gui.modules. What about
g.gui.mapsets? Or if we want to keep the flag -s, the code should be
at least on one place.
2013/2/18 Anna Kratochvílová <kratochanna@gmail.com>:
I think there is no reason for that. Also, this g.mapsets -s is not
really consistent with the new g.gui.modules. What about
g.gui.mapsets? Or if we want to keep the flag -s, the code should be
at least on one place.
this `-s` flag is a historical artefact from G6 - `g.mapsets -s`
originally launch TCL/TK dialog (if GUI is TCL/TK). Having `g.gui.*`
modules, `g.gui.mapsets` makes probably more sense (drawback: one more
module introduced, backward compatibility broken - 's' flag removed)
than `g.mapsets -s`. In any case, code should be on one place, of
course.
On 18 February 2013 15:34, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2013/2/18 Anna Kratochvílová <kratochanna@gmail.com>:
I think there is no reason for that. Also, this g.mapsets -s is not
really consistent with the new g.gui.modules. What about
g.gui.mapsets? Or if we want to keep the flag -s, the code should be
at least on one place.
this `-s` flag is a historical artefact from G6 - `g.mapsets -s`
originally launch TCL/TK dialog (if GUI is TCL/TK). Having `g.gui.*`
modules, `g.gui.mapsets` makes probably more sense (drawback: one more
module introduced, backward compatibility broken - 's' flag removed)
than `g.mapsets -s`. In any case, code should be on one place, of
course.
Hi,
we can ignore backward compatibility issue if we decide that mixing
modules with and without gui is simply wrong (I vote for non-mixing
but we can do some wider discussion on that topic, of course).
I'm afraid that we are not able to keep the number of g.gui.* modules small.
For me the drawback is that as a user I have to thing about two
different mapset modules. Generally speaking, there is no rule to
determine which functionality is provided by the g.mapset(s) module
and which by g.gui.mapset(s) module.
> fwiw there is already a "-s" switch to launch the selection GUI,
Anna wrote:
I didn't know about this option. From the layer manager menu you can
launch the same dialog. The problem is that the code is duplicated (in
wxpython/gui_core/preferences.py and
general/g.mapsets/g.mapsets_picker.py). There are some
differences but I think there is no reason for that.
Please keep in mind that not everyone uses the GUI, especially among
the power-users, but sometimes a little GUI helper window is very
helpful anyway.
Also, this g.mapsets -s is not really consistent with the new
g.gui.modules.
I've been away and am not familiar with that, but will have a look.
On Mon, Feb 18, 2013 at 6:51 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On 18 February 2013 15:34, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2013/2/18 Anna Kratochvílová <kratochanna@gmail.com>:
I think there is no reason for that. Also, this g.mapsets -s is not
really consistent with the new g.gui.modules. What about
g.gui.mapsets? Or if we want to keep the flag -s, the code should be
at least on one place.
this `-s` flag is a historical artefact from G6 - `g.mapsets -s`
originally launch TCL/TK dialog (if GUI is TCL/TK). Having `g.gui.*`
modules, `g.gui.mapsets` makes probably more sense (drawback: one more
module introduced, backward compatibility broken - 's' flag removed)
than `g.mapsets -s`. In any case, code should be on one place, of
course.
Hi,
we can ignore backward compatibility issue if we decide that mixing
modules with and without gui is simply wrong (I vote for non-mixing
but we can do some wider discussion on that topic, of course).
I'm afraid that we are not able to keep the number of g.gui.* modules small.
For me the drawback is that as a user I have to thing about two
different mapset modules. Generally speaking, there is no rule to
determine which functionality is provided by the g.mapset(s) module
and which by g.gui.mapset(s) module.
Adding some confusion:
There is gui/wxpython/modules which holds gui interfaces to modules,
but not modules itself. Other customized interfaces are in
gui/wxpython/gui_core. These have no additional functionality, the
reason for their existence is mainly that the automatically generated
gui is less powerful than the cli. The g.gui.* modules are apparently
distributed in several subfolders of gui/wxpython/.
Since the -s flag does not add new functionality to g.mapsets, I would
strongly opt to remove the -s flag. If you want to use the customized
gui interface for
r.in.gdal/v.in.ogr/r.colors/v.clean/i.group/g.mapsets etc, use the gui
menu. Otherwise, you can use the command line. The g.gui.* naming
should IMHO be reserved exclusively for modules that require a GUI
like e.g. g.gui.mapswipe.
Alternatively, gui/wxpython/gui_core/forms.py could be modified to use
a customized interface if it exists for a given module, defined as
handler in gui/wxpython/gui_core/xml/menudata.xml which in turn is
parsed by gui/wxpython/core/menudata.py, the handler itself is defined
in gui/wxpython/lmgr/frame.py. Can the handlers be moved to forms.py?
On 18 February 2013 20:08, Markus Metz <markus.metz.giswork@gmail.com> wrote:
On Mon, Feb 18, 2013 at 6:51 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On 18 February 2013 15:34, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2013/2/18 Anna Kratochvílová <kratochanna@gmail.com>:
I think there is no reason for that. Also, this g.mapsets -s is not
really consistent with the new g.gui.modules. What about
g.gui.mapsets? Or if we want to keep the flag -s, the code should be
at least on one place.
this `-s` flag is a historical artefact from G6 - `g.mapsets -s`
originally launch TCL/TK dialog (if GUI is TCL/TK). Having `g.gui.*`
modules, `g.gui.mapsets` makes probably more sense (drawback: one more
module introduced, backward compatibility broken - 's' flag removed)
than `g.mapsets -s`. In any case, code should be on one place, of
course.
Hi,
we can ignore backward compatibility issue if we decide that mixing
modules with and without gui is simply wrong (I vote for non-mixing
but we can do some wider discussion on that topic, of course).
I'm afraid that we are not able to keep the number of g.gui.* modules small.
For me the drawback is that as a user I have to thing about two
different mapset modules. Generally speaking, there is no rule to
determine which functionality is provided by the g.mapset(s) module
and which by g.gui.mapset(s) module.
Adding some confusion:
There is gui/wxpython/modules which holds gui interfaces to modules,
but not modules itself. Other customized interfaces are in
gui/wxpython/gui_core. These have no additional functionality, the
reason for their existence is mainly that the automatically generated
gui is less powerful than the cli. The g.gui.* modules are apparently
distributed in several subfolders of gui/wxpython/.
Since the -s flag does not add new functionality to g.mapsets, I would
strongly opt to remove the -s flag.
If you want to use the customized
gui interface for
r.in.gdal/v.in.ogr/r.colors/v.clean/i.group/g.mapsets etc, use the gui
menu.
Otherwise, you can use the command line.
But still there are some power users which would like to avoid
starting the main big GUI. Personally, I like the idea of accessing
anything in the gui from command line (one reason is that it helps to
reduce dependencies in the gui code).
One solution would be run gui for modules such as r.in.gdal by some
gui starter command which would accept the module name as a parameter;
it is something like command line menu (g.gui.climenu). This was
proposed for the g.gui.* in order to avoid having many new modules or
to avoid the new kind of modules.
The g.gui.* naming
should IMHO be reserved exclusively for modules that require a GUI
like e.g. g.gui.mapswipe.
Alternatively, gui/wxpython/gui_core/forms.py could be modified to use
a customized interface if it exists for a given module, defined as
handler in gui/wxpython/gui_core/xml/menudata.xml which in turn is
parsed by gui/wxpython/core/menudata.py, the handler itself is defined
in gui/wxpython/lmgr/frame.py. Can the handlers be moved to forms.py?
Show customized instead of generated, interesting. The handlers in
lmgr/frame.py are subject to refactoring and even more, they might be
connected to toolbox concept. I will try to keep this in mind.
This thread should turned into a article on Trac wiki. Putting this
into my todo.
On Mon, Feb 18, 2013 at 10:39 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On 18 February 2013 20:08, Markus Metz <markus.metz.giswork@gmail.com> wrote:
On Mon, Feb 18, 2013 at 6:51 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On 18 February 2013 15:34, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2013/2/18 Anna Kratochvílová <kratochanna@gmail.com>:
I think there is no reason for that. Also, this g.mapsets -s is not
really consistent with the new g.gui.modules. What about
g.gui.mapsets? Or if we want to keep the flag -s, the code should be
at least on one place.
this `-s` flag is a historical artefact from G6 - `g.mapsets -s`
originally launch TCL/TK dialog (if GUI is TCL/TK). Having `g.gui.*`
modules, `g.gui.mapsets` makes probably more sense (drawback: one more
module introduced, backward compatibility broken - 's' flag removed)
than `g.mapsets -s`. In any case, code should be on one place, of
course.
Hi,
we can ignore backward compatibility issue if we decide that mixing
modules with and without gui is simply wrong (I vote for non-mixing
but we can do some wider discussion on that topic, of course).
I'm afraid that we are not able to keep the number of g.gui.* modules small.
For me the drawback is that as a user I have to thing about two
different mapset modules. Generally speaking, there is no rule to
determine which functionality is provided by the g.mapset(s) module
and which by g.gui.mapset(s) module.
Adding some confusion:
There is gui/wxpython/modules which holds gui interfaces to modules,
but not modules itself. Other customized interfaces are in
gui/wxpython/gui_core. These have no additional functionality, the
reason for their existence is mainly that the automatically generated
gui is less powerful than the cli. The g.gui.* modules are apparently
distributed in several subfolders of gui/wxpython/.
Since the -s flag does not add new functionality to g.mapsets, I would
strongly opt to remove the -s flag.
If you want to use the customized
gui interface for
r.in.gdal/v.in.ogr/r.colors/v.clean/i.group/g.mapsets etc, use the gui
menu.
Otherwise, you can use the command line.
But still there are some power users which would like to avoid
starting the main big GUI. Personally, I like the idea of accessing
anything in the gui from command line (one reason is that it helps to
reduce dependencies in the gui code).
One solution would be run gui for modules such as r.in.gdal by some
gui starter command which would accept the module name as a parameter;
it is something like command line menu (g.gui.climenu). This was
proposed for the g.gui.* in order to avoid having many new modules or
to avoid the new kind of modules.
The g.gui.* naming
should IMHO be reserved exclusively for modules that require a GUI
like e.g. g.gui.mapswipe.
Alternatively, gui/wxpython/gui_core/forms.py could be modified to use
a customized interface if it exists for a given module, defined as
handler in gui/wxpython/gui_core/xml/menudata.xml which in turn is
parsed by gui/wxpython/core/menudata.py, the handler itself is defined
in gui/wxpython/lmgr/frame.py. Can the handlers be moved to forms.py?
Show customized instead of generated, interesting. The handlers in
lmgr/frame.py are subject to refactoring and even more, they might be
connected to toolbox concept. I will try to keep this in mind.
I am not sure if this needs emphasizing, but the customized GUI
interfaces already exist. The idea here is to call the already
existing customized interface for a given module, e.g.
r.in.gdal/v.in.ogr/r.colors/v.clean/i.group/g.mapsets etc. No funny
flag needed in the module.
This thread should turned into a article on Trac wiki.
I have been the person requesting the -s flag for g.mapsets long ago
for G7 and I use it continuously. To remove it entirely would be a
major usability loss for cmd line prefering power users who don't want
to search in the wxGUI.
On 19 February 2013 07:12, Markus Neteler <neteler@osgeo.org> wrote:
Hi,
I have been the person requesting the -s flag for g.mapsets long ago
for G7 and I use it continuously. To remove it entirely would be a
major usability loss for cmd line prefering power users who don't want
to search in the wxGUI.
On Mon, Feb 18, 2013 at 11:03 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
On Mon, Feb 18, 2013 at 10:39 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On 18 February 2013 20:08, Markus Metz <markus.metz.giswork@gmail.com> wrote:
On Mon, Feb 18, 2013 at 6:51 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
...
Since the -s flag does not add new functionality to g.mapsets, I would
strongly opt to remove the -s flag.
If you want to use the customized gui interface for
r.in.gdal/v.in.ogr/r.colors/v.clean/i.group/g.mapsets etc, use the gui
menu.
Otherwise, you can use the command line.
This makes perfect sense: i.e. g.mapsets fired up from cmd line
without anything pops up the nice related g.mapsets gui window.
But still there are some power users which would like to avoid
starting the main big GUI. Personally, I like the idea of accessing
anything in the gui from command line (one reason is that it helps to
reduce dependencies in the gui code).
One solution would be run gui for modules such as r.in.gdal by some
gui starter command which would accept the module name as a parameter;
it is something like command line menu (g.gui.climenu). This was
proposed for the g.gui.* in order to avoid having many new modules or
to avoid the new kind of modules.
+1
...
I am not sure if this needs emphasizing, but the customized GUI
interfaces already exist. The idea here is to call the already
existing customized interface for a given module, e.g.
r.in.gdal/v.in.ogr/r.colors/v.clean/i.group/g.mapsets etc. No funny
flag needed in the module.
