# Specification of user interface, GIS and DBMS functions (updates)

Keywords:
Interactive functionality, menu system, GUI, software implementation, X Windows/Xlib, HTML.
Release 10 November 1997
Author: Kurt Fedra

Synopsis
 Programme name Telematics Application Programme Sector Environment Project Acronym ECOSIM Contract number EN 1006 Project title Ecological and environmental monitoring and simulation system for management decision support in urban areas Deliverable number D04.03 Deliverable title Specification of user interface, GIS and DBMS functions (updates) Deliverable version number 0.3 Work package contributing to deliverable 4 Nature of the deliverable Online Working Document Dissemination level Limited to Project Participants Contractual date of delivery PM20 (August 1997) Actual date of delivery PM20 (online) 10 November 1997 Author Dr. Kurt Fedra Environmental Software & Services GmbH Project technical co-ordinator Dr. Kurt Fedra, Environmental Software & Services GmbH tel: +43 2252 633 050 fax: +43 2252 633 059 E-mail: kurt@ess.co.at

### Executive Summary:

This document summarizes the specifications for the ECOSIM Demonstrator in terms of the user interface to the main systems components, namely the overall GUI, geographic information system (GIS), simulation models and object data base (ODBMS) functions.

This includes

• the graphical user interface (GUI) for
• local workstations access (based on X Windows/Xlib, Motif, CDE)
• remote access through PC based client software (http/HTML3, Netscape.)
• the hypertext help and explain system
• existing model interface
• system configuration files
• the geographic information systems (GIS) functionality, in particular for the display and analysis of
• geographical background data like geomorphology, land use, administrative boundaries;
• observation (monitoring) data and measurements
• spatial model results
• the systems data bases, including
• the internal object data structure used by the ECOSIM server
• linkages to external, existing data bases
• linkages to (on-line) monitoring networks.

### GUI for local workstation access

The graphical user interface for local workstation access is based on the MIT XWindows System V11 R.5. Please note that ECOSIM can also support as (remote) clients PCs or NCs (network computers) that can run a local X11 server and support the X11 protocol.

The ECOSIM Demonstrator uses CDE (Common desktop Environment) as a hardware independent window manager. Alternative window managers include uwm and xtwm.

The Demonstrator requires a screen resolution of 1280 by 1024 pixels with 256 (8 bit) simultaneous colors, or the support of a pseudo-color visual on a 24 bit (or higher) true-color system.

The GUI supports a fully menu driven, graphical and symbolic interaction with the Demonstrator. User interaction is almost exclusively through the mouse, selecting, dragging, dropping, and scaling options from a largely iconic menu or analog input utilities like sliders and selectors.

The GUI supports multiple languages, with the language elements of the interface defined through X Resource files (defaults files, see below).

### GUI for remote http clients

Remote user access within the ECOSIM on-site validation phase will be restricted to high-bandwidth (LAN) clients supporting the X11 protocol as described above.

Future developments (for a subsequent commercialization of the system) of the user interface for remote access through low-bandwidth connections (dial-up, ISDN, Internet) will be based on Java.

### GUI: hypertext system

The demonstrator features an embedded hypertext system that uses alternatively an internal hypertext data format design for high efficiency, derived from the syntax of the LaTeX typesetting software system, or an embedded HTML browser (under development).

The hypertext system is triggered by:

• information icons associated with every major system interface component (window, widget, pop-up;)
• all Descriptors used in the expert system, see below.
The data files for the hypertext system are located in one or several directories identified by an explain_path variable defined in the main system configuration file CONFIG

In addition to the hypertext pop-up browser, the system supports help messages and user prompts in a message bar at the bottom of the screen.

The syntax of the internal hypertext system is specified below:

xDrawHyperText(3n)         ACA ToolKit         xDrawHyperText(3n)

NAME
xDrawHyperText - (libxatk)  Draw hyper text.

SYNOPSIS
int
xDrawHyperText   (aca, win, ht, string, test, datapath)
x_environment_t *aca;
Window win;
x_hyper_text_t *ht;
char *string;
int test;
char *datapath;

