[GRASS-dev] wxGUI data catalog

martinl · May 1, 2014, 5:18pm

Hi all,

one of my students (Tereza, cc'ed) started to work on simple version
of the data catalog implemented as a new tab in Layer Manager. This
tool will allow to manage maps in the current location (remove, copy,
or rename). Later could be added support for copying maps between
different locations (including automated reprojection), preview of
data and so on.

Currently we are facing to the question whether to use in her code
pyGRASS or just GRASS Python Scripting Library. pyGRASS is not
currently used in wxGUI at all (with only one exception - see
gui_core/gselect.py [1]). There are some wxGUI components which should
be rewritten using pygrass (those which already use ctypes), eg. wxGUI
vector digitizer, but it's another story.

So the question: do we start using pyGRASS in wxGUI more often even in
the code where we don't need ctypes access and calling GRASS commands
through GRASS Python Scripting Library is enough.

The sample code from data catalog (copying maps):

GRASS Python Scripting Library:

cur_mapset = grass.gisenv()['MAPSET']
grass.run_command('g.gisenv', set = 'MAPSET=%s' % dst_mapset)
grass.run_command('g.copy', rast='%s@%s,%s' % (src_map, src_mapset, dst_name))
grass.run_command('g.gisenv', set = 'MAPSET=%s' % cur_mapset)

pyGRASS:

cur_mapset = str(Mapset())
Mapset(dst_mapset).current()
g.copy(rast = '%s@%s,%s' % (src_map, src_mapset, dst_name)) # *
Mapset(cur_mapset).current()

* this could be replaced by something more fancy by modifying pyGRASS

What is you opinion?

Personally I incline to promote pyGRASS as interface for user scripts,
but in wxGUI I still prefer to use GRASS Scripting Library to call
GRASS commands on the background.

Martin

[1] http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/gui_core/gselect.py#L55

--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa

mlennert · May 2, 2014, 8:44am

On 01/05/14 19:18, Martin Landa wrote:

Hi all,

one of my students (Tereza, cc'ed) started to work on simple version
of the data catalog implemented as a new tab in Layer Manager. This
tool will allow to manage maps in the current location (remove, copy,
or rename). Later could be added support for copying maps between
different locations (including automated reprojection), preview of
data and so on.

Currently we are facing to the question whether to use in her code
pyGRASS or just GRASS Python Scripting Library. pyGRASS is not
currently used in wxGUI at all (with only one exception - see
gui_core/gselect.py [1]). There are some wxGUI components which should
be rewritten using pygrass (those which already use ctypes), eg. wxGUI
vector digitizer, but it's another story.

So the question: do we start using pyGRASS in wxGUI more often even in
the code where we don't need ctypes access and calling GRASS commands
through GRASS Python Scripting Library is enough.

The sample code from data catalog (copying maps):

GRASS Python Scripting Library:

cur_mapset = grass.gisenv()['MAPSET']
grass.run_command('g.gisenv', set = 'MAPSET=%s' % dst_mapset)
grass.run_command('g.copy', rast='%s@%s,%s' % (src_map, src_mapset, dst_name))
grass.run_command('g.gisenv', set = 'MAPSET=%s' % cur_mapset)

pyGRASS:

cur_mapset = str(Mapset())
Mapset(dst_mapset).current()
g.copy(rast = '%s@%s,%s' % (src_map, src_mapset, dst_name)) # *
Mapset(cur_mapset).current()

* this could be replaced by something more fancy by modifying pyGRASS

What is you opinion?

Personally I incline to promote pyGRASS as interface for user scripts,
but in wxGUI I still prefer to use GRASS Scripting Library to call
GRASS commands on the background.

I don't know pyGRASS well enough to really judge. Could you explain your preference ?

More generally, I think that unless the two really fulfill two different purposes shouldn't we try to focus on one, instead of having the two ?

Moritz

wenzeslaus · May 2, 2014, 7:18pm

On Thu, May 1, 2014 at 1:18 PM, Martin Landa <landa.martin@gmail.com> wrote:

one of my students (Tereza, cc'ed) started to work on simple version
of the data catalog implemented as a new tab in Layer Manager. This
tool will allow to manage maps in the current location (remove, copy,
or rename). Later could be added support for copying maps between
different locations (including automated reprojection), preview of
data and so on.

Hi, this could be a very helpful tool. There is one thing I strongly
suggest to you. The tool should be available as g.gui.datacatalog (or
whatever name is appropriate). There is several reason for this and we can
discuss them in detail if you want but basically they include better code,
possibility to not have it in main GUI at all, space for more feature-rich
interface, and fast access to functionality if your primary interface is
command line.

Vaclav

annakrat · May 3, 2014, 4:12am

Hi,

···

On Thu, May 1, 2014 at 1:18 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi all,

one of my students (Tereza, cc’ed) started to work on simple version
of the data catalog implemented as a new tab in Layer Manager. This
tool will allow to manage maps in the current location (remove, copy,
or rename). Later could be added support for copying maps between
different locations (including automated reprojection), preview of
data and so on.

Do you plan to discuss somewhere the design of the catalog? Perhaps summarize the main points about the integration with layer manager and map display, gui design, planned features etc on Trac?

Currently we are facing to the question whether to use in her code
pyGRASS or just GRASS Python Scripting Library. pyGRASS is not
currently used in wxGUI at all (with only one exception - see
gui_core/gselect.py [1]). There are some wxGUI components which should
be rewritten using pygrass (those which already use ctypes), eg. wxGUI
vector digitizer, but it’s another story.

So the question: do we start using pyGRASS in wxGUI more often even in
the code where we don’t need ctypes access and calling GRASS commands
through GRASS Python Scripting Library is enough.

The sample code from data catalog (copying maps):

GRASS Python Scripting Library:

cur_mapset = grass.gisenv()[‘MAPSET’]
grass.run_command(‘g.gisenv’, set = ‘MAPSET=%s’ % dst_mapset)
grass.run_command(‘g.copy’, rast=‘%s@%s,%s’ % (src_map, src_mapset, dst_name))
grass.run_command(‘g.gisenv’, set = ‘MAPSET=%s’ % cur_mapset)

pyGRASS:

cur_mapset = str(Mapset())
Mapset(dst_mapset).current()
g.copy(rast = ‘%s@%s,%s’ % (src_map, src_mapset, dst_name)) # *
Mapset(cur_mapset).current()

this could be replaced by something more fancy by modifying pyGRASS

What is you opinion?

Personally I incline to promote pyGRASS as interface for user scripts,
but in wxGUI I still prefer to use GRASS Scripting Library to call
GRASS commands on the background.

I agree with that, I am not sure if pyGRASS would give us some advantage in the mapset/location management, I haven’t used it for these tasks. But I would like to hear from some who already used it like this.

Anna

Martin

[1] http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/gui_core/gselect.py#L55

–
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

martinl · May 4, 2014, 8:16am

Hi,

2014-05-03 6:12 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:

Do you plan to discuss somewhere the design of the catalog? Perhaps
summarize the main points about the integration with layer manager and map
display, gui design, planned features etc on Trac?

good idea, I created trac wiki page [1]. Please feel free to improve
this page, add new ideas...

Thanks, Martin

[1] http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/wxDataCatalog

Pietro2 · May 6, 2014, 8:47am

Hi Martin,

On Thu, May 1, 2014 at 7:18 PM, Martin Landa <landa.martin@gmail.com> wrote:

Later could be added support for copying maps between
different locations (including automated reprojection)

I would love to have this functionality somewhere on the python
library, maybe we could add a "copy" method to the Location class, see
more below.

pyGRASS:

cur_mapset = str(Mapset())
Mapset(dst_mapset).current()
g.copy(rast = '%s@%s,%s' % (src_map, src_mapset, dst_name)) # *
Mapset(cur_mapset).current()

* this could be replaced by something more fancy by modifying pyGRASS

Perhaps I could add a new method "copy" to Mapset If could be useful
to someone, something like:

{{{
    def copy(self, data_type, data_name, dst_mapset, dst_name=''):
        """Copies available data files in the current mapset search path
        to the user's current mapset.

Parameters
----------

        data_type : string
            String with the data type that must be copied ('rast', rast3d',
            'vect', 'oldvect', 'asciivect', 'icon', 'labels', 'sites',
            'region', 'region3d', 'group', 'view3d').
        data_name : string
            Name of the data that you want to copy.
        dst_mapset : string
            Name of the destination mapset.
        dst_name : string, optional
            Name of the copy.
        """
        from grass.pygrass.modules.shortcuts import general as g
        # set the destination mapset as current
        Mapset(dst_mapset).current()
        # copy the data from origin to destination
        g.copy(**{data_type: '%s@%s,%s' % (data_name, self.name,
                             dst_name if dst_name else data_name)})
        # set the origin as current
        self.current()
}}}

In this way you should be able to do the same operation with:

{{{
Mapset().copy('rast', src_map, dst_mapset, dst_name)
}}}

and should be possible to implement something similar for the location.

{{{
Location().copy(data_type, data_name, src_mapset, dst_location,
dst_mapset, dst_name)
}}}

Personally I incline to promote pyGRASS as interface for user scripts,
but in wxGUI I still prefer to use GRASS Scripting Library to call
GRASS commands on the background.

+1, or using pygrass through Soeren's RPC interface.

Pietro