10th EC GI & GIS Workshop, ESDI State of the Art, Warsaw, Poland, 23-25 June 2004
TRANSCAT PROJECT AND PROTOTYPE OF DSS
1
2
J. Horak1, J.W. Owsinski2
VSB-Technical University, Ostrava, Czech Republic
Systems Research Institute – Polish Academy of Sciences, Warsaw, Poland
ABSTRACT
The paper describes an effort of developing a DSS meant to assist in integrated management
of transboundary catchments within the EU project TRANSCAT. The primary characteristics of
the DSS under development, with special emphasis on GIS-related functionality and potential
architecture are presented. The results of a state-of-the-art survey are shown. Then, the outline the
prototype elaborated for the DSS, concentrated essentially on the visualisation aspects is given.
Some conclusions from on-going work and experiences gathered are forwarded.
KEYWORDS: water management, web technologies, WFD
TRANSCAT PROJECT
The main goal of the TRANSCAT project (Integrated Water Management of
Transboundary Catchments) is to create an operative and integrated comprehensive Decision
Support System (DSS) that should provide the basis for water management, possibly close to
optimal, in the borderland regions in the context of EU Water Framework Directive
implementation. It will be able to cope with the complexity of the water resources systems and the
uncertainty of decision-making. The DSS will be built around modules that allow simulation of the
different climatic, topographic, environmental and socio-economic conditions of various EU and
candidate countries’ transboundary catchments.
The DSS developed will be implemented and put to work in five selected pilot areas,
representing a spectrum of European conditions (Bela/Biała river at the Czech/Polish border,
Pasvik river at the Norwegian/Russian border, Guadiana river at the Spanish/Portuguese border,
Mesta/Nestos river at the Bulgarian/Greek border, and Šumava catchment at the Czech/German
border). Thus, the DSS developed will be thoroughly tested on a variety of natural, socioeconomic and institutional settings.
SYSTEM REQUIREMENTS
At the beginning of the system development an identification of stakeholders, selection of end
users, analysis of their conditions and requirements for the target system were analysed.
To fulfil the task, various sources of information were used, namely the questionnaire, a
specification of stakeholders for proposed DSS, meetings organized with stakeholders in
individual pilot areas, and a preliminary SWOT analysis. The information thus obtained was
processed to a summary document, which identified the most frequent type of end users and their
conditions to implement DSS. The indicated problems and data sets were sorted and aggregated.
On the basis of responses to the questionnaire and other sources a classification of all stakeholders
and users by type of organisation was prepared.
1
10th EC GI & GIS Workshop, ESDI State of the Art, Warsaw, Poland, 23-25 June 2004
On the basis of existing knowledge, it is assumed the most important groups of end users for
targeting the TRANSCAT DSS are:
• public administration bodies on regional and local level (123 stakeholders are
documented now, quite often having declared an active interest in the system),
• companies for water supply and sewage (12 interested units documented until now),
• nature protection bodies (8 units with high importance for some areas, like Šumava).
The stakeholders pronounced also their problems in water management. A summary of
problems from questionnaires and other sources was prepared so as to understand the matter of the
problems, to propose the way the TRANSCAT DSS can help solving them, to identify the tools to
be used (mainly from the modelling and analytical domains). A problem catalogue was established
on this basis.
Thus, it is assumed that the most important modelling and analytical tools for the
TRANSCAT DSS are surface water flow models, rainfall – runoff models, precipitation models,
river system analysis and ground water flow and solute transport models.
The data requirements for main modelling tools were analysed and described along with the
existing data sources. The metadata structure (for the review of data sources in pilot areas) bases
on ISO 19115:2003. The metadata should be exploited also in data processing (uncertainty
management).
Likewise, a review of relevant European and World data was done to evaluate the possibility
of overcoming inconsistency of country-oriented data in pilot areas. The description of datasets on
central level is documented and published on the internet: http://transcat.vsb.cz/transcat (section
“archives”).
The obtained and summarised knowledge was transformed into a model structure using the
Unified Modelling Language. The model describes the position of stakeholders, their role in
legislative and administrative processes in water management, relation to data, problem catalogue.
Table 1 presents the “requirements” aspect of the model description. The requirements are divided
into two categories (packages) – primary and secondary, according the source of their
identification.
ANALYSIS OF SELECTED EXISTING DSS
When addressing the state-of-the-art pertaining to the subject matter and the realisation of the
TRANSCAT DSS we should distinguish three domains of importance. These three domains are
distinguished for both substantial and pragmatic reasons and thus do not pretend to any exhaustive
nor consistent classification. They are as follows:
• the existing know-how and experience embedded in the projects funded by the European
Communities, past and current, related to watershed management and associated DSS
systems (and, of course, other similar projects around the globe),
• the existing instruments meant for the modelling of water systems of similar character
(freshwater, catchment scale, integrated and/or separate aspects),
2
10th EC GI & GIS Workshop, ESDI State of the Art, Warsaw, Poland, 23-25 June 2004
•
the existing methodologies pertaining to the data and decision analytic aspects of the
potential DSS, with particular emphasis on the methods and techniques that have been
successfully implemented and tried out in practice.
Table 1: Formal requirements
Category Main requirements
Primary
Requirements
Category Functional
requirements
Category System requirements
Category End-user technical
requirements
Secondary
Requirements
Category System architecture
Main goal
Main focus
Modular structure
DSS bases
Visualisation of data
Querying and knowledge extraction
Subject-oriented information provision
Analysis/calculation
Two way communication
Modelling and simulation
Software architecture
Main subsystems of DSS
Dealing with fuzzy situations
Novelty methodologies
GIS based data base system
Multilingual
Support for Metadata
Configurable
Personalisation
Easy installation and upgrade for end-user
Small additional costs for end-user
Modular system
Open system
Distributed system
On-line data access
Security
Access to calibrated models
Thus, of special importance would be the existing experience with catchment-oriented
integrated water management DSS systems based on extensive modelling and multifaceted
decision analytic techniques meant for various kinds of decision situations. Alas, such experience
is very scarce, if, indeed, any at all. Therefore the importance of the present project and of the
results thereof.
The objective of the project is not to try to develop a new modelling system nor to rival these
individual models, but to develop a neutral core of DSS with appropriate functions for end users,
which might be able to communicate with and utilise a number of different models. For
communication, an individual interface can be used as a first step. Conform to the output from the
HarmonIT project, application of Open Modelling Interface is seen as a more advanced phase.
To fulfil such requirement it was essential to first evaluate the existing modelling software
systems from the point of view of aspects relevant for the project. Fourteen systems have been
evaluated in the framework of Transcat WP3 (MIKE-SHE; FLOODWORKS; WATERWARE;
WMS; GMS; SMS; HEC-FDA; HEC-RAS; HEC-HMS; PMWIN; CatchmentSIM; UPM;
FEFLOW; PHREEQC). Eight of them deal with hydrological issues, six with hydrogeological and
3
10th EC GI & GIS Workshop, ESDI State of the Art, Warsaw, Poland, 23-25 June 2004
four with other issues. Systems have been intentionally chosen to cover all situations in water
management domain with varying input parameters. Software packages have also been chosen
according to TRANSCAT requirements, i.e. possibilities of integrating these applications into the
TRANSCAT DSS.
Tutorial data provided by software developer, and in specific cases also real data, have been
used in testing. General evaluation of software packages, prepared through this process is useful in
deciding on the choice of appropriate modelling tools for the TRANSCAT DSS, for choosing
appropriate data, for model testing in pilot areas and last but not least for implementation of the
TRANSCAT DSS.
The description of the selected water modelling systems covered:
• information about embedded models (simulated processes, applied codes, the
mathematical base, verification, validation, preprocessor and/or postprocessor, the level
of simplification).
• scope of use (describe the field of applications).
• interoperability (linkage to GIS, distant management and control)
• price and licence terms
• support (updating, technical support, documentation)
• software features (operating system, design, user interface, modularity, provided
functions)
• DSS features (is information in the form suitable for decision support, capabilities for
analysing and comparing results from modelling process)
• input and output (input obligatory, optional, output)
• users (comments to Users - required level of knowledge, experience,..)
• documentation
• results of testing
• evaluation (advantages, disadvantages)
The results of evaluation can be summarized as follows (Tylcer 2004):
Application programming interface (API) and distant management abilities are among the
most valuable features for possible use in TRANSCAT DSS. FloodWorks and WaterWare include
some kind of API for distance management and usage. FloodWorks support Client/server multiuser access to data, models and results. Both FloodWorks and WaterWare support access through
Intra/Internet for distributed, remote clients. Other systems are not intended for such use.
Basic GIS interoperability (export/import) is provided by all evaluated systems. Some of
them adopt close integration with external commercial GIS, namely ESRI ArcView or ArcGIS.
This is the case of MIKE SHE GeoEditor ArcView extension, MIKE SHE DAISY GIS, HEC
GeoRAS, HEC GeoHMS. Close integration with ArcGIS is also option for WMS 7.
A DSS should also be easy to use, giving its users information they need to do their work
quickly in the form they can understand. This requirement is not satisfied by many of evaluated
systems. GMS, WMS, SMS, FEFLOW etc. are tools for professional hydrologists. The MIKE
family, even though equipped with a sophisticated GUI, is neither suitable for inexperienced users.
4
10th EC GI & GIS Workshop, ESDI State of the Art, Warsaw, Poland, 23-25 June 2004
It is very complex and input parameters have to be managed by users with basic knowledge about
hydrology and meteorology. Managerial staff cannot use it.
The systems evaluated can be divided in tree classes: modelling systems with DSS
functionality (WaterWare, FloodWorks), modular modelling systems – frameworks (GMS, SMS,
WMS, MIKE-SHE, PMWIN, FEFLOW), and monolithic systems (HEC-HMS, HEC-RAS and
HEC-FDA).
Evaluated systems cannot be simply integrated together. They are not designed for integration
needed in TRANSCAT DSS. Integration is possible on the level of underlying models. The results
of the HarmonIT project, when available, could be applicable in this point for TRANSCAT DSS.
SYSTEM ARCHITECTURE
TRANSCAT DSS is envisaged to comprise four major subsystems concerned with data
management, modelling, mapping and spatial analysis (geoprocessing) and DSS functionality:
• The mapping subsystem deals with the manipulation and visualisation of geographic
information. The associated spatial analysis subsystem implements a series of geographic
analysis functions for the geographic operations. Proximity and overlay analysis, as well as
functions for data conversion, are basic geographic operations.
• The modelling subsystem encapsulates various models, as mentioned before. The models
should be accessed through unified interface.
• The data management subsystem concentrates on editing and management of data needed in
other subsystems. Data access should be fast, secure and reliable. The data management
subsystem should handle large volumes of data of various formats and structures.
• The role of DSS subsystem is to specify decision alternatives and help in choosing between
them. The alternatives are analysed and ranked according to the criteria by which they can be
compared.
This is done in an interactive manner either through one of the MCDM methodologies
available, or through group decision devices, or finally through the use of bargaining and
negotiation tools.
The functionality of DSS can be described in UML using Business Process Model (see Fig.
1).
From the proper architectural standpoint it is possible to separate the system into three layers:
presentation, business logic and data management. The layers can be implemented on one
computer (single-tier architecture), or spread across separate machines (multi-tier architecture). In
the single-tier architecture the presentation (user interface), business logic (including, in particular,
the geographic processing functions), and data management functions all run on the same
machine. At the other extreme, in a three-tier situation the presentation tier (including the mapping
and spatial analysis subsystems) runs as a client on a desktop PC, the business logic for data access
runs on a middle-tier application server, and the data management tier (DBMS) runs on a proper
server. In this type of configuration the client has sophisticated capabilities and, in advanced
systems, can comprise several hundreds of megabytes of code (a so-called "thick" client
implementation).
5
10th EC GI & GIS Workshop, ESDI State of the Art, Warsaw, Poland, 23-25 June 2004
Model management
Model
management
Modeller
System
management
System & user management
Administrator
Data
management
Data managament
Operator
Database
Modelling and simulation
«supply»
«output»
Model data
«supply»
«supply»
Map generation
«supply»
«output»
«supply»
Map composition
«supply»
DSS
User
Enquiry
Modelling
Exploring
Ev aluation
Goal
«goal»
Decisionmaker
Figure 1: TRANSCAT DSS - UML business process model
An alternate, more centralised architecture is emerging that addresses these issues. At the
heart of this architecture approach is the idea that the application server tier can be enhanced to
encompass not only the data management subsystem but also the mapping and spatial analysis
subsystems. Running all the components on a server means that a thin client can be used to initiate
processing requests and display the results of tasks. Most common architecture approach in this
context is web application.
Fig. 2 illustrates the idea of TRANSCAT DSS architecture. The communication protocol is
HTTP or HTTPS (secure protocol). Open Internet standards (XML, SOAP) constitute a method
for integration of distributed services.
6
10th EC GI & GIS Workshop, ESDI State of the Art, Warsaw, Poland, 23-25 June 2004
Figure 2: The idea of TRANSCAT DSS system architecture
OPTIONS FOR ARCHITECTURE IMPLEMENTATION
Open source based system architecture with PHP
Based mostly on Open Source technologies – UMS Map Server, My SQL, Apache, PHP.
Public domain models are running on separated computer(s). This architecture is thoroughly
studied in the framework of DSS TRANSCAT prototype project.
7
10th EC GI & GIS Workshop, ESDI State of the Art, Warsaw, Poland, 23-25 June 2004
:MapServ er
:ModellingServ er
:Client
UMS
MapServ er
Model 1
Client
DSS Appl.
serv er
Model 2
System
architecture::
RDBMS
System
architecture::
Web serv er
Figure 3: Open source with PHP application server
Web services based system architecture
The term Web services (Web Services, 2003) describes a standardized way of integrating
Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet
protocol backbone. Thus, the web services standards are the glue that allows computers and
devices to interact.
XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing
the services available and UDDI is used for listing what services are available. Used primarily as a
means for businesses to communicate with each other and with clients, Web services allow
organizations to communicate data without intimate knowledge of each other's IT systems behind
the firewall.
Unlike traditional client/server models, such as a Web server/Web page system, Web services
do not provide the users with a GUI. Web services, instead, share business logic, data and
processes through a programmatic interface across a network. The applications interface, not the
users. Developers can then add the Web service to a GUI (such as a Web page or an executable
program) to offer specific functionality to users. Web services are a kind of application services.
Web services allow different applications from different sources to communicate with each
other without time-consuming custom coding, and because all communication is in XML, Web
services are not tied to any one operating system or programming language. Thus, e.g., Java can
talk to Perl, Windows applications can talk to UNIX applications.
The model of distributed web services is applicable to cross-border localities. The crossborder service integrating two or more national web services nodes into a one seamless whole can
be established. The integrating web service needs to be capable of carrying out on-the-fly
transformations of input and output data.
8
10th EC GI & GIS Workshop, ESDI State of the Art, Warsaw, Poland, 23-25 June 2004
Desktop application
TRANSCAT DSS in the form of desktop application should be built as framework for
components. Those components are bundled in one application with GIS and DSS modelling
subsystems. MS Windows developing environment (Win32 or .NET) can be used as far as Java.
Desktop application can switch user into Internet site, where the service patches, additional
components and information can be available. Desktop application can utilize web-based services.
The map layers published by OpenGIS compliant map services can be directly composed into
working map compositions.
Desktop system
HTTP
User interface
Internet map
serv ices
DSS
HTTP
Internet
information
serv ices
GIS
HTTP
Sc.Model 1
TRANSCAT
internet
serv ices
Sc.Model 2
Figure 4: TRANSCAT DSS built as desktop application
THE TRANSCAT DSS PROTOTYPE FUNCTIONS
To promote communication with end users we prepared a TRANSCAT DSS prototype,
which is available on http://gis.vsb.cz/transcat (under Results). The TRANSCAT DSS prototype
helps with the specification of future system end-users and their demands. The real data from the
pilot catchment of Bela in the Jeseniky Mts. in the Czech Republic are combined with simulated
data, also the DSS system functionality is simulated in part. The prototype allows for a better
communication with users and more accurate projection of the concept and the real system
functions.
The prototype bases on Free and Open Source solution (Linux, MySQL, Minessota Map
Server, Javascript). It has two main parts – map client and application server, which are under
development. As of now, basic mapping functions were implemented such as geographic data
visualization in map window, zoom in/out, information query. Some of the functions are advanced
e.g. attribute query “search” in the attribute part of geographical data, made possible due to the
database system.
9
10th EC GI & GIS Workshop, ESDI State of the Art, Warsaw, Poland, 23-25 June 2004
Figure 5. The TRANSCAT DSS prototype interface
It is presumed that TRANSCAT DSS will operate with heterogeneous data. So, data
management and documentation was given special consideration. The prototype uses a special
data manager, where layers are chosen and hierarchically sorted according to individual topics.
Metadata information for each layer can be accessed in the form of common documents stored
locally, or as a live connection to metainformation system (Czech national metainformation
system MIDAS). It is presumed that system will use metadata directly also while some operation
is in progress, e.g. in the course of uncertainty estimation connected with the result of data
processing. Data copyright is displayed in map window and is a firm part of map composition.
The system is organised as multilingual, where the administrator can define the setting for
each language (correct name for indicators, metadata description, copyright description, possibility
to visualise layers/data according national standards/conventions). All parameters are saved in the
system database and can be defined individually. The system should be able to work both with
local and distant deposited data and it is anticipated to exploit of web services for distant access to
data (mainly Web Map Service and Web Feature Service according to Open GIS Consortium
specifications).
The prototype’s graphic interface consists of tools area (GIS tools, metadata, layer agent),
map window area (visualisation information such as scale bar or coordinates), menu area
(modelling-analysis functions, query, and pre-defined map compositions), information services
10
10th EC GI & GIS Workshop, ESDI State of the Art, Warsaw, Poland, 23-25 June 2004
panel (connection to meteorological and hydrological information, predictions, warnings, weather
services on-line), and legend area allowing the user to organise layers (see Fig. 5).
Although the DSS should not provide only visualisation of data, it is still an important and
obligatory step in system development, needed for setting the basic functions of the DSS. The DSS
should facilitate the use of results from modelling. It is anticipated to enable the linkage between
the mapping and database subsystems, and the modelling subsystem.
Until September 2004 the prototype should offer all the proposed functionality in a simulated
way. Any stakeholder will be able to evaluate if the proposed functions of DSS address his
requests. The stakeholders would comment on these proposals and guide the subsequent system
development.
CONCLUSION
Given the plethora of available systems and applications, from open source to commercial, in
all the domains pertinent to the domain of TRANSCAT DSS (GIS, modelling, data handling), it
would appear that putting together of a workable DSS is not a problem. Yet, the requirements
associated with integrated and comprehensive transboundary water management constitute a true
challenge even in the presence of such possibilities. Thus, the TRANSCAT project has to envisage
multiple choices in terms of methodologies, technologies and functionalities, relying heavily on
the responses from end users. For this purpose the DSS prototype has been – and still is – being
developed, along with a number of trial applications, serving to test the proper assumptions for the
ultimate DSS. The positively tested functions and applications will then enter the final DSS.
ACKNOWLEDGEMENT
EC funded project: Integrated Water Management of Transboundary Catchments,
TRANSCAT, EVK1-CT2002-00124, 5FP - EESD.
BIBLIOGRAPHY
Tylcer O. Ed. 2004: Analysis of selected DSS for the water management. Deliverable 3.1.
Ostrava 2004, 134 pp. http://transcat.vsb.cz/transcat/php/archives/english/index.php?lang=en
Web Services, 2003, World Wide Web consortium. http://www.w3.org
11