ARGUMENTS
aca        Specifies our Environment.
win        Specifies window.
ht         Specifies 'x_hyper_text_t' used.
string     Specifies text to be drawn.
test       If test is 1 text is not drawn, if test is 0 text is drawn.
datapath   Path for picture file.

DESCRIPTION
Function draws data from 'string'. Specifications from  'ht'
structure  (e.g.  fonts)  are  used. Instead of normal ascii
text there are some special commands:

\font{fontname} ... to set a specific font; 'fontname' can be:

ns - standard (normal) font, small size,
nm - standard (normal) font, medium size,
nb - standard (normal) font, big size,
bs - bold font, small size,
bm - bold font, medium size,
bb - bold font, big size

\color{color number or name} ... to change color
\vspace{distance} ... vertical spacing; "distance" can be given
in pixels (99p) or lines (99l)
\hspace{distance} ... horizontal spacing; "distance" can be given
in pixels (99p) or in characters (99c)
\savepos{number} ... current drawing position is saved to
the position memory[number]; 0 <= number < 100
\setpos{number} ... current position is set to saved position,
don't forget to move current position down at the end of data,
it is used as the length of the window
\setxpos{number} ... current x-position is set to saved position
\setypos{number} ... current y-position is set to saved position
\hline{length} ... horizontal line; "length" can be given in
pixels (99p) or in characters (99c)
\vline{length} ... horizontal line; "length" can be given in
pixels (99p) or in lines (99l)
\linecolor{color} ... line color for vline, and hline
\linewidth{width} ... line width for vline, and hline
\begin{verbatim} ... begin of verbatim, maximal font
character width used
\begin{verbatim}{c} ... begin of verbatim, the width
of character 'c' used
\end{verbatim} ... end of verbatim
\%...remark...'\n' ... everything starting \% until
'\n'(including) is ignored
\_{text} ... subscript
\^{text} ... superscript
\- ... possible hyphenation in words, like hyper\-explain
\newline plus 'SPACE' or '\n' ... new line
\bigpara plus 'SPACE' or '\n' ... new paragraph below the
last used y-position (e.g. below icons too)
\leftmargin{margin} ... sets left margin; 'margin' can be given
in pixels (99p) or in characters (99c), or original margin
can be set (0)
\picture{icon file} ... draws icon file in directory 'datapath'
in current position, (either xwd or sun raster). 1 SPACE
or '\n' following the ending '}' of commands is ignored;
leading spaces of the line or after the picture are ignored.
\\ ... single backslash "
\x ... '\' in another combination - if HTA_FUNCTION was specified
in mask for xCreateHTStruct, specified function is called
with arguments:
function(aca, win, &text, &width, &length, option, test, ht->fdata);

The arguments 'text', 'width', 'length' and 'option' above are
the same as in 'xHyperTextSegment' function, other were specified
here. It should return 1 if successful, 2 if specified command was
found in function but something was wrong or 0 if command was not found.

If test is 1, nothing is drawn but the  length  of  text  is
calculated.  Drawing  is simulated and current position like
after drawing is returned  in  'ht->cts->cx'  and
'ht->cts->cy'.

NOTE
See xhypertext.h
RELATED COMMANDS
xTSDrawString, xCreateHTStruct, xFreeHTStruct
FILES
libxatk/xDrawHypText.c
stdio.h
string.h
xaca.h
xhypertext.h
rasterfile.h
xfproto.h
xatk_int.h

libxatk             Last change:  Jul 20 1996


### Model interface

Model interfaces consist of two major components:

• Scenario specification (input editing)
• Analysis of results (display and analysis)

The specification of a scenario consists in a combination of option selections (e.f., pre-defined emission and meteorological scenarios) and setting of specific values such as scaling factors.

For these tasks, the interface provides a set of standard tools such as list and file selectors, as well as analog editors (sliders) that support hybrid representation (numerical ranges and symbolic ranges) of variables, represented by the Descriptors of the expert system.

The analysis of model out is based on functionality similar to that described for the GIS.

### System configuration files

