WxPython-based GUI for GRASS

See also GRASS GUI and GRASS and Python.

Overview

• A nice summary of the progress to date, written by Jachym Cepicky:
  • Part 1
  • Part 2
• New GRASS GUI based on wxPython (Geoinformatics FCE CTU 2007 Workshop, September 19th, 2007)

Requirements

• README

Screenshots

• SVN

Where to get it

Current version can be found at https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_grassaddons_gui_

svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons/gui

Write access to the GRASS-Addons SVN is managed by Markus Neteler.

Components

GIS Manager

Map display window

Module GUIs

• Generated from XML using --interface-description

E.g. for d.rgb

Description:
 Displays three user-specified raster map layers as red, green, and blue overlays in the active graphics frame.

Keywords:
 display

Usage:
 d.rgb [-ox] red=name green=name blue=name [--verbose] [--quiet]

Flags:
  -o   Overlay (non-null values only)
  -x   Don't add to list of commands in monitor
 --v   Verbose module output
 --q   Quiet module output

Parameters:
    red   Name of raster map to be used for <red>
  green   Name of raster map to be used for <green>
   blue   Name of raster map to be used for <blue>

Startup GUI

• for picking mapset etc

New location GUI

• Wizard for creating new location & region.

see QGIS's one

Cartography: GUI front end for ps.map

• This is a cartographic composer, intended to be a stand alone hardcopy plot generator. It is not meant to be a Print button for the maps currently displayed in the GIS manager, that will need it own controls.

• The GUI will prepare a semi-WYSIWYG + tree menu controls which can write a ps.map control file, and then run ps.map to create PostScript and PDF output directly. Loading a ps.map control file is harder and can happen later.

• For a start at a Tcl/Tk composer see gui/tcltk/d.m/print.tcl

see also these discussions and pyGTK prototype by Jachym Cepicky

• http://thread.gmane.org/gmane.comp.gis.grass.devel/12469
• http://thread.gmane.org/gmane.comp.gis.grass.devel/19368

• Start with most important mapping instructions
  • paper
  • scale
  • maploc
  • rast
  • vects
  • grids
  • scalebar
  • mapinfo
  • text labels

Outputs

• ps.map instructions file
• PostScript file [ps.map instructions tmp file]
• lpr [PostScript tmp file]
• PDF File (pstopdf? ps2pdf? GNU Ghostscript?) [PostScript tmp file]

Inputs

• Ability to load in saved ps.map scripts. I consider this to be a low priority, deal with it after map creation is fully functional. Start with scripts saved using the GUI, after that is working expand to load any ps.map instructions file.

Georectifier

• Should be a simple port of Michael's tcltk Georectifier for gis.m

Digitizer

Vector map layers

Replacement of v.ditit module integrated to Map display window (Screenshots).

Roadmap:

• Implement all features available in v.digit
  • done
• Back-end
  • v.edit (slow)
    • done
  • digit library
    • under development
• Implement new requested features
  • display vertices
    • done
  • animate moving vector objects by mouse
    • done
  • snap to vertex
    • done (v.edit tool=add/move/vertexmove snap=vertex)
  • snap to vector objects of background map(s)
    • done (v.edit tool=add/move/vertexmove snap=node/vertex bgmap=map)
  • unsplit (remove pseudo nodes, v.build.polylines functionality)
    • done (v.edit tool=merge)
  • copy features from background map
    • done (v.edit tool=copy bgmap=map)
  • query tool
    • select lines according their length
      • done (v.edit tool=select query=length thresh=value)
    • select dangles
      • done (v.edit tool=select query=dangle thresh=value)
  • z bulk-labeling (automated assignment of z coordinate to 3D lines)
    • done (v.edit tool=bulk)
  • undo
  • personalized menu
  • exit without save

Raster map layers

• r.digit (merge with v.digit?)
• d.rast.edit

Idea: get cell center coords and new values from GUI interaction, then pass those through r.in.xyz, and r.patch the new values over the top of the old map.

• merge with Georectifier? (i.points, i.vpoints)

Ortho photos

• To replace i.ortho.photo and friends

General GUI Design

User's point of view

• Multiple map display windows available
• Each map display window has several buttons for basic functions
  • Zooming, Paning
  • Data Quering
  • Etc.
• Each map display window will be able to fire up pop-up toolbar with more complicated and not-so-often-used display functions (substitutions for d.measure, d.profile, d.text, ...)
• Each map display window will be able to fire up pop-up toolbar with v.digit substitution
• Map display windows can be started from the command line and from the GIS Manager
• Map display windows must be able to display following types of layers
  • GRASS Raster
  • GRASS Vector
  • GDAL Raster
  • GDAL Vector
  • WMS Layer from remote server
  • WCS and WFS layers too
  • Text layers
  • Graphics layers
  • Grid
  • Image layers
  • ...
• GIS Manager is tool for
  • Map display window management and content management
  • Layer look management
  • Modules starting (from integrated command line or menu)
  • Displaying output from modules (G_message, G_warning, G_fatal_error, G_percent)
• GIS Manager must be able to save and restore session
  • Better new XML format
  • Or old gis.m related
• There should be default session file, which will be loaded by default ones GRASS is started with -gui parameter
• Georectification tool should be part of new GUI. It should be special type of monitor with added GCP function
• Map Composer should be part of the new GUI. This tool should generate configuration files for hardcopy maps. The configuration files should be either ps.map files or maybe SVG

Coder's point of view

NOTE: Has not been updated long time!; SVN code in progress. Would be better to use Python docs instead...

List of suggested classes and their purpose.

• Layer --Raster, vector, WMS, whatever layer
  • Attributes - Attributes are depending on layer type, but there are also common attributes marked with prefix "l_" (for 'layer'):
    • l_type - vector, raster, wms, text, graph, ...
    • l_mapfile - rendered ppm file
    • l_maskfile - pgm file with layer's alpha channel
    • l_active - layer is active, will be rendered only if True
    • l_hidden - layer is hidden, will be allways rendered
    • l_opacity - layer opacity [0-1]
  • Methods
    • Render - runs d.* and similar commands for making content of l_mapfile
• Map -- Set of layers renderd to single PNG image, ready to display in Map display frame
  • Attributes
    • Width - map width
    • Height - map height
    • Region - Region boundaries and resolution
    • Layers - Array of Layers displayed in this "map"
    • MapFile - path to resulting PNG file with rendered map
  • Methods
    • AddRasterLayer - Adds GRASS-raster layer to list of layers
    • AddVectorLayer - Adds GRASS-vector layer to list of layers
    • Add...Layer - Adds some type of layer (wms, wfs, text, ...) to list of layers
    • GetListOfLayers - Returns array of layers (active, hidden, type)
    • Render - Creates final PNG image and stores it's path to MapFile

TSW Comment: perhaps it would be simpler to have AddLayer and pass the type as a parameter. Automatic would be nice, but since it is possible for vector and raster files to have the same name, this wouldn't work. Another option to consider would be to use AddLayer as a base class AddLayerRaster, ... as subclasses. This would make things more modular and theoretically at least, easier to maintain and develop.

JC Comment: I made separate functions for raster and vector, because of their attributes are completely different. There should be also AddWMSLayer etc. functions. IMHO it does not matter, if we have general AddLayer with parameter layer_type, or separate functions for all layer types.

• DigitToolbar - Pop-up toolbar with digitising functions
• DisplayToolBar - Pop-up toolbar with substitution of other d.* modules
• MapDisplay - Frame (in wxWidgets terminology) with embed toolbar for zooming and paning and maybe data quering and pop-up toolbar for substitution of other d.* modules (d.path, d.profile, ...)
  • Attributes
    • Width
    • Height
    • Mouse - mouse actions, movements, presed buttons etc.
    • Map - Map class
  • Methods - just very coarse definition
    • Zoom - for zooming and paning
    • DrawBox - For box drawing
    • DrawLine - For line drawing
    • DrawPoint - for points drawing

• GisManager - GIS Manager frame
  • Attributes
    • Displays - array with map displayes
  • Methods
    • AddDisplay - Creates new map display
    • AddLayer - Adds layer of defined type
    • EditLayer - Opens pop-up window with layer attributes definition
    • ExecuteCommand - Executes module from command line or menu

• GCPDisplay -- Special type of MapDisplay with tool for setting GCPs
• HCPDisplay -- Special type of MapDisplay with tools for creating configuration files for hardcopy maps

Layout Concepts

Screenshots with proposed shapes

The wxGlade definition file is avaliable in the subversion repository	Another proposal by Michael Barton

Discussion / Comments

If the goal is to move toward a single command line interface integrated into the GUI, perhaps we should use the shape of a terminal window as the the shape of the new GIS manager. In this way the layers tree could appear next to the layer attributes in the same way the currently gis.m displays the layer attributes below the tree. The downside to this is having space on the desktop.

Another possibility would be to link the command window to the map display in the shape of an xterm, in this way the gis manager could have a profile shape by default that could easily fit onto a single screen for those without multiple display systems. Another possibility that might be desirable is to be able to 'tear off' the command window separately or link it to either the GIS manager tree or the display window.

It appears in the screen shots that multiple command windows are being considered (1 per map). In some ways this is potentially quite elegant especially if they are set up as separate sessions altogether so we wouldn't need to use win override. What we do encounter is issues related to multiple users which are non-trivial. Still as the layout suggest this it may be worth considering the impact of this, although the current solution in gis.m is probably the best for now.

Please use icons that adhere the icon style guideline. They will make Grass look more professional and consistent with other FOSS applications.

Make usability test of the new interface to enshure that Grass will be easy and intuitive for users.

GUI History

Link to wxPython prototype GUI for GRASS 6

Update 18:02, 14 August 2006 (CEST) New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!***** Cmbarton

Update 00:50, 9 August 2006 (CEST) New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. Cmbarton

Update 23:59, 7 August 2006 (CEST) New version with nearly complete raster menu by Yann Chemin. Cmbarton

Update 19:02, 7 August 2006 (CEST)I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:

• The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.

This can now be called from the command console (just type in the command name with no arguments as you do now) or the prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from other modules.

• Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac

--Cmbarton 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above. --Cmbarton 07:15, 4 August 2006 (CEST)

Useful links

• 10 minute Python tutorial for programmers of other languages