Design Notes for an Opus/UrbanSim GUI

This page records some preliminary ideas about an integrated graphical interface for Opus and UrbanSim. The primary users of this GUI would be modelers (so it's not on the one hand primarily intended for software developers, nor on the other for non-technical users).

The GUI will be implemented in PyQT and QGIS, to take advantage of the open-source GIS capabilities of QGIS and to allow these to be integrated with the rest of the GUI. It should also interface smoothly with other tools such as matplotlib and R.

This initial design focusses on running scenarios. Next we'll flesh out and generating indicators and reports, and then model construction. Data preparation will be addressed later (perhaps using ESRI tools launched from this GUI).

Right now the design for the 'running scenarios' section is the most developed, and we propose to start implementation with that.

The Top-Level Window

The top-level window should provide access to all of the stages in the process. There is a tree-structured view on the left hand pane, which will eventually present the connected steps needed in preparing data, constructing models, running scenarios, and generating indicators and reports. Also in the long term, each step can have associated tests that can be run (ideally in an automated fashion, so that when there are changes upstream all the downstream tests can be run conveniently).

The contents of the main pane on the right will change depending on which stage in the process has been selected -- it may be a QGIS map, a chart, or a table, for example. When running a model there is a status bar at the bottom of the window giving the current simulation year, model that is running, and so forth. There is also a Python shell and a log window available (although generally the log window isn't visible -- we don't want the main feature of the running simulation to be scrolling text -- instead, it should be a regularly updated display of some useful indicators).

Database Browsing and Editing

All of the GUI components will make use of different database servers. We want to provide a tree-structured browser and editor for these, probably using !QTreeWidget. The UI for this might look something like:

* Database Servers
  - trondheim_mysql
  + localhost_postgress
    - Database ...
      - PSRC
      - MAG
        - Tables
          .... 
  - UrbanSim_cache       

Right-clicking on a database name (e.g. PSRC) opens up a view on the database schema. Right-clicking on a table opens up a browser/editor for that table.

Data Preparation

This part of the design isn't developed yet. We envision the top-level interface as providing a range of actions. The specific actions will often launch an ESRI tool (but the top-level list of actions and controls will be in PyQT in the Python world).

Model Construction and Configuration

A model system consists of a set of component models. The model system configuration can be inspected and edited using another tree view. For example, for model construction we might have

* Model construction
  - choice model
    - agent choice model
  - regression model
  - scaling model

Other notes from this part of the board:

Model system
  - ...
  - ...

specification, estimation, simulation, diagnostics

(not sure how all this hangs together ...)

Running Scenarios

Run configurations are made available using another tree-structured view, for example:

* Run Configuration
  - scenario database
  - output database
  - start year
  - end year
  - travel model configuration
  - indicators
  - diagnostic output
  - model system

A run configuration is just a description of what should be run. They can be loaded, saved, or saved under a new name (allowing copying some existing configuration). when used in the top-level window there are also controls to run, pause and resume, and to stop a simulation. When a simulation is paused we want to be able to open a Python shell and inspect current state, and also use iPython to access the python debugger (pdb).

In many cases the configuration components are shared with other parts of the interface, for example, the specification of the scenario or output database, and the set of indicators to produce as part of the batch run.

Generating Indicators and Reports

A configuration for producing a single interface specifies the variable or expression that provides the data, the output database from which the indicator is being generated, the kind of visualization, and any addtional parameters needed by the visualization (e.g. map info).

These single indicator configurations can be assembled into a configuration describing a set of indicators to be produced. This in turn can be used in a configuration describing a web page or report that uses these indicator results.