Several aspects of the ECOSIM Demonstrator interface are data driven. These data are coordinated by a set of configuration and defaults files, associated with individual functions groups and major modules and sub-systems.

The overall configuration file resides in the systems main (working) directory is in named CONFIG. A typical CONFIG file example looks like:

############################################################
#   List of modules present
#   ECOSIM - Berlin                            1997 10 30 kf
############################################################

setenv  ACATKDIR    /d0/acatk

############################################################
#   load the defaults for each module in order specified
#   (a CONFIG file must be present in each directory.
#   This CONFIG file loads defaults only for that directory)

set defaults-load-path  ${ACATKDIR}/app-defaults \\ /p5/ETS/defaults/ets-defaults \\ ./defaults ############################################################ # paths are searched (depth-first) in specified order # set images-search-path${DATADIR}/icons ${ACATKDIR}/images \\${DATADIR}
set explain-search-path ${DATADIR}/explain \\${ACATKDIR}/explain/english ${DATADIR} \\${DATADIR}/icons

############################################################
#   load the KB for each module in order specified

############################################################


The CONFIG files specifies several data pathes which in turn may contain CONFIG files, e.g., for the expert system's knowledge base or for the object data bases including observation time series (see below).

The most important group of configuration files are the systems default files, referred to by the defaults-load-path. In the respective directories, configuration files control which files are loaded, and in which sequence (overloading applies):

#################################################
### Configuration file for ECOSIM system
###
#################################################
### application layout files for large screen
LAYOUT_HI
gis.hi
isc_inter.hi
pbm.hi
areasel.hi
optim.hi
windfield.hi
pse.hi
metdata_disp.hi
ts.hi
END
#################################################
### non-layout files
NONLAYOUT
palest.nonlayout
tsdanalysis.nonlayout
nonlayout
END
#################################################
### application english language files
LANG
app_english
spirs
END
#################################################


The X11 systems Resource manager is used to manage the defaults from these files, using the well known hierarchical reference and overloading scheme, illustrated in the (partial) example from the ECOSIM nonlayout default file below:

*project.name:              Ecosim
*data.dir:                  ./data/
*icon.dir:                  icons/
*bitmap.dir:                bitmaps/
*raster.dir:                rasters/
*explain.dir:               explain/
*source.dir:                sources/
*weather.dir:               weather/
*output.dir:                output/
*xps.dir:                   ./
*domain.dir:                KB/
*database.dir:              databases/
*isc.lt.output.dir:         lt_scenarios/
*isc.st.output.dir:         st_scenarios/
*default.weather_file:      DEFAULT_weather
*default.substance_file:    DEFAULT_substances
*default.technology_file:   DEFAULT_technology
*default.source_file:       DEFAULT_sources
*default.site_name:         City of Vienna
*default.scenario_name:     Scenario-1
*descriptor.file:           Descriptors
*htmlpath:                  /p2/AIRWARE/ECOSIM/HTML

*infowin.icon:              data/icons/info_tiny
*main.analysis:             1
!----- ecosim_main background logo
*background.logo:           ecosim_logo
*background.lx:             50
*background.ly:             250
*background.color:          0
!------


### GIS: background data

The basic GIS functions for background data display include:

• display of overlays (points, lines, polygons, cell grids, rasters, DEM, spatial model results) from a (hierarchical) list of available overlays; overlays are selected or de-selected by clicking them from the list of available overlays;

• toggling on/off of features within an overlay; a specific overlay editor allows to select or de-select individual elements (legend entries);

• restacking of overlays displayed; in the selector of active overlays, an overlay entry can simply by dragged and dropped with the mouse pointer;

• display of satellite imagery or scanned maps as a background to the map overlays; where available, sub-selectors offer alternative sets of satellite imagery or aerial photography;

• arbitrary zooming (arbitrary selection of location and size of the zooming window); zooming uses a salable window that the user can move, shrink and enlarge, maintaining aspect ratio;

• multiple resolutions with transparent switching between resolution within a map set;

• support for tiling of large maps for increased performance;

• highlighting and color editing of map (legend) features;

• switching from one to a four window mode, with four synchronized map windows;

• query and read-back function for map attributes; for classified (color coded) overlays representing continuous variables, the actual raw data will be read back;

• cross hair cursor with selectable line color and thickness read back current position in the application's world coordinates; synchronized in the four parallel windows;

• 3D display of digital terrain models (or other numerical data such as model results or spatially interpolated measurement data) in arbitrary zooming states: overlays including satellite imagery may be draped over the DEM;

• 3D display of elevation data over a 2D map background with Gouraud shading; position and vertical scaling of the 3D display is interactively selected by the user;

• arbitrary interactive 3D rotation of the display window (roll, pitch, yaw);

• vertical stretching and positioning of the 3D display;

• interactive selection of 3D overlays;

• satellite imagery display in 3D (draping);

• control of lighting source location and intensity for the shading;

• animation of time series of maps (cell grids, lines/polygons, attribute time series); the animation features include both continuous and step-by-step animation;

• extensive data import and export facilities linking to all major standard GIS, image processing and CAD systems;

• dynamic linkage to the (optionally) embedded public-domain GRASS GIS for special data capture and analysis functions such as digitizing, map conversion and geo-correction, etc.

• hardcopy output (HP-GL, PostScript);

• support of WWW clients and Internet access (Netscape, Java);

• hypertext (multimedia in HTML format) on-line user manual, help functions, and metadata display;

• access to spatially referenced object data such as observation time series, compound objects (eg., emission sources, industries, water bodies, settlement, parks and nature reserves, etc.); objects in turn provide linkages to (optional) environmental simulation models and a rule-based expert system for environmental assessment and data interpretation.

• spatial analysis functions such as interpolation of spatial observations (station data);

• special support for network data, including an interactive network editor (transportation networks, water resources (rivers and canals) networks, utility networks (sewers, pipelines, electricity, etc.) linked to a range of editing and display functions for network 9arc) attributes, as well as network analysis (routing, shortest path, etc. functionality;

Map sets in the GIS can be hierarchically structured, ie., a regional GIS data set can contain several local, more detailed case study sub-regions, each with their individual map sets.

### GIS: spatial model results

Model output generated by spatially distributed models (all model in ECOSIM are spatially distributed) can be viewed, within the framework of the GIS, as an additional (but dynamically generated) map overlay. All functionality specified above applies, including the 3D display of functional surfaces (without shading).

An important feature for the interpretation of model results is the possibility to stack (line) overlays on top of the model results (e.g., street networks for orientation), and use the four parallel window mode for direct visual comparison.

Most analysis functions such as overlay analysis or buffer analysis are methods available to specific assessment tools, or are performed directly as part of the model result post-processing at the level of the model interface.

### DBMS: object data

Object data are managed in a manner similar to the system defaults (data) files. A main CONFIG files in the ./data/objects directory enumerates classes and (static) members:

#########################################################
# OBJECT DATA BASE CONFIGURATION FILE
#
CLASS
ISC_Scoping_Model MO
ENDCLASS
CLASS
PBM_Scoping_Model MO
ENDCLASS
CLASS
REGOZON_Forecast_Model MO
ENDCLASS
CLASS
MEMO-DYMOS_Planning_Model MO
ENDCLASS
CLASS
MEMO_Meteorological_Forecast MO
ENDCLASS

CLASS
Air_Quality CS
E Krantorweg        CS001 ./data/objects/air/Krantorweg.dat
E Am_Vierrutenberg  CS003 ./data/objects/air/Am_Vierrutenberg.dat
E Buddestrasse      CS005 ./data/objects/air/Buddestrasse.dat
E Roedernallee      CS006 ./data/objects/air/Roedernallee.dat
E Pionierstrasse    CS007 ./data/objects/air/Pionierstrasse.dat
E Bachstrasse       CS015 ./data/objects/air/Bachstrasse.dat
.............

The reference to the actual location of the data can be a local file, a database retrieval methods (SQL), or a URL specifying a network address:
E Roedernallee      CS006 URL http://www.ess.co.at/ECOSIM/Roedernallee.html
E Pionierstrasse    CS007 URL http://www.ess.co.at/ECOSIM/Pionierstrasse.html
E Bachstrasse       CS015 URL http://www.ess.co.at/ECOSIM/Bachstrasse.html

The individual objects (classes) are defined by TEMPLATES. AN example is an air quality observation station object:
################################################
############################# OBJECT TEMPLATE
NA Bachstrasse
ID CS015
LA 21882.190265909
LO 21277.1038011889
EL 40
HY file:/ECOSIM/HTML/berlin/html/blume_info.html
TABLE
georeference
E string_name
E string_value
E overlay
E attribute
D Land      Berlin      boundaries  001
D Gemeinde  Berlin      city_limits 002
D Bezirk    Tiergarten  districts   010
D Strasse   Bachstrasse streets     034
END_TABLE
TS ./data/stations/air/015_SO.asc Sulfur_Dioxide


#### Time series analysis

The time series data managed (displayed and analyzed) by the station object are referenced by the object. This reference can again be to a local file, possibly to a network drive:

TS host:/drive0/data/stations/air/015_SO.asc Sulfur_Dioxide

an (embedded) SQL call, or a URL, like in the above example.
ID 015
NA 015
ME Sulphur_Dioxide
DE Sulphur_Dioxide
BE 199401010030
ST 30
NV 49008
22 22 21 18 15 13 11 10 9 10 12 12 14 14 13 13 14 14 15 17 16
17 17 16 16 16 16 16 15 16 17 21 19 21 22 27 24 18 13 14 13 12
12 12 12 12 11 10 9 10 10 10 9 9 11 11 12 13 15 18 21 22 22 25
25 26 39 54 49 41 38 34 28 27 30 50 61 77 83 55 61 63 5 3 51 46
42 40 41 38 40 43 44 40 36 36 32 27 23 19 18 19 18 17 17 17 20
21 24 26 26 26 29 30 28 30 32 36 33 30 31 34 34 31 33 33 38 36
43 47 4 2 41 40 37 38 42 37 32 35 48 55 61 69 76 73
...............


#### Embedded expert system

The embedded expert system uses a backwards chaining first-order logic inference engine with numerous extension in its inference strategy, and operates on (object) Descriptors as it variables.

A formal description of its syntax is provided in: Embedded Expert System Specifications

The main objectives of the expert system are to:

• ensure that user specifications area complete;
• ensure that user specifications area consistent;
• ensure that user specifications area plausible.
On the model output side, the expert system can be used for the analysis of complex (spatially distributed, dynamic, multiple variables) data sets, translating them into a simple statement like: Air quality standard violated

Interface to the expert system is through an interactive dialogue, where the inference engine requests user input if and when required. This includes the display of defaults and available option, a detailed specification of the question (in hypertext format), and possibly the (optional) display of the rule currently being evaluated.

After the expert system has reached an intermediate or final result, the user can trace the conclusions step by step through the inference tree, displaying individual rules and the inputs. In addition, a Knowledge Base Browser can display sets of Rules and the related Descriptors in a hierarchical representation corresponding to the inference tree structure.

#### DBMS: linkage to existing data bases

Database linkage is achiever through the methods available to the objects. Data retrieval to instantiate an object in a given context include:

• retrieval from local files
• retrieval from network files
• retrieval through URLs (directly for HTML files or though server side cgi scripts)
• retrieval through SQL database connections.
The main requirement for access methods to DBM systems are:
• sufficient network connectivity
• appropriate access privileges
• support of the common protocol (like embedded SQL)
• availability of an httpd daemon (for URL based requests).

For the user, access to an external data base should, in principle, be transparent unless the fact is relevant for the interpretation of the data.

#### DBMS: linkage to on-line monitoring data

The linkage to on-line monitoring data is equivalent to the linkage to data bases. It uses an http request (POST) to fetch data through a cgi script at the server side. Alternatively, within a LAN configuration, the client-server protocol supported by the DBMS (like embedded SQL or NETSQL) can be used directly.