A Decision Support System in a Geographical Environment

Transcription

1 A Decision Support System in a Geographical Environment Roberto Abbondanza - Giuliana Bonello + Edoardo Bracci * Guglielmo Cresci * Alfredo Di Domenican tonio - - Ministero dell'ambiente - Roma + CSI Piemonte - Torino * CNUCE - CNR - Pisa Introduction The Italian Ministry for the Environment has defined three national networks of measurement stations for air, surface and ground water monitoring; each network has several hundred stations. Each station represents a specific geographical area (hereafter "related area") that has a homogeneous behaviour with respect to the phenomena to be investigated. This related area may be an industrial site, a town, a hydrographic basin, a ground water body, etc.. A number of chemical and physical parameters are measured at each station. The parameters sampled on a station depend on the features of the station and its related area. All the measurements are collected and stored in a National Environmental Information System (SINA). In SINA computers other data related to environmental monitoring and planning are collected and stored: some of them only contain alphanumeric information (Le. measurement values) but many contain geographical data (Le. location of the measurement stations). Tools are available to insert, modify and manage all the stored data. In particular, a Decision Support System (DSS) has been implemented to help the strategic planning of air quality, surface water and ground water quality and quantity on a national basis. Measurement values from the three national networks are used as DSS input data together with: population distribution in municipalities, provinces and regions; data on industry, agriculture and cattle breeding; geographical, hydrographical, geohydrological data; other useful data (soil usage, roads, aqueducts, etc.). 95

2 Partners involved in the project The DSS design and implementation were carried out by three partners: CNUCE was commissioned to design and develop the ground water DSS. CNUCE is an Institute of the Italian National Research Council (CNR) located in Pisa. Since 1965 it has been involved in computer science research and application fields. It has a staff of 120; 20 of whom operate on statistical and geographical applications. CSI was commissioned to design and develop the air quality DSS. CSI is a consortium of public and private institutions. Located in Turin, it was founded in 1977 to supply consortium members (but also external organisations) with computing facilities and computer based applications. It has a staff of 350: 40 of whom work in the fields of statistical and geographical systems. A third partner was commissioned to develop the surface water DSS. The three DSSs were designed and implemented in strict co-ordination in order to create applications with a common architecture and a uniform user interface. The DSS functional scheme According to user requirements, the three DSSs must be able to analyse the following four aspects (Fig. 1): 1) Data related to the resource state and represented by the measurement values stored in SINA host computers. Various statistical analyses must be executed on these measurements. 2) Data on environmental stress factors related to population, industries and agriculture. Pollution is linked to resource states by using simple models based on synthetic indicators. 3) Data defining the characteristics of the measurement station and the related geographical area (Land area description). These characteristics influence the relationships between polluting sources and resource states. 4) Data on actions. The Ministry and other organisations finance, coordinate and execute works of environmental protection and restoration. The DSS must consider these actions and it must be able to evaluate related results. 96

3 Land area description " Stress.. Resource factors state... ~~, ~ Actions Fig. 1: DSS functional scheme The geographical DSS approach The three DSSs must operate on both alphanumeric and geographical data. DSS technology only considers alphanumeric data, so it is unable to supply all the required functions. These functions include: navigation on geographical maps whose elements (points, lines, polygons) may be passive (background) or active (hotspots) elements through which the user can operate new selections and/or start processing functions; presentation of processing results (a statistical analysis, a model execution) as thematic maps. These are typical Geographical Information System (GIS) functions, but GIS applications generally do not have sophisticated statistical and modelling tools. Furthermore GISs generally have user interfaces specifically designed to be used by specialised technicians and are unsuitable for managers and decision makers. Only by combining DSS functions with GIS functions can we obtain a satisfactory result. Geo-DSS (also called Spatial DSS: SDSS) tries to integrate DSS and GIS technologies. Current technology doesn't supply geo-dss packages, so these applications must be implemented directly by users. DSS and GIS can be integrated by using: 1) a DSS structure where geographical functions have been added; 2) a GIS structure integrated with statistical and modelling functions; 3) a more complex system including both DSS and GIS packages that exchange data and results to give users the best of both technologies. The type of solution is generally driven by user requirements. Considerable interest in geographical functions suggests that a GIS-based application 97

4 should be used. On the other hand, when geographical elements only represent a background with no active element, a DSS approach may be a more convenient solution. We required geographical functions but also statistical tools and a simple user interface, so we followed the third type of approach, by using a GIS environment to pre-process geographical and alphanumeric data. Pre-processed data are then imported into a DSS application for further processing and presentation. The geo-dss architecture The architecture is organised into three execution phases (Fig. 2): 1) Data extraction. Input data are stored in SINA host computers in many mono-thematic data bases. So we have data bases for: measurement values collected from the three national networks; population and industrial activities summarised by municipality, province and region; geographical borders of municipalities, provinces, regions; features of the measurement station (and its related area); many other geographical data such as roads, hydrography, geohydrology, etc. All these archives supply input data to the geo-dsss. In the data extraction phase all the data associated with a single measurement station (and to its related area) are collected. Some geographical operations are made on these data (area computations, inclusion of a point into an area, etc.) and the results are transferred to the next phase (the geo-dss supervisor). This process is repeated for each measurement station. This processing phase is executed on SINA host computers in ARC/INFO and Oracle environments. 2) The geo-dss supervisor phase operates on a DSS server hosted on a PC. The DSS supervisor imports in a SAS environment data pre-processed during the extraction phase. Data are aggregated by measurement stations to reduce complexity and response times during the user session; they are stored in a geo-dss data base. This causes data redundancy because the same information is often stored both in a host computer and in the DSS server. Functions have been implemented to guarantee data consistency. Data extraction and geo-dss supervisor functions execute off-line, so these operations have no impact on host computers and geo-dss user operations. 3) Data processing and presentation phase. This phase is executed on the user's PC in a SAS environment. It accesses the geo-dss server to import all the required data (i. e. all the data associated with one or more measurement stations previously selected by the user). After this initial data transfer, all the functions execute in the stand-alone PC, so that users can operate both in a local or in a geographical network. 98

5 LAN DSS user / ~ "" Borders data base I Geo host -- '" C " Geo-DSS data base ~ / 1 Geo-DSS "'- -' Hydrography data base server I / ~ ""... T DSS user Alphanum host -- '-../ Measurement data base ~,:::, -::: '-./ Population data base Fig. 2: The geo-dss architecture Project evolution and implementation The DSS took about a year to be designed and implemented; most of this time was spent identifying user requirements, selecting and organising data. The application presented at the Italian SAS Users Group in October 1993 was a prototype implemented by using SAS/EIS. The prototype had some shortcomings: it was slow. Response times were generally too high; it didn't support geographical navigation. Only pre-defined maps were presented: no user modification was allowed on them; it only had pre-defined statistical and presentation functions. A first release of the geo-dss is now available; it took another four man months to be implemented. 99

6 It was implemented through SAS/ AF by using the Frame Technology. Two classes have been implemented to navigate on: geographical maps; measurement values. The geographical navigation class allows users to select the geographical area to be investigated. They can select what to display on maps by setting both passive and active elements: Passive elements (layers) only represent a background and supply information on land territory features and behaviour thus helping users to understand the phenomena they are investigating. In ground water analysis it is possible to display the following as layers: municipal borders, water flow directions, location of springs and wells. Active elements (hotspots) can be selected by using a mouse: the right hand button gets information about the element the hotspot represents. For instance, it is possible to get a description of the main features of a ground water body (average rainfall, estimated water supply, number of springs, etc.); the left hand button allows navigation to the next geographical level. From a nation-wide map, it is possible to pass to regional maps and, finally, to maps showing one (or more) measurement stations and their related area. There is no limit to the number of layers and hotspots the class can manage. Obviously the definition of many layers and hotspots increases the map's complexity so: the time required to draw a map increases. In the present implementation up to seconds are required to draw a map by using a high end 486 platform. It may be difficult to read maps with many elements. Simple zoom and pan functions have been implemented to partially overcome this problem. Each layer and hotspot requires its own data stored both in SINA and DSS data bases; a great number of layers and hotspots implies large amounts of data stored on disks. A number of push buttons are collected in a tool bar to allow users: to select layers and hotspots (layers and hotspots buttons); to return to a previous hierarchical level in the class (hierarchy button); to draw thematic maps (analysis button); to enlarge part of the map (zoom button); to reset the zoom and to show the map scale (options button). An alphanumeric navigation class is used to select and to show measurement values related to a measurement station. It allows users to select and dynamically modify: the parameter(s) and the time interval to be investigated; the time aggregation level (hour by hour, day by day, week by week, etc.); the type of presentation (tabular or various kinds of graph); the statistical function to be executed on data. A what-if analysis is also available (for the air quality and surface water DSSs) to relate environmental stress factors and pollution measures. Polluting loads due to one particular human activity (the resident population, a specific type of industry, etc.) are evaluated as product of an estimated unitary polluting load and the number of employees or inhabitants. 100

