Demonstrator Technical Description
|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.
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 TABLE georeference 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 END_TABLE 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 .... morphometry 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 END_TABLE TABLE default_policy 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 END_TABLE TABLE links E object_name E object_ID D EPCCA TP01 D Ramirez_(entradas) FS1080 D Atlacomulco CS70 D EPCCA IN01 D Arroyo_Toluca-Palmillas WQ390 D Temascalcingo SS03 D Flow_Station_Ameche FS02 D Flow_Station_Atenco FS80 END_TABLE TS FS15 monthly_flow # flow station ref, ID and parameter TABLE time_series E name E path_name D monthly_release ./data/objects/time_series/ramirez.out END_TABLE
The corresponding descriptor definition for, e.g., useful_storage and trophic_sate are given below:
DESCRIPTOR useful_storage 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 ? ENDDESCRIPTOR
DESCRIPTOR trophic_state 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 ? ENDDESCRIPTOR
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 ENDRULE
However, as a first step, for each case study we need:
a list of object classes required (plus any suggestions for extensions of the classes currently supported);
example data sets (preferably for some observation data, meteorology, and one or more major point sources of air pollutants, e.g., thermal power stations.
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:
DESCRIPTOR 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 ENDDESCRIPTOR
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.
For the startup screen and the header bar that displays the names/functions of each main module of the ECOSIM server, the interface requires: