Sensor Web, Geoprocessing, Security & GeoRM, Geostatistics, Semantics, 3D, Ilwis, Earth Observation

Modelling scenarios

November 10th, 2015 @ 12:12 by Martin Schouwenburg
Posted in Communities, ILWIS

One of the new things in Ilwis4 is the modeller. The modeller is a complex set of tools that tries to “model” the behaviour of dynamic spatial systems in several conceptual layers. In a crude way, one could say that it is a GUI for the script. This is essentially true, but it doesn’t do justice to the whole idea behind the modeller.

The ideas around it are still being developed, but basically (as it looks now) it contains a number of layers.

  1. Workflow builder: The lowest layer is the workflow builder. This is similar to “modellers” from other packages, such as ArcGIS. Operations are connected by flows and conditions and result in some desired output(s). The operations consist of all the operations plus all the workflows Ilwis4 knows. In Ilwis terms, a workflow is an operation. This layer is rather technical in the sense that all the nuts and bolts of operations are accessible and can be tweaked. It will probably be possible to insert your own python code snippets as seperate “operations”.
  2. Interactive input layer: The nuts and bolts might be too technical, so the purpose of this layer is to provide a suitable friendly interface to determine the details of the inputs (if needed). The internals of the workflow itself are not relevant at this level, just what goes in and what comes out. For example, there might be an URL to an input map within the workflow. As such, the URL doesn’t provide much extra information about the nature of the input data. The user might know, but that is by ‘chance’. In this layer the user is presented with much more metadata, previews and other details about the possible inputs to make a proper selection for the input The idea is to seperate the user from the nitty gritty details of the inputs/outputs and workflow technicalities and to focus more on the semantics of what goes into an operation.
  3. Dynamic modelling: The purpose of this layer is to view the model as a whole and to be able to tweak its input parameters interactively, in value, not in nature. Sounds a bit vague? It is, so let’s give an example. Suppose you have an evaporation model that is, among other things, dependent on temperature. With a set temperature and assuming the rest of the parameters are constant, the system will always produce a certain output. But what would happen if I am able to modify the temperature in a continous way over a certain range? The model would dynamically generate a number of outputs that showed me how temperature effects the model. The idea is to have (depending on the nature of the input) suitable controls for input parameters that can be interactively changed (e.g. a slider) and produce a whole set of outputs that represent the dynamic behaviour of a model.
  4. Conceptual layer: This describes in text and other media what the model is all about. Its a static layer (mostely).

At the moment we are busy with the first layer (see the example below).


There is still a lot of work to do.

A special export will enable one to export the model to a python script, which can run independently of Ilwis4 (not of ilwis-objects). We will not offer a reverse process, since this is a bit too complicated.

The ideas behind the whole modeller are still under developement. Will it be 4 layers, or 3, or 5? At the moment I have explained my current understanding of the whole process, but that might change.

Note that the modeller doesn’t replace the script (editor). That will still remain.


  1. Thank you for your work!) It’s interesting idea because users can improve python coding level by learning python scripts. Does the modeller have special features? WxGUI Graphical Modeler in GRASS also can convert models to python code. Actually good thing in ilwis 3.3 was excellent documentation. E.g. there were manuals in ilwis 3.3 how to make slope and aspect maps and users could create their own well-working functions. Possibly programmers had spent less time to make user-friendly well-working functions by making very good manual for script functions. It’s just my thoughts out loud:)

    Comment by Arseniy — November 11, 2015 @ 14:40
  2. Yes the workflows can be converted to python script. Furthermore we allow things like workflows in workflows (etc) so nesting. Most of the map visualization can be done through the modeller (if you want ofc) as all manipulation of the mapwindow ( adding layers, zooming, colors , etc…) are script command now, or better said, available as script commands. And of course the purpose of the extra layers is to dynamically tweek your models to see what the effect is of certain things

    Comment by Martin Schouwenburg — November 11, 2015 @ 15:52

RSS feed for comments on this post.

Leave a comment

Time limit is exhausted. Please reload CAPTCHA.