Partners header

Demonstrator Technical Description
Case Study Data Requirements Specifications

Hardware, software, data requirement, networking, client-server architecture
DRAFT Release 0.2, September 24 1996
Author: Kurt Fedra

Case study data requirements for the DEMONSTRATOR

Data requirements cover:

  1. GIS data including spatially distributed model input;
  2. Object data including observation time series;
  3. Descriptor Definitions and Rules for the expert system;
  4. Hypertext content including meta data and user manuals;
  5. auxiliary data including model interface descriptions.

GIS Data

The case study is defined for a geographical domain that includes the entire area of interest, i.e., the city boundaries (Berlin, Athens, Gdansk) and the surrounding area that is considered explicitly. For reasons of screen layout, this domain should either be square, or have a landscape (aspect ratio: 4x3) or portrait (aspect ratio: 3x4) layout. Other aspect ratios are, in principle, possible, but require extensive editing of the layout configuration files and may not lead to "aesthetically pleasing" results. Please note that the screen layout is based on a 1280*1024 pixel resolution (also required for any PC client).

The following aspect ratios and sizes have been decided upon for the three demonstrator case studies:

Berlin 100 * 100 km square
Athens 100 * 100 km square
Gdansk 90 * 120 km portrait

The domain should be defined in terms of longitude/latitude (upper left and lower right corner) or the coordinate system used for the background maps. The GIS can handle any number of sub-areas within this domain (so-called case-study areas and sites), but cannot go BEYOND the domain boundaries (without re-implementing the GIS data base).

For the domain, and any sub-areas within the domain, for example, the region around a city and the city proper, the following map data sets (overlays) are recommended:

  • basic topographical and land-use map (usually 1:50:000 or 1:25:000; for the city proper, again depending on size, maps of up to 1:5,000 could also be used to support zooming into small neighborhoods, e.g., around a major source of pollution, individual street canyon, waste dump, etc.) in vector format (e.g., Arc/Info export format or any GIS format that can be converted with Arc/Info or GRASS) depending on the size of the area. Overview of the domain can be based on map resolutions of 1:50,000 to 1:500,000, depending on the level of detail required by the end user.

    This should include at least features like administrative boundaries; transportation lines (rail, roads), water bodies, built-up areas.

  • same map set, but scanned (with names) for better orientation;

  • satellite imagery, where available, LANDSAT TM and/or SPOT, for a recent land-use picture;

  • digital elevation model (gridded, typically 50x50 m spatial resolution and a minimum of 1 m vertical resolution). Where coastal waters are included (Athens, Gdansk) this should also include the corresponding bathymetry.

  • additional topical maps, e.g., geology, soils, vegetation, population density (in particular for the city area proper).

  • for the coupling of traffic emissions, a transportation graph (see also road segments in the objects data) is also required.

Please note that at least ONE map coverage is required to run the GIS system at all, but this could, in principle, be as simple as a single line (vector) overlay with the city boundaries. All other overlays (including scanned maps, satellite imagery, and DEM) are optional, but of course limit functionality if absent. Besides, several of the models require (gridded) input data sets that can also be included in the form of a map.

Object data

The main data base (top layer) of the ECOSIM server uses an object structure; objects describe important functional elements (see the class examples below), and the different (model) scenarios that represent alternative management options.

The following object classes are available or are under construction in parallel projects:

 Climate_stations              CS (including temperature, wind, 
                                  precipitation, cloud cover etc.)
 Air_Quality                   AQ measurement station
 Water_quality                 WQ measurement station
 Flow_measurements (rivers)    FS measurement station
 Settlements                   SE hierarchy of administrative units
 City district                 CD
 City blocks                   CB
 Point_source                  PTS (atmospheric, generic)
 Area_source                   ARS (atmospheric, generic)
 Line_source                   LNS (atmospheric, generic)
 Thermal_Power_Station         TPS
 Road segments                 RDS
 Road intersections            RDI
 Industries (generic)          IND
 Waste_water_treatment_plants  WWTP
 Process_Plants                PPLANT
 Chemicals_Storage             CST
 Waste_Dumps                   WDUMP
 Waste_Processing              WPROC
 Waste_Incinerators            WINC
 Port_Facilities               PORTF
 Airports                      AIRP
 Marshalling_Yards             MYARD
 Railway_Loading_Docks         RLDOCK
 Animal_farms_and_feedlots     AFF
 Irrigation_districts          IRR
 Sub-catchments                SC
 Dams_and_Reservoirs           DAM
 Natural_Lakes                 LAKE
 Abstractions_(river)          ABS
 Aquifers                      AQUF
 Wells                         WELL
 Scenic_sites                  SS

