1wxGUI.gmodeler(1)           GRASS GIS User's Manual          wxGUI.gmodeler(1)
2
3
4

wxGUI Graphical Modeler

DESCRIPTION

7       The  Graphical  Modeler  is  a wxGUI component which allows the user to
8       create, edit, and manage simple and complex models using an easy-to-use
9       interface.   When  performing  analytical  operations in GRASS GIS, the
10       operations are not isolated, but part of a chain of  operations.  Using
11       the  Graphical  Modeler,  a chain of processes (i.e. GRASS GIS modules)
12       can be wrapped into one process (i.e. model). Subsequently it is easier
13       to  execute  the  model later on even with slightly different inputs or
14       parameters.
15       Models represent a programming technique used in GRASS GIS to  concate‐
16       nate  single  steps  together  to accomplish a task. It is advantageous
17       when the user see boxes and ovals that are connected by lines and  rep‐
18       resent some tasks rather than seeing lines of coded text. The Graphical
19       Modeler can be used as a custom tool that automates a process.  Created
20       models  can  simplify or shorten a task which can be run many times and
21       it can also be easily shared with others. Important  to  note  is  that
22       models  cannot  perform  specified  tasks that one cannot also manually
23       perform with GRASS GIS. It is  recommended  to  first  to  develop  the
24       process manually, note down the steps (e.g. by using the Copy button in
25       module dialogs) and later replicate them in model.
26
27       The Graphical Modeler allows you to:
28
29           ·   define data items (raster, vector, 3D raster maps)
30
31           ·   define actions (GRASS commands)
32
33           ·   define relations between data and action items
34
35           ·   define loops (e.g. map series) and conditions  (if-else  state‐
36               ments)
37
38           ·   define model variables
39
40           ·   parameterize GRASS commands
41
42           ·   define intermediate data
43
44           ·   validate and run model
45
46           ·   save model properties to a file (GRASS Model File|*.gxm)
47
48           ·   export model to Python script
49
50           ·   export model to image file
51
52   Main dialog
53       The  Graphical Modeler can be launched from the Layer Manager menu File
54       -> Graphical modeler or from the main toolbar . It’s also available  as
55       stand-alone module g.gui.gmodeler.
56
57       The  main Graphical Modeler menu contains options which enable the user
58       to fully control the model. Directly under the main menu one  can  find
59       toolbar  with  buttons  (see figure below). There are options including
60       (1) Create new model, (2) Load model from file, (3) Save current  model
61       to  file, (4) Export model to image, (5) Export model to Python script,
62       (6) Add command (GRASS modul) to model, (7) Add data to model, (8) Man‐
63       ually define relation between data and commands, (9) Add loop/series to
64       model, (10) Add comment to model, (11) Redraw model canvas, (12)  Vali‐
65       date  model,  (13)  Run  model, (14) Manage model variables, (15) Model
66       settings, (16) Show manual, (17) Quit Graphical Modeler.
67
68       Figure: Components of Graphical Modeler menu toolbar.
69
70       There is also a lower menu bar in the Graphical  modeler  dialog  where
71       one  can  manage  model  items, visualize commands, add or manage model
72       variables, define default values and descriptions.  The  Python  editor
73       dialog  window  allows  seeing  workflows  written  in Python code. The
74       rightmost tab of the bottom menu is automatically  triggered  when  the
75       model  is  activated  and  shows all the steps of running GRASS modeler
76       modules. In case of errors in the calculation process, it is written at
77       that place.
78       Figure: Lower Graphical Modeler menu toolbar.
79
80   Components of models
81       The  workflow is usually established from four types of diagrams. Input
82       and derived model data are usually represented with oval diagrams. This
83       type of model elements stores path to specific data on the user’s disk.
84       It is possible to insert vector data,  raster  data,  database  tables,
85       etc.   The  type of data is clearly distinguishable in the model by its
86       color.  Different model elements are shown in the figures below.
87
88           ·   (A) raster data:
89
90           ·   (B) relation:
91
92           ·   (C) GRASS module:
93
94           ·   (D) loop:
95
96           ·   (E) database table:
97
98           ·   (F) 3D raster data:
99
100           ·   (G) vector data:
101
102           ·   (H) disabled GRASS module:
103
104           ·   (I) comment:
105       Figure: A  model  to  perform  unsupervised  classification  using  MLC
106       (i.maxlik) and SMAP (i.smap).
107
108       Another example:
109       Figure:  A  model  to  perform  estimation  of average annual soil loss
110       caused by sheet and rill erosion using The Universal  Soil  Loss  Equa‐
111       tion.
112
113       Example as part of landslide prediction process:
114       Figure:  A  model to perform creation of parametric maps used by geolo‐
115       gists to predict landslides in the area of interest.
116

EXAMPLE

118       In this example the zipcodes_wake vector data and  the  elev_state_500m
119       raster data from the North Carolina sample dataset (original raster and
120       vector data) are used to calculate average elevation  for  every  zone.
121       The  important part of the process is the Graphical Modeler, namely its
122       possibilities of process automation.
123
124   The workflow shown as a series of commands
125       In the command console the procedure looks as follows:
126       # input data import
127       r.import input=elev_state_500m.tif output=elevation
128       v.import input=zipcodes_wake.shp output=zipcodes_wake
129       # computation region settings
130       g.region vector=zipcodes_wake
131       # raster statistics (average values), upload to vector map table calculation
132       v.rast.stats -c map=zipcodes_wake raster=elevation column_prefix=rst method=average
133       # univariate statistics on selected table column for zipcode map calculation
134       v.db.univar map=zipcodes_wake column=rst_average
135       # conversion from vector to raster layer (due to result presentation)
136       v.to.rast input=zipcodes_wake output=zipcodes_avg use=attr attribute_column=rst_average
137       # display settings
138       r.colors -e map=zipcodes_avg color=bgyr
139       d.mon start=wx0 bgcolor=white
140       d.barscale style=arrow_ends color=black bgcolor=white fontsize=10
141       d.rast map=zipcodes_avg bgcolor=white
142       d.vect map=zipcodes_wake type=boundary color=black
143       d.northarrow style=1a at=85.0,15.0 color=black fill_color=black width=0 fontsize=10
144       d.legend raster=zipcodes_avg lines=50 thin=5 labelnum=5 color=black fontsize=10
145
146   Defining the workflow in the Graphical Modeler
147       To start performing above steps as an automatic process with the Graph‐
148       ical  Modeler  press the  icon or type g.gui.gmodeler. The simplest way
149       of inserting elements is by adding the complete GRASS  command  to  the
150       Command  field  in  the  GRASS command dialog (see figure below).  With
151       full text search one can do faster module hunting. Next, the label  and
152       the  command can be added. In case that only a module name is inserted,
153       after pressing the Enter button, the module dialog window is  displayed
154       and  it  is possible to set all of the usual module options (parameters
155       and flags).
156
157       Figure: Dialog for adding GRASS commands to model.
158
159   Managing model parameters
160       All used modules can be parameterized in the model. That causes launch‐
161       ing  the dialog with input options for model after the model is run. In
162       this   example,   input   layers   (zipcodes_wake   vector   map    and
163       elev_state_500m  raster  map) are parameterized. Parameterized elements
164       show their diagram border slightly thicker than those  of  unparameter‐
165       ized elements.
166       Figure: Model parameter settings.
167
168       The  final model, the list of all model items, and the Python code win‐
169       dow with Save and Run option are shown in the figures below.
170       Figure: A model to perform average statistics for zipcode zones.
171
172       Figure: Items with Python editor window.
173
174       For convenience, this model for the Graphical Modeler is also available
175       for download here.
176
177       The  model is run by clicking the Run button . When all inputs are set,
178       the results can be displayed as shown in the next Figure:
179       Figure: Average elevation for ZIP codes  using  North  Carolina  sample
180       dataset as an automatic calculation performed by Graphical Modeler.
181
182   Managing model properties
183       When one wants to run model again with the same data or the same names,
184       it is necessary to use --overwrite option.  It  will  cause  maps  with
185       identical names to be overwritten. Instead of setting it for every mod‐
186       ule separately it is handy to change the Model Property settings  glob‐
187       ally.   This  dialog includes also metadata settings, where model name,
188       model description and author(s) of the model can be specified.
189       Figure: Model properties.
190
191   Defining variables
192       Another useful trick is the possibility to set variables. Their content
193       can  be used as a substitute for other items. Value of variables can be
194       values such as raster or vector data, integer, float, string  value  or
195       they  may  constitute some region, mapset, file or direction data type.
196       Then it is not necessary to set any parameters for input data. The dia‐
197       log  with  variable  settings is automatically displayed after model is
198       run. So, instead of model parameters (e.g. r.import a v.import, see the
199       Figure Run model dialog above) there are Variables.
200       Figure: Model with variable inputs.
201
202       The  key  point  is the usage of % before the substituting variable and
203       settings in Variables dialog. For example, in case of a model  variable
204       raster that points to an input file path and which value is required to
205       be used as one of inputs for a particular model, it should be specified
206       in  the  Variables dialog with its respective name (raster), data type,
207       default value and description. Then it should be set in the module dia‐
208       log as input called %raster.
209       Figure: Example of raster file variable settings.
210       Figure: Example of raster file variable usage.
211
212   Saving the model file
213       Finally,  the  model  settings  can be stored as a GRASS GIS Model file
214       with *.gxm extension. The advantage is that it can be shared as a reus‐
215       able workflow that may be run also by other users with different data.
216
217       For example, this model can later be used to calculate the average pre‐
218       cipitation for every administrative region in Slovakia using the precip
219       raster  data  from  Slovakia  precipitation  dataset and administration
220       boundaries of Slovakia from Slovak Geoportal (only with a few clicks).
221
222   Handling intermediate data
223       There can be some data in a model that did not exist before the process
224       and  that  it  is  not worth it to maintain after the process executes.
225       They can be described as being Intermediate by  single  clicking  using
226       the  right  mouse  button,  see  figure  below. All such data should be
227       deleted following model completion. The boundary of intermediate compo‐
228       nent is dotted line.
229       Figure: Usage and definition of intermediate data in model.
230
231   Using the Python editor
232       By  using the Python editor in the Graphical Modeler one can add Python
233       code and then run it with Run button or just save it as a Python script
234       *.py.  The result is shown in the Figure below:
235       Figure: Python editor in the wxGUI Graphical Modeler.
236
237   Defining loops
238       In  the  example below the MODIS MOD13Q1 (NDVI) satellite data products
239       are used in a loop. The original data are stored as coded integer  val‐
240       ues  that  need  to be multiplied by the value 0.0001 to represent real
241       ndvi values. Moreover, GRASS GIS  provides  a  predefined  color  table
242       called  ndvi  to represent ndvi data.  In this case it is not necessary
243       to work with every image separately.
244       The Graphical Modeler is an appropriate tool  to  process  data  in  an
245       effective  way  using  loop  and variables (%map for a particular MODIS
246       image in mapset and %ndvi for original data name  suffix).   After  the
247       loop  component  is added to model, it is necessary to define series of
248       maps with required settings of map type, mapset, etc.
249       Figure: MODIS data representation in GRASS GIS after Graphical  Modeler
250       usage.
251
252       When  the model is supplemented by all of modules, these modules should
253       be ticked in the boxes of loop dialog. The final model and its  results
254       are shown below.
255       Figure: Model with loop.
256
257       Figure:  MODIS data representation in GRASS GIS after Graphical Modeler
258       usage.
259
260       The steps to enter in the command  console  of  the  Graphical  Modeler
261       would be as follows:
262       # note that the white space usage differs from the standard command line usage
263       # rename original image with preselected suffix
264       g.rename raster = %map,%map.%ndvi
265       # convert integer values
266       r.mapcalc expression = %map = %map.%ndvi * 0.0001
267       # set color table appropriate for nvdi data
268       r.colors = map = %map color = ndvi
269

SEE ALSO

271        wxGUI
272       wxGUI components
273
274       See also selected user models available from this git repository.
275
276       See also the wiki page (especially various video tutorials).
277

AUTHORS

279       Martin  Landa,  OSGeoREL,  Czech  Technical University in Prague, Czech
280       Republic
281       Various manual improvements by Ludmila Furkevicova,  Slovak  University
282       of Technology in Bratislava, Slovak Republic
283

SOURCE CODE

285       Available at: wxGUI Graphical Modeler source code (history)
286
287       Main  index  |  GUI  index  | Topics index | Keywords index | Graphical
288       index | Full index
289
290       © 2003-2020 GRASS Development Team, GRASS GIS 7.8.5 Reference Manual
291
292
293
294GRASS 7.8.5                                                  wxGUI.gmodeler(1)
Impressum