7 ~~~=t~~~'"1-~t;,"~"':~-~:"'%?-:--;~~"0"-'~~---~- i, The total polluting load in a geographical area is then evaluated as a sum of contributions due to the human activities operating in that area. Users can modify both the number of employees and the unitary emissions to simulate many different scenarios and verify their global effect. Final remarks The table in Fig. 3 summarises some evaluations on the geo-dss as it is today. In the table rows we list a number of elements representing the user requirements. The table columns report our current evaluation. along with future hopes for the less satisfactory items. Obviously many evaluations can also be seen as SAS system evaluations. Element Current Future hopes evaluation statistical processing very good geographic processing unsatisfactory SAS/GIS what-if processing very good portability very good alphanum. navigation very good geographic navigation sufficient SAS/GIS graphic presentation very good tabular presentation v~good thematic maps unsatisfactory SAS/GIS response time sufficient more powerful hw implementation time good better documentation total cost sufficient run time modules Fig. 3: Application evaluations The table shows that all the geographical functions (processing, navigation and thematic maps) have a not completely satisfactory evaluation. We believe that the GIS module of SAS system may be used to integrate the geographical navigation class functions. In fact, SAS/GIS could supply functions not available in our application (i.e. functions to simply write on a map the names of map elements such as towns, rivers, mountains, etc.) or with limits and shortcomings (i.e. the zoom function). \ \.. The table also shows that we expect to have better response times by using more powerful hardware platforms. Tests made on a Pentium platform gave encouraging results: response times were in the range of 1/3, 1/2 of the ones we experienced on 486 platforms. 101

8 Although we evaluated the time taken to implement the application as being good, a further observation is needed. Object oriented technology requires a problem approach different from traditional technologies, with considerable efforts in the first design phase leading to good results with a substantially reduced programming effort. It would be extremely useful to have the support of a complete, comprehensive, user friendly documentation. During our work we had some problems due to a lack of documentation so we applied to SAS Institute of Rome to get some support in programming the geographical and alphanumeric navigation classes. Finally, a complex application requires many SAS modules (we used SAS Base, FSP, AF, GRAPH, STAT and ETS) so it has a high license cost. When the application needs to be used by many users, this cost increases considerably; in some cases it limits the usage and benefits of the application. One solution would be a system with some kind of run time module, capable of selecting and loading only the system code strictly required by the application execution. This approach would reduce the license costs and in fact only one set (or a few sets) of SAS modules would be needed to implement and maintain the application, while users would only require a run time license which would be less expensive. Furthermore, the hardware configuration required to run the application would probably need less memory and disk space if a run time approach is used. Appendix: Samples of screen layout The following figures show some screens produced by the geographical arid alphanumeric navigation classes. 102

9 Fig. 4: The first map displayed by the geographic navigation class \ \.. 103

10 i ~.

11 ;~. ype of station: Spring Municipality: Spigno Saturnia River: Collection works: NO Water collection (115):. Type of spring:. Average flow (mc/s): 1.1 Altitude a.s.l: 52 Fig. 5: The second map displayed by the geographic navigation class. Mouse usage: the right hand button on a measurement station displays the station main features 105

12

13 Fig. 6: The third map displayed by the geographic navigation class. Layers button allows user to select available layers to be displayed on the map \ \., ' 107

14

15 MUNICIPAL CENTROID RELATED AREA CENTROID MEASUREMENT STATION Fig. 7: Hotspots button allows user to select available hotspots to be displayed on the map 109

16 "3... J:l! ~ I.' ~.... j \:.,y..... "'-3.~"'f.~... ~~~~~..,::.,:-~::;:-.::::-:::<::-~--~

17 ~ ~ '1\ ;,[;,tl:.;.~., " l ~i~ 1 ~ $ :j~ ''{; J:.J". ti ~ It ID ]~ }; -~. ~"~ g': j~ J ;.:,) ~,r,,r k; I>.~; f!' ~-.~' i ;': Fig. 8: Hierarchy button allows to jump to a previous hierarchical level (Regions or Provinces in this case) i'.: '~' $I 1 c' ;.~ -i.1 \.> \, }~ ~ t; ; 111

18

19 Fig. 9: Analysis button creates thematic maps on an user selected variable (Agricultural area in this case) 113

20

21 Fig. 10: Zoom button enlarges a part of the map around a point selected by the user 115

22

23 Fig. 11: Effect of the zoom operation 117

24 ; :": r...

25 Fig. 12: Alphanumeric navigation class displays measurement values on a station (P036) Fig. 13: The class allows graphic presentation of a selected parameter (C02) \ 119