Each object class is defined by a header, specifying

  • NA A name of the object;

  • ID unique ID, which, by convention, is composed of the class label (see above) and an integer number;

  • location, defined by LO, LA, EL longitude, latitude, and elevation (meters above sea level) or x,y, and z coordinates in the respective domain coordinate system;

  • HY hypertext link, pointing to an explanation file with meta data and background information;

  • PI hypertext link, pointing to the pictorial and textual (multi-media) description of the object;

  • geographical reference, a table of symbolic labels describing (hierarchical) location references like City, district, block, with the associated overlay element. This provide the linkage to the GIS layer.

Depending on the type of objects, this is followed by a list (set) of parameters ( DE Descriptors, known to the expert system and defined in its knowledge base in terms of name, unit, legal range, and method of retrieval/estimation/deduction). Special object-specific data (like tables, graphs, time series etc. and the methods for the retrieval), are defined in a set of tables display function, and links to other objects.

As a special feature, in particular of all observation station objects as well as objects that include time series data, specific time series display and analysis tools, including a number of statistical tests and spatial interpolation, are available as methods to these objects through their display functions.

For a detailed description of the time-series data format and station object data, please refer to the respective AirWare Reference Manual pages.

Please note that the retrieval methods for any of the object's data can include access to the local file system, (networked) data bases (embedded SQL), or remote (Internet) data sources (URLs).

Once the (sub)set of objects required for each case study are selected, the detailed parameter lists for each object class can be defined. And example for the DAMS_and_RESERVOIR CLASS is given below:

 NA Big_Reservoir                    # object name
 ID LR01                             # unique ID
 LO 99.774                           # longitude
 LA 19.460                           # latitude
 EL 240.0                            # masl, base of the dam
 HY ./data/explain/reservoirs/information/LR01hlp.html
 PI ./data/explain/reservoirs/display/LR01exp.html      
 E  string_name                      # name (Descriptor)
 E  string_value                     # the actual value
 E  overlay                          # GIS overlay name, string
 E  attribute                        # overlay attribute, int
 D  State           Some_state         st_overlay 100 
 D  Municipality    Some_municipality  mu_overlay 200 
 D  Catchment       Some_catchment     ca_overlay 300 
 D  River_Segment   this_segment       ri_overlay 400 
 DE 1975               year_of_completion  # all defined as DESCRIPTORS ..
 DE limestone          geology
 DE 74.0               mean_annual_inflow
 DE 63.0               maximum_inflow
 DE 3.0                dead_storage 
 DE 17.5               useful_storage
 DE 0.0                flood_control_storage 
 DE 36.3               total_storage_capacity
 DE 17.5               current_storage_capacity  
 DE TE                 dam_type
 DE 480.0              dam_length
 DE 225000.0           dam_volume
 DE L                  spillway_type
 DE 2.08               spillway_head  
 DE 13.0               spillway_crest_length
 DE 65.0               spill_capacity
 DE concrete_channel  outflow_type
 DE 6.50               outflow_head  
 DE 0.0                outflow_capacity  
 DE 7800.0             irrigation_command_area
 DE eutrophic          trophic_state  
 DE 0.0                macrophyte_coverage  
 TABLE                 #pretty rough ....
 E storage_volume      #Mill.m3
 E elevation           #variables defined (units) as DESCRIPTORS
 E surface_area        #km2
 D 00.00  240.00  000.00
 D 01.00  242.50  040.00
 D 02.00  244.00  170.00
 D 03.00  244.80  280.00
 D 04.00  245.25  300.00
 D 05.00  245.50  330.00
 D 07.00  246.00  385.00
 D 10.00  246.80  460.00
 D 15.00  247.50  580.00
 D 17.50  248.00  620.00
 D 21.00  248.40  680.00
 D 32.50  250.00  860.00
 D 36.00  250.48  920.00
 E elevation           #masl
 E out_flow            #m3/sec
 D 2550.0   0.0        
 D 2560.0  50.0       
 D 2565.0  50.0
 D 2567.0 254.0
 E object_name     
 E object_ID       
 D Ramirez_(entradas) FS1080 
 D Atlacomulco  CS70
 D Arroyo_Toluca-Palmillas WQ390
 D Temascalcingo SS03
 D Flow_Station_Ameche    FS02
 D Flow_Station_Atenco     FS80
 TS FS15 monthly_flow                # flow station ref, ID and parameter
 E name
 E path_name
 D monthly_release     ./data/objects/time_series/ramirez.out

The corresponding descriptor definition for, e.g., useful_storage and trophic_sate are given below:

 T S
 U Mill.m3
 V very_small[ 1,    2,   5] /
 V small     [  5,  10,  15] /
 V medium    [ 15,  50, 100] /
 V large     [100, 250, 500] /
 V very_large[500,1000,5000] /
 Q What is the total useful storage capacity
 Q of this reservoir, ie., in terms of levels, 
 Q between dead storage and the flood control level ?

 T S
 V oligotrophic /
 V mesotrophic /
 V eutrophic /
 V hypertrophic /
 R 3000 / 3001 / 3002 / 3003 / 3004 / 3005 / 3006 / 3007 / 3008 / 3009 /
 R 3010 / 3011 / 3012 / 3013 / 3014 / 3015 / 3016 /
 Q How would you characterize the trophic state of the reservoir ?

Please note that the numbers under R refer to Rules in the Knowledge base, for example:

 RULE 3000
 IF           eutrophication_potential == very_large
 AND          [  nutrient_loading == very_large
              OR nutrient_loading == large
              OR nutrient_loading == medium ]
 THEN         trophic_state = hypertrophic

However, as a first step, for each case study we need:

  1. a list of object classes required (plus any suggestions for extensions of the classes currently supported);

  2. example data sets (preferably for some observation data, meteorology, and one or more major point sources of air pollutants, e.g., thermal power stations.

Descriptor Definitions and Rules

Object properties or attributes are represented by Descriptors which in turn are objects, and the Rules that are used to estimate their values in a specific context. Descriptors have a simple, keyword driven syntax:

 ozone                     # variable name
 S                         # type (symbolic/hybrid)
 U ppm                     # unit of measurement
 V very_low[0,1,2]         # range of legal values
 V very_high []            # described by a symbol (name) and
                           # corresponding numerical range
 M                         # model reference
 TS                        # data base reference
 R 1234/1235/1236/         # rule references
 Q              # question asked from the suer if all other methods fail

Hypertext Data

These consists of HTML formatted text (or minimally plain ascii), images (GIF or sunraster format), and the linkages (keys or anchors) connecting individual hypertext pages. These files are stored in the servers local file system, for example, ./data/explain, or anywhere on the network accessible to the ECOSIM server, referenced by the appropriate URL (Unified Resource Locator).

A few pages (plus images) describing each case study, as well as the meta data for the main data sources (maps, time series) and models (theory and assumptions, equations, literature references) should be available to build into the demonstrator, and serve as examples for a customized information system.

Auxiliary Data

For the startup screen and the header bar that displays the names/functions of each main module of the ECOSIM server, the interface requires:

  • an attractive (and typical) picture (GIF or good quality color photo or print) to be used as background for the first screen;
  • a logo (coat of arms) of the case study city, again as a GIF file or as a good color print/photo.

Copyright 1995-2002 by:   ESS   Environmental Software and Services GmbH AUSTRIA