1g.gui.gmodeler(1) GRASS GIS User's Manual g.gui.gmodeler(1)
2
6 g.gui.gmodeler - Graphical Modeler.
7 Allows interactively creating, editing and managing models.
8
10 general, GUI, graphical modeler, workflow
11
13 g.gui.gmodeler
14 g.gui.gmodeler --help
15 g.gui.gmodeler [file=name.gxm] [--help] [--verbose] [--quiet]
16 [--ui]
17 Flags:
19 --help
20 Print usage summary
21 --verbose
23 Verbose module output
24 --quiet
26 Quiet module output
27 --ui
29 Force launching GUI dialog
30 Parameters:
32 file=name.gxm
33 Name of model file to be loaded
34
36 The Graphical Modeler is a wxGUI component which allows the user to
37 create, edit, and manage simple and complex models using an easy-to-use
38 interface. When performing analytical operations in GRASS GIS, the op‐
39 erations are not isolated, but part of a chain of operations. Using the
40 Graphical Modeler, a chain of processes (i.e. GRASS GIS modules) can be
41 wrapped into one process (i.e. model). Subsequently it is easier to ex‐
42 ecute the model later on even with slightly different inputs or parame‐
43 ters.
44 Models represent a programming technique used in GRASS GIS to concate‐
45 nate single steps together to accomplish a task. It is advantageous
46 when the user see boxes and ovals that are connected by lines and rep‐
47 resent some tasks rather than seeing lines of coded text. The Graphical
48 Modeler can be used as a custom tool that automates a process. Created
49 models can simplify or shorten a task which can be run many times and
50 it can also be easily shared with others. Important to note is that
51 models cannot perform specified tasks that one cannot also manually
52 perform with GRASS GIS. It is recommended to first to develop the
53 process manually, note down the steps (e.g. by using the Copy button in
54 module dialogs) and later replicate them in model.
55 The Graphical Modeler allows you to:
57 • define data items (raster, vector, 3D raster maps)
59 • define actions (GRASS commands)
61 • define relations between data and action items
63 • define loops (e.g. map series) and conditions (if-else state‐
65 ments)
66 • define model variables
68 • parameterize GRASS commands
70 • define intermediate data
72 • validate and run model
74 • save model properties to a file (GRASS Model File|*.gxm)
76 • export model to Python script
78 • export model to Python script in the form of a PyWPS process
80 • export model to image file
82 Main dialog
84 The Graphical Modeler can be launched from the Layer Manager menu File
85 -> Graphical modeler or from the main toolbar . It’s also available as
86 stand-alone module g.gui.gmodeler.
87 The main Graphical Modeler menu contains options which enable the user
89 to fully control the model. Directly under the main menu one can find
90 toolbar with buttons (see figure below). There are options including
91 (1) Create new model, (2) Load model from file, (3) Save current model
92 to file, (4) Export model to image, (5) Export model to Python script,
93 (6) Add command (GRASS module) to model, (7) Add data to model, (8)
94 Manually define relation between data and commands, (9) Add loop/series
95 to model, (10) Add comment to model, (11) Redraw model canvas, (12)
96 Validate model, (13) Run model, (14) Manage model variables, (15) Model
97 settings, (16) Show manual, (17) Quit Graphical Modeler.
98 Figure: Components of Graphical Modeler menu toolbar.
100 There is also a lower menu bar in the Graphical modeler dialog where
102 one can manage model items, visualize commands, add or manage model
103 variables, define default values and descriptions. The Python editor
104 dialog window allows seeing workflows written in Python code, either as
105 a basic Python script, or as a PyWPS script. The rightmost tab of the
106 bottom menu is automatically triggered when the model is activated and
107 shows all the steps of running GRASS modeler modules; in the case some
108 errors occur in the calculation process, they are are written at that
109 place.
110 Figure: Lower Graphical Modeler menu toolbar.
111 Components of models
113 The workflow is usually established from four types of diagrams. Input
114 and derived model data are usually represented with oval diagrams. This
115 type of model elements stores path to specific data on the user’s disk.
116 It is possible to insert vector data, raster data, database tables,
117 etc. The type of data is clearly distinguishable in the model by its
118 color. Different model elements are shown in the figures below.
119 • (A) raster data:
121 • (B) relation:
123 • (C) GRASS module:
125 • (D) loop:
127 • (E) database table:
129 • (F) 3D raster data:
131 • (G) vector data:
133 • (H) disabled GRASS module:
135 • (I) comment:
137 Figure: A model to perform unsupervised classification using MLC
138 (i.maxlik) and SMAP (i.smap).
139 Another example:
141 Figure: A model to perform estimation of average annual soil loss
142 caused by sheet and rill erosion using The Universal Soil Loss Equa‐
143 tion.
144 Example as part of landslide prediction process:
146 Figure: A model to create parametric maps used by geologists to predict
147 landslides in the area of interest.
148
150 In this example the zipcodes_wake vector data and the elev_state_500m
151 raster data from the North Carolina sample dataset (original raster and
152 vector data) are used to calculate average elevation for every zone.
153 The important part of the process is the Graphical Modeler, namely its
154 possibilities of process automation.
155 The workflow shown as a series of commands
157 In the command console the procedure looks as follows:
158 # input data import
159 r.import input=elev_state_500m.tif output=elevation
160 v.import input=zipcodes_wake.shp output=zipcodes_wake
161 # computation region settings
162 g.region vector=zipcodes_wake
163 # raster statistics (average values), upload to vector map table calculation
164 v.rast.stats -c map=zipcodes_wake raster=elevation column_prefix=rst method=average
165 # univariate statistics on selected table column for zipcode map calculation
166 v.db.univar map=zipcodes_wake column=rst_average
167 # conversion from vector to raster layer (due to result presentation)
168 v.to.rast input=zipcodes_wake output=zipcodes_avg use=attr attribute_column=rst_average
169 # display settings
170 r.colors -e map=zipcodes_avg color=bgyr
171 d.mon start=wx0 bgcolor=white
172 d.barscale style=arrow_ends color=black bgcolor=white fontsize=10
173 d.rast map=zipcodes_avg bgcolor=white
174 d.vect map=zipcodes_wake type=boundary color=black
175 d.northarrow style=1a at=85.0,15.0 color=black fill_color=black width=0 fontsize=10
176 d.legend raster=zipcodes_avg lines=50 thin=5 labelnum=5 color=black fontsize=10
177 Defining the workflow in the Graphical Modeler
179 To start performing above steps as an automatic process with the Graph‐
180 ical Modeler press the icon or type g.gui.gmodeler. The simplest way
181 of inserting elements is by adding the complete GRASS command to the
182 Command field in the GRASS command dialog (see figure below). With
183 full text search one can do faster module hunting. Next, the label and
184 the command can be added. In case that only a module name is inserted,
185 after pressing the Enter button, the module dialog window is displayed
186 and it is possible to set all of the usual module options (parameters
187 and flags).
188 Figure: Dialog for adding GRASS commands to model.
190 Managing model parameters
192 All used modules can be parameterized in the model. That causes launch‐
193 ing the dialog with input options for model after the model is run. In
194 this example, input layers (zipcodes_wake vector map and
195 elev_state_500m raster map) are parameterized. Parameterized elements
196 show their diagram border slightly thicker than those of unparameter‐
197 ized elements.
198 Figure: Model parameter settings.
199 The final model, the list of all model items, and the Python code win‐
201 dow with Save and Run option are shown in the figures below.
202 Figure: A model to perform average statistics for zipcode zones.
203 Figure: Items with Python editor window.
205 For convenience, this model for the Graphical Modeler is also available
207 for download here.
208 The model is run by clicking the Run button . When all inputs are set,
210 the results can be displayed as shown in the next Figure:
211 Figure: Average elevation for ZIP codes using North Carolina sample
212 dataset as an automatic calculation performed by Graphical Modeler.
213 Managing model properties
215 When the user wants to run the model again with the same data or the
216 same names, it is necessary to use --overwrite option. It will cause
217 maps with identical names to be overwritten. Instead of setting it for
218 every module separately it is handy to change the Model Property set‐
219 tings globally. This dialog includes also metadata settings, where
220 model name, model description and author(s) of the model can be speci‐
221 fied.
222 Figure: Model properties.
223 Defining variables
225 Another useful trick is the possibility to set variables. Their content
226 can be used as a substitute for other items. Value of variables can be
227 values such as raster or vector data, integer, float, string value or
228 they may constitute some region, mapset, file or direction data type.
229 Then it is not necessary to set any parameters for input data. The dia‐
230 log with variable settings is automatically displayed after the model
231 is run. So, instead of model parameters (e.g. r.import a v.import, see
232 the Figure Run model dialog above) there are Variables.
233 Figure: Model with variable inputs.
234 The key point is the usage of % before the substituting variable and
236 settings in the Variables dialog. For example, in the case of a model
237 variable raster that points to an input file path and which value is
238 required to be used as one of inputs for a particular model, it should
239 be specified in the Variables dialog with its respective name (raster),
240 data type, default value and description. Then it should be set in the
241 module dialog as input called %raster.
242 Figure: Example of raster file variable settings.
243 Figure: Example of raster file variable usage.
244 Saving the model file
246 Finally, the model settings can be stored as a GRASS GIS Model file
247 with *.gxm extension. The advantage is that it can be shared as a reus‐
248 able workflow that may be run also by other users with different data.
249 For example, this model can later be used to calculate the average pre‐
251 cipitation for every administrative region in Slovakia using the precip
252 raster data from Slovakia precipitation dataset and administration
253 boundaries of Slovakia from Slovak Geoportal (only with a few clicks).
254 Handling intermediate data
256 There can be some data in a model that did not exist before the process
257 and that it is not worth it to maintain after the process executes.
258 They can be described as being Intermediate by single clicking using
259 the right mouse button, see figure below. All such data should be
260 deleted following model completion. The boundary of intermediate compo‐
261 nent is dotted line.
262 Figure: Usage and definition of intermediate data in model.
263 Using the Python editor
265 By using the Python editor in the Graphical Modeler the user can add
266 Python code and then run it with Run button or just save it as a Python
267 script *.py. The result is shown in the Figure below:
268 Figure: Python editor in the wxGUI Graphical Modeler. In the Script
269 type combobox, the user can also choose a PyWPS export instead of a ba‐
270 sic Python script. A PyWPS process based on the model will be generated
271 then; for the PyWPS script, the Run button is disabled as users are ex‐
272 pected to include this script in their web processing service and not
273 to run it on itself.
274 Figure: Python editor in the wxGUI Graphical Modeler - set to PyWPS.
275 Defining loops
277 In the example below the MODIS MOD13Q1 (NDVI) satellite data products
278 are used in a loop. The original data are stored as coded integer val‐
279 ues that need to be multiplied by the value 0.0001 to represent real
280 ndvi values. Moreover, GRASS GIS provides a predefined color table
281 called ndvi to represent ndvi data. In this case it is not necessary
282 to work with every image separately.
283 The Graphical Modeler is an appropriate tool to process data in an ef‐
284 fective way using loop and variables (%map for a particular MODIS image
285 in mapset and %ndvi for original data name suffix). After the loop
286 component is added to model, it is necessary to define series of maps
287 with required settings of map type, mapset, etc.
288 Figure: MODIS data representation in GRASS GIS after Graphical Modeler
289 usage.
290 When the model is supplemented by all of modules, these modules should
292 be ticked in the boxes of loop dialog. The final model and its results
293 are shown below.
294 Figure: Model with loop.
295 Figure: MODIS data representation in GRASS GIS after Graphical Modeler
297 usage.
298 The steps to enter in the command console of the Graphical Modeler
300 would be as follows:
301 # note that the white space usage differs from the standard command line usage
302 # rename original image with preselected suffix
303 g.rename raster = %map,%map.%ndvi
304 # convert integer values
305 r.mapcalc expression = %map = %map.%ndvi * 0.0001
306 # set color table appropriate for nvdi data
307 r.colors = map = %map color = ndvi
308
310 wxGUI
311 wxGUI components
312 See also selected user models available from GRASS Addons repository.
314 See also the wiki page (especially various video tutorials).
316
318 Martin Landa, GeoForAll Lab, Czech Technical University in Prague,
319 Czech Republic
320 PyWPS support by Ondrej Pesek, GeoForAll Lab, Czech Technical Univer‐
321 sity in Prague, Czech Republic
322 Various manual improvements by Ludmila Furkevicova, Slovak University
323 of Technology in Bratislava, Slovak Republic
324
326 Available at: wxGUI Graphical Modeler source code (history)
327 Accessed: Saturday Oct 28 18:20:08 2023
329 Main index | GUI index | Topics index | Keywords index | Graphical in‐
331 dex | Full index
332 © 2003-2023 GRASS Development Team, GRASS GIS 8.3.1 Reference Manual
334GRASS 8.3.1 g.gui.gmodeler(1)