Jakub Talaš

Tomáš Gregar
email: xgregar@fi.muni.cz

Tomáš Pitner

Semantic Wiki in Environmental Project Management

Keywords: environmental project management, semantic wiki, RDF

Advanced management of environmental data requires appropriate metadata and tooling. Moreover, contemporary environmental data is heterogenous, encompassing also data about people, environmentalyrelated projects, and documents. Also geographical-and time-related information are vital for any environmental data and should be supported. To satisfy these requirements, "semantic wikis" represent suitable tools but usually requiring knowledge management skills. In this paper, we present a semantic extension to project-management tool Trac, enabling advanced but user-friendly querying in semantic data stored in the system and its visualization. As it builds upon the general concept of RDF-based semantic data, it can be freely extended into other contexts and deployed in various environmental management applications. We also discuss automatic formal visualization of semantic data. Such process significantly lowers the requirements on users in preparing the visualization in domains like environmental studies -and also helps to build Linked Data-aware and better human-readable interfaces of semantic data repositories.

1 Semantic wiki in real project management Since many (if not a majority) of modern systems for computer-aided environmental project management require not only the baseline, generic functionality and collaborative content creation but also its sharing and publication. The idea of Semantic Web builds upon the assumption that the data should be accessible, reusable and even re-purposable. So they should be accompanied by rich metadata sets based on standardized (or commonly-agreed) ontologies wherever applicable. However, their key users are usually not experts in knowledge management, they are not capable of operating advanced semantic tools like ontology editors. They like to work with really simple tools, editing a wiki is the most "technical" activity that can be expected in this terms. On the other hand, we might need at least some support of complex functionality like semantic querying. It enables to automatically present selected data about projects, people, their participation and progress on wiki pages. The wiki is no more a tool for fast collaborative creation of static textual content by end-users and starts to be a powerful instrument to present anything stored in a semantic repository.

In an environment targeted to software projects, these requirements are even amplified, cf. [START_REF] Kadenbach | Benefits and Challenges of Using Collaborative Development Environments with Social Software in Higher Computer Science Education[END_REF]. The members of a project team must share a common environment, see all relevant analytical documents, and contribute to discussions with the clients. All these activities intensively deal with content. For instant content creation, wiki systems became a de-facto "golden standard" as a mean to share, present and exchange information, and are present in nearly all project hosting and management platforms such as Sourceforge.net, Google Code, Codeplex.com, or github.org, among others. They are less demanding than online office-like suites like Google Docs though they still allow user to create and edit web content without a need to know languages like HTML/CSS or to have physical access to the web server.

There exist many implementations of such interface, based on different languages and storage databases1 -like MediaWiki (PHP and MySQL), Dokuwiki (PHP), Twiki (Perl) etc. An integrated Wiki is also an inevitable part of the (installed) open-source project management system Trac2 being used by many open-source projects as referred later.

2 Semantic support in existing wiki systems However, the vast majority of systems run without support for semantics. Only few wikis are built with semantic capabilities [START_REF] Völkel | Semantic Wikipedia[END_REF]. Most of current semantic wiki engines are developed in academic environment. Such conditions bring some advantages (they are almost all open source and freely distributed), as well as some drawbacks (lots of them is currently abandoned, not developed at all; sometimes, they even do not ever reach a usable milestone) 3 . Existing semantic wikis can stand as the functionality model. Actively developed semantic wikis are in alphabetical order: ACE wiki works with an interesting concept of syntax definition in natural language (definitions like "every country is an area"). It is easy and wellarranged wiki with wide capabilities in building the semantics. The statements are checked for potential semantic collisions like "Country has one capital" vs. "The capital of Germany is Berlin" and "The capital of Germany is Bonn". KiWi stands for Knowledge In Wiki. This system is intended for sharing and managing the knowledge. KnowWE this system has a technique for annotating content of wiki pages similar to techniques used in our developed Trac Semantic Extension. It also recommends pages with semantically related topics or topics with similar attributes. It features an easy-to-use semantic search functionality ("Select sports where Flexibility = spontanious"). OntoWiki very advanced and user friendly wiki-engine. Semantic MediaWiki is an extension of the popular MediaWiki. It adds possibility to add properties to pages and semantic searching. TaOPis easy wiki system for project and contributors' listing. Wikidsmart communicates with project management system Jira. Wiki authoring can create bug/feature/feature document in Jira (or other connected management system).

Projects presentation in a broader context

Typically, a particular environmental project is a part of a broader activity, being led by a public body (agency, office), an academic institution, or a commercial subject. So, relationships to other activities should be taken into account. In order to satisfy this aspect, an appropriate project management tool has to be found and deployed. Another important factor determining the selection of a right project management system are its semantic capabilities related to project management tasks [START_REF] Landaeta | Assessing faulty knowledge management systems in project-based organisations[END_REF]. The system selected to satisfy these needs, Trac, includes an integrated wiki for project presentation, allows synchronization with a Subversion repository, contains modules for bug tracking and issue reporting, a module for browsing the source code, and the like. It can be enhanced with the support of multiple projects and localization which is still vital, particularly in the highly international context. Our experimental installation implemented in the research lab of the authors is called Deep Thought (DT), cf. [START_REF] Gregar | Deep Thought : Web based System for Managing and Presentation of Research and Student Projects[END_REF]. A fundamental advantage of Trac/Deep Thought is a wide support for extensions. Trac is based on the Python component architecture -a basic module, and also each plug-in are components distributed as .egg packages. There exist two types of extensions -plugins and macros. Plugins can, thanks to their low-level interface to other Trac modules, extend whole system functionality. Macros are direct components of the Trac wiki-subsystem. They allow to dynamize wiki pages.

Semantic extension in the wiki

Key requirements

The key ideas how to combine the wiki ease of use with semantic information are:

1. Connect the wiki with a semantic repository containing info on categories like projects, people, or documents. 2. Provide instruments to easily annotate/link the wiki content with references to pieces of semantic information from the repository. 3. Offer enhancements to insert even complex semantic queries into wiki pages in order to dynamize the content. Our recent project, Semex (Semantic extension) experimentally implements the above ideas, see also [START_REF] Talaš | Semantically Enriched Tools for the Knowledge Society: Case of Project Management and Presentation[END_REF]. Semex allows annotations of wiki content according to ontological definitions in the knowledge database Sesame 2. It also enables visual highlighting of the tagged parts of text and viewing their context. This added functionality brings the possibility of browsing pages via semantic relations; e.g. person -his/her projects; or "show all people contributing to this project, who are older than 18 years". It can integrate the content with other services (e-mail), mine concept definitions from the repository or other web-service, or list other instances of the same concept [START_REF] Geurts | Towards Ontology-driven Discourse: From Semantic Graphs to Multimedia Presentations[END_REF]. It is composed of a Trac plugin assuring the administrative functions and communication with the knowledge repository and a set of wiki macros. Macros visualize semantic data instantly on the wiki pages and interact with the users; they are capable to wrap the authoring of semantic statements directly in the user interface, cf. Fig. 1.

Technology

As the Trac environment is Python-based, the extensions must also satisfy its non-functional requirements: at least to be written in Python. There exists li-brary RDFLib4 for work with RDF triples (i.e. inner representation of sources, statements, relations, ontologies) in Python. Python interface with Sesame 2 (via its REST protocol interface) could be offered by RDF Alchemy5 ; Sesame is just one of triple-stores the library can communicate with.

The important part of the Semex development was also the selection -to prevent reinventing the wheel -of prepared ontologies (see [START_REF] Gómez-Pérez | Ontology Languages for the Semantic Web[END_REF]) to work with. DT, as multi-project management system cope with information about persons (foaf, http://xmlns.com/foaf/0.1/, see [START_REF] Brickley | FOAF vocabulary specification[END_REF]), projects (doap, http://usefulinc. com/ns/doap#, see [START_REF] Dumbill | Description of a Project (DOAP)[END_REF]), documents (dc, http://purl.org/dc/elements/1.1/), wiki pages (wiki, http://sw.deri.org/2005/04/wikipedia/wikiont.owl#), in project management also with temporal events (event, http://purl.org/ NET/c4dm/event.owl#), or places (geo, http://www.w3.org/2003/01/geo/wgs84_ pos#). This ontological structure allows describing semantics of the wiki documents -define developers, deadlines, meetings, used literature etc. A very important feature of our approach is generality and universality. The ontologies used in the system can be extended, replaced, or combined with others which enables seamless employment of environmental ontologies like [START_REF] Morrison | The Environment Ontology -Linking Environmental Data[END_REF] as well together with the more general ones.

Functionality

The solution covers all basic use-cases required for a computer-aided project management and presentation using wiki. The administrative section allows creating, editing and deleting persons, projects, events, places and documents via a form-based web interface. The module also automatically creates wiki pages for the respective objects -names of these wiki pages start with prefix Semex:, therefore they are easy recognizable and can be quickly deleted in the administrative section. In the prototype, access to the sections is authenticated and authorized via Kerberos and the users can use their Faculty accounts credentials and do not have to bother with maintaining separate access data, namely passwords.

Wiki macros are the "visible" part of the module, cf. Fig. 2. A common visitor of Deep Thought sees only them. General Trac macros could be written in wiki page as short tag enclosed in doubled square brackets (with optional parameters in parentheses).

The following "bootstrap" macros have been developed for Semex so far:

Info it shows popup menu with options and information about selected object. It also allows user to see all statements of this object. Query returns a list of RDF sources according to entered SPARQL query. Suitable for automatic lists. Calendar prints out simple calendar with upcoming events. Allabout prints out all information about a source and similar ones.

SemexCommon this macro is the prerequisition for other semantic macros (includes semantic methods, defines GUI forms used in macros), and hence has to be included in every wiki page.

Fig. 2. Writing complex queries in wiki

The GUI of macros is created via the jQuery 1.3 library. It creates popup menus, and also user-centered simple wizards helping common user to incorporate macros which makes them accessible even for users with only a minimal notion of the formal semantic. However, the semantics in the wiki can be explored to its full power using queries in fully-fledged languages like SPARQL, as depicted on the last figure.

System integration

One of the usage patterns of the semantically enhanced project management system Deep Though is the university teaching. Choosing the right pattern of integration into the whole study process and administration is crucial, it was necessary to integrate the extension module and the whole system with the University's study administration information system (IS) in order to ensure smooth application in software development oriented courses. Students in these courses have to build a team, sign up for some project assignment and then work on it. This integration allows to get needed data from the IS, automatically create an environment for student projects defined in IS containing basic wiki pages, bug-tracker module, or source-code browser. Metadata about project is also imported into the semantic repository and utilized via the semantic module of Deep Thought.

The most visible features and contributions of this semantically-enhanced project management system in comparison with tradition PM systems is a common knowledge base consisting of concepts (entities) maintained centrally and reusable in all projects wherever it is relevant, see Fig. 3. A clear advantage of this approach is in its flexibility -once the DOAP ontology schema is replaced by a newer standard for project description, the transition will be significantly easier that in a classical database system where the relational or object/class schema must be modified -with all the undesired consequencies it might have.

Conclusion and Further work

Let us summarize the achievements reached so far. The key requirements showed to be realistic and implementable. The presented semantic extension to a project management tool Trac has proven as a working combination of -Advanced, popular project management system for hosting public-, community-, or internal projects including commercial ones; -Integrated semantic repository containing semantically precise and welltreatable data about environmental projects, people, places, events, and documents that represent a substantial part of all data typically processed; -Tools for advanced semantic querying and dynamic wiki content; -Visualization facility to user-centered query formulation and content browsing. So, all the main ideas have resulted in a succesfully implemented working prototype. Further development will include both general and domain-specific directions that should be tested on a larger-scale projects and data sets and also to compare/combine the approach with tagging tools developed within the TaToo Project [START_REF] Rizzoli | TaToo: tagging environmental resources on the web by semantic annotations[END_REF].

Fig. 1 .

 1 Fig. 1. Popups with semantic information from the wiki

Fig. 3 .

 3 Fig. 3. Entities common for all projects in Deep Though

http://www.wiki.org/wiki.cgi?WhatIsWiki

http://trac.edgewall.org/

http://semanticweb.org/wiki/Tools

http://www.rdflib.net/

http://www.openvest.com/trac/wiki/RDFAlchemy


Berit Arheimer
email: berit.arheimer@smhi.se

Patrik Wallman

Chantal Donnelly

Karin Nyström

Charlotta Pers

Chantal Donelly

E-HypeWeb: Service for Water and Climate Information -and Future Hydrological Collaboration across Europe?

Keywords: catchment hydrology, modeling, pan-European, technical infrastructure, open source community, E-HYPE

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Information about water quantity and/or quality is required by any societal sector dealing with natural resources, ecosystem services, or watercourses. Accordingly several European directives deal with water access and status, e.g. the Water Framework Directive, WFD (2000/60/EC) and the Marine Strategy Framework Directve, MSFD (2008/56/EC). Hydrological predictions by numerical models are often used to produce water information and related decisionsupport for societal safety or production eciency. The predictions may be used for e.g. early warning services, hydropower regulation, infrastructure planning, agricultural practices, water allocation, shipping guidance, environmental control, or climate change adaption.

Both scientically and operationally, the water community in Europe is diverse and disaggregated. Traditionally, hydrological model systems have often been site specic for water bodies and catchments, or small enough to be manageable by a single actor. Because of the economic interests in the water business, many commercial companies have developed their own tools for specic assessments and forecasts. Often institutes have specialized on a single model concept for decades [START_REF] Arheimer | A systematic review of sensistivities in the Swedish ood forecasting system[END_REF] giving answers to a few questions. SWAT [START_REF] Arnold | SWAT2000: Current Capabilities and Research Opportunities in Applied Watershed Modelling[END_REF] and HBV [START_REF] Bergström | Development and application of a conceptual runo model for Scandinavian catchments[END_REF] are examples of models that are frequently used for specic catchments in Europe, and sometimes also for operational transnational use in large river basins [START_REF] Berglöv | Improvment HBV model Rhine in FEWS[END_REF]. New challenges, however, have appeared for European water authorities related to new policies for environmental control, climate change adaption and uncertainty analyses. Today's requirements on hydrological models are going in the direction of higher spatial and temporal resolution for larger regions. Developing such tools requires a lot of resources, both when it comes to technical infrastructure, computational power and hydrological knowledge.

Setting up an integrated hydrological modeling and monitoring system is maybe not only a national concern today as information is requested also for pan-European issues and cooperation would reduce costs. This has been recognized since decades among meteorologists and oceanographers, who are sharing both code development and operational systems in the international collaborations of e.g. HIRLAM/ALADIN, MACC, HIROMB, NEMO and MYOCEAN.

The experiences show that it is not only benecial for scientic and technical development, knowledge and data exchange, but it is also economically sound to share the costs of both development and maintenance of these large systems between several partners. These cooperations could serve as blue-prints for the hydrological community, when increasing ambitions to cover the whole European domain and developing a core service for hydrological information.

The most ambitious European collaboration around a common hydrological model code is probably the SHE initiative that started some decades ago, between European institutes in Denmark, UK and France [START_REF] Refsgaard | Système Hydrologique Européen (SHE): review and perspectives after 30 years development in distributed physically-based hydrological modeling[END_REF]. For transnational analyses, some hydrological models have recently been applied for the pan-European domain, such as VIC [START_REF] Arnell | A simple water balance model for the simulation of streamow over a large geographic domain[END_REF], WaterGap [START_REF] Döll | A global hydrological model for deriving water availability indicators: model tuning and validation[END_REF][START_REF] Alcamo | Development and testing of the WaterGAP 2 global model of water use and availability[END_REF], WASMOD [START_REF] Widn-Nilsson | Global water-balance modelling with WASMOD-M: Parameter estimation and regionalization[END_REF] and LIS-FLOOD [START_REF] Feyen | Parameter optimisation and uncertainty assessment for large-scale streamow simulating with the LISFLOOD model[END_REF][START_REF] Van Der Knij | LISFLOOD: a GIS-based distributed model for river-basin scale water balance and ood simulation[END_REF]. However, none of the mentioned initiatives combines collaborative code development and operational production in common.

In this paper we present and suggest a platform that will enable intensied collaboration among water scientists as well as operational institutes, to provide water information with high resolution for Europe. This will presumably speed up the work with European directives in the European Union, as included model components, databases, simulation platforms, and model results are suggested to be open access for all member states. Such a collaborative core service could also enable a ora of commercial decision support systems appointed to specic needs of end-users.

Material and Methods

The HYPE Model

The Hydrological Predictions for the Environment (HYPE) model is a dynamic, semi-distributed and process-based model based on well-known hydrological and nutrient transport concepts [START_REF] Lindström | Development and test of the HYPE (Hydrological Predictions for the Environment) model -A water quality model for dierent spatial scales[END_REF]. It can be used for both small and large scale assessments of water resources and water quality.

In the model, landscape is divided into classes according to soil type, vegetation and altitude. The soil representation is stratied and can be divided in up to three layers, each with individual characteristics and hence calculations. The model simulates water ows, transport and turnover of nitrogen, phosphorus and inert trace substances. These substances follow the same pathways as water in the model: surface runo, macro pore ow, tile drainage and groundwater outow from the individual soil layers. Rivers and lakes are described separately with routines for turnover of nutrients in each environment. Model coecients are global, or related to specic characteristics of Hydrological Response Units (HRU), i.e. combinations of soil type and land-use. Internal model components are checked using corresponding observations from dierent sites [START_REF] Arheimer | Multivariable evaluation of an integrated model system covering Sweden (S-HYPE)[END_REF]. The HYPE model code is structured so that the model can be easily applied with high spatial resolution over large model domains, which is also facilitated by linking coecients to physical characteristics and by the multi-basin calibration procedure [START_REF] Donnelly | An evaluation of multi-basin hydrological modelling for predictions in ungauged basins[END_REF].

The European HYPE Model Set-up (E-HYPE)

So far, the HYPE model has been set up pan-European for water, while nutrients are only modeled for the Baltic Sea basin (Balt-HYPE), se Table 1. The E-HYPE model calculates water balance, hydrological processes (snow, glaciers, soil moisture, ow paths, groundwater contribution, and lake dampening) and nal routing to the surrounding sea, i.e. the Atlantic, Mediterranean, Black and Baltic Seas. The model domain covers most of the European continent, from the British Isles to the Ural Mountains, and from Norway to the Mediterranean Sea.

It serves as an operational high-resolution model and production system delivering daily data. This achievement was possible thanks to readily available regional and global databases, which are handled in a specially designed system of methods for automatic generation of model input data, WHIST [START_REF] Strömqvist | Using recently developed global data sets for hydrological predictions[END_REF]. The rst version was uncalibrated but a second version is currently (spring 2011) being set up and calibrated against observed time-series.

HYSS

The source code of HYPE is embedded in the HYdrological Simulation System ESDB [START_REF]Eurpoean Soils Database[END_REF] Runo data GRDC [START_REF]Global Runo Data Centre: River Discharge Data[END_REF], BHDC [START_REF]BALTEX Hydrological Data Centre: BALTEX Hydrological Database[END_REF] GRDC EWA [START_REF]Global Runo Data Centre: European Water Archive (EWA)[END_REF], BHDC [START_REF]BALTEX Hydrological Data Centre: BALTEX Hydrological Database[END_REF] # E-HypeWeb allows both zooming and panning in the maps shown in the web browser. To make the application reasonably fast the maps for dierent zoom levels are pre generated using cloud technology with access to several servers and parallel processing is achieved.

Results

The E-HYPE is a modeling tool that, on a daily timescale, and at a high spatial resolution:

calculates water discharge at all sub basin outlets on the European continent calculates water discharge to European Seas (and nutrient load to the Baltic sea) can be used operationally to give past and current conditions and forecast all variables can be used as a tool for examining the eects of climate change, land use change and/or nutrient reduction measures, and uses quality-assured data and will soon be calibrated and validated against independent observations, according to sound scientic principles [START_REF] Donnelly | High-resolutio, large-scale hydrological modelling tools for Europe[END_REF] Pan-European analyses show that the model captures major hydrological variability for the continent 3. Comparisons of preliminary model results towards observed values [START_REF] Donnelly | High-resolutio, large-scale hydrological modelling tools for Europe[END_REF] also show that the model is able to reconstruct dominant features of water quality and dynamics for the continent. Although, there is a need for more detailed input data and local adjustments to achieve more useful results for water authorities on the sub basin scale. on dominant hydrological processes, and advanced technology. For successful implementation and cost ecient development we ask for a bottom-up approach and inclusion of e-science. Some of the main building blocks in such an ambition are presented in the three steps below.

Better Input Data

Attempts to improve the input data are performed in several on-going EU FP7 projects (see acronyms that follow). Within GEOLAND2 we will experiment with new satellite-based products regarding detailed land use, soil sealing, phenology and soil moisture. In CRYOLAND we will try satellite products for snow and glaciers. GENESIS contributes with information about aquifers, and SUD-PLAN with methods for incorporation of local observations. EURO4M will contribute with more detailed forcing data and high-resolution precipitation products. In addition, the strategy is to initiate local collaboration and participatory modeling where input data can be improved for a specic domain of interest, and thereby contribute to the overall development.

Open Source Community

Hydrological Laboratory and New Technologies

The proposed modeling system will also be used as a hydrological laboratory.

At present the HYSS system manage the HYPE and the HBV models, but the ambition is that more models should be plugged in relatively easily. This facilitates ensemble runs using several dierent models for the same domain and with the same input data. In addition, the HYPE model code is relatively easy to follow, which allows experiments with dierent hydrological algorithms. This

Conclusions

A pan-European model is available, providing high-resolution water information with free access through a web product http://www.smhi.se/e-hype, and water and nutrient load to the sea through http://www.smhi.se/balt-hype

The rst preliminary model results show that the model is able to reconstruct dominant features of water quality and dynamics for the continent. However, collaborative development is needed both for producing more useful results

for water authorities on the sub basin scale, and for further operational pan-European implementation.

A three step strategy is developed for further development and implementation using a bottom-up approach. Focus is put on better input data, local knowledge on hydrological processes and advanced technology. Much of the work will rely on EU FP7 projects, an open source community, and hopefully new e-science. The ambition is to combine both collaborative code development and operational production in this new water service.

(

  HYSS, 2.3), which is the infrastructural part of the model source code. HYSS handles the simulation instructions, provides the hydrological model with variables containing data on the model set-up, time and current forcing data (i.e. precipitation and air temperature) and writes the result les. It also provides variables for model state, model parameters and output, which are used and set by the model. In this way, the hydrological algorithms are separated from the model infrastructure in its own module. HYSS can thus be coupled to several dierent hydrological modules with dierent model structures and process descriptions. HYSS leaves it to the hydrological process code to dene parameters and output variables, and calculate state variables during a time step. Currently, HYSS only handles ASCII-les which are used both for input data and output.

Fig. 1 .

 1 Fig. 1. Schematic picture of HYSS and its linkage to hydrological algorithms

4Fig. 2 .

 2 Fig. 2. First evaluation of time-series from the uncalibrated E-HYPE model vs. observations.

For ecient code development

  and inclusion of local knowledge on dominant hydrological processes for each part of such a large model domain, we will try the concept of an open source community. The code is then open and can be seen, changed and learnt from, and all code users are then treated as co-developers. It lies within the nature of an open source project to be highly modularized, and this allows for parallel development of independent components. Users/codevelopers should be encouraged to submit additions to the software, code xes, bug reports, and documentation etc. Early versions of the software should be released as soon as possible to increase chances of nding co-developers early. An open source community also needs a dynamic decision making structure that makes strategic decisions depending on changing user requirements and also manage/release new code versions. The open code and system related to E-HYPE could be hosted and managed at SMHI to serve the needs of local and continental issues and demands.The community should also cooperate with other national services and end-users linked to the operational production systems for full implementation.

  would enable scientic elaboration of hydrological hypothesis and increase the knowledge base of European water systems.New challenges in hydrological modeling include e.g. high spatial and temporal resolution, Monte Carlo simulations for uncertainty estimates, sensitivity studies, ensemble modeling, water quality estimates and climate change eects for the next coming hundreds of years. All these applications need high computational capacity. Hydrological models are traditionally run on PCs, but the new challenges thus ask for new technologies. Cloud services using several processors are already applied in the production system within SMHI hydrology to generate maps for the web products. Future modeling system may use this technology also to run the hydrological models themselves 3. This will soon speed up the computational time signicantly. Moreover, new technology is currently developed for visualization of E-HYPE results in decision support systems, for data extraction and automatic model calibration to local observation. This development is done in the EU FP7 preoject SUDPLAN and will result in interactive user interfaces, including model runs and data access. All together, the step strategy could thus lead to improved quality, credibility through transparency, collective learning and international cooperation. Each step would benet on linkage to new e-science to be ecient. If the overall development is successful, E-HYPE has a large potential to form a hydrological core service for Europe in the next coming years. This would then combine collaborative code development and operational production in the same service.

Fig. 3 .

 3 Fig. 3. Schematic picture of the future E-HypeWeb production system.

Table 1 .

 1 Model application set-up and input data.

		Balt-HYPE	E-HYPE1.0
	Areal extent	1.8 million km2	9.6 million km2
	Med. Sub basin area 325 km2	120 km2
	No. Sub-basins	5128	57436
	Topography/routing	Hydro1K [17]	Hydrosheds [16],(Hydro1K for latitude > 60 •
	Forcing Data	ERAMESAN 1980-2004 [18], ERAMESAN 1980-2004 [18], Resolution = 11 km. Resolution = 11 km.
	Landcover	Globcover 2000	Globcover 2000
	Soil-types	ESDB [19]

Acknowledgments This paper relates to work that has been partly nanced by the EU FP7 projects Geoland2, Sudplan, Genesis, Cryoland and OPERR.

National projects that have contributed are Hydroimpacts2.0 nanced by Formas, and Ecosupport nanced by BONUS. We are very grateful for the funding and the condence we have received. We would also like to thank Peter Karlsson, SMHI, and the water team for ecient and fruitful work on the E-HypeWeb and Balt-HypeWeb products.


Thomas Usländer
email: thomas.uslaender@iosb.fraunhofer.de

Rainer Junker
email: rainer.junker@rpf.bwl.de

Ulrike Pfarr
email: ulrike.pfarr@rpf.bwl.de

Towards User Requirements for an Information System of the Integrated Rhine Programme

Keywords: Integrated Rhine Programme, Environmental Information System, IS-IRP, Requirements Analysis

The Integrated Rhine Programme (IRP) is a strategic integrated measurement programme of the German federal state of Baden-Württemberg that aims at an improvement of flood control as well as the preservation and/or the restoration of the Upper Rhine plains. The implementation of the IRP shall be supported by an integrated and sustainable Information System for the IRP (IS-IRP) as an extension of the Environmental Information System of Baden-Württemberg. This paper describes how the analysis and design methodology SERVUS is applied to gather and document the functional and informational user requirements for the IS-IRP. SERVUS denotes a Design Methodology for Information Systems based upon Geospatial Service-oriented Architectures and the Modelling of Use Cases and Capabilities as Resources.

Introduction

The Integrated Rhine Programme (IRP) is a strategic integrated measurement programme of the German federal state of Baden-Württemberg that aims at an improvement of flood control as well as the preservation and/or the restoration of the Upper Rhine plains [START_REF]The Integrated Rhine Programme -Flood control and restoration of former floodplains along the Upper Rhine[END_REF]. Over a time period of more than 30 years it proposes and implements the creation of flood retention areas at 13 sites located in the alluvial floodplains on the Baden-Württemberg side of the Rhine. Moreover, it aims at achieving the preservation and restoration of the alluvial floodplains on the Upper Rhine to the largest possible extent. The ultimate goal entails attaining the level of flood protection that existed prior to the construction of the hydroelectric plants and locks.

Each individual measure requires an intense planning period over several years and includes the involvement of all stakeholders in the respective region including the citizens. A multitude of data has to be gathered from various sensors, databases and systems (e.g. surface and groundwater gauges, ecological data of fauna and flora, operational data of controlled weirs, input and output parameters of groundwater models, flood hazard and risk maps) such that an assessment and a justification of the measures is possible. Due to ongoing and lasting discussions with public and private stakeholders the argumentation line for a particular measure shall even stand up in courts after several years. Hence, there is a need for an integrated and sustainable Information System for the IRP (IS-IRP). It is designed as an extension and dedicated module of the encompassing Environmental Information System (EIS) of Baden-Württemberg [START_REF] Keitel | A: Framework Conception for the Environmental Information System of Baden-Württemberg (Germany)[END_REF]. One of the major design objectives is to avoid redundant data storage as far as possible.

In order to clearly understand the needs of the IS-IRP end-users as well as the capabilities of the existing EIS modules an intense requirements analysis phase is being carried out in 2011. Due to the multitude of involved persons and the interdisciplinary nature of this activity there is a need to follow a design methodology supported by an information management platform. For this purpose, the method SERVUS is being applied. SERVUS denotes a Design Methodology for Information Systems based upon Geospatial Service-oriented Architectures and the Modelling of Use Cases and Capabilities as Resources [START_REF] Usländer | Service-oriented Design of Environmental Information Systems[END_REF]. It is described in more detail in these proceedings [START_REF] Usländer | How to Analyse User Requirements for Service-Oriented Environmental Information Systems[END_REF]. This paper highlights the current status of the IRP implementation (section 2) and the approach of the requirements analysis (section 3). Furthermore, it presents a use case example (section 4) and concludes with an outlook about the consequences for the IS-IRP design from a broad architectural perspective (section 5).

Implementation of the Integrated Rhine Programme

By preserving the ecological goals the final objective of the IRP, once being fully implemented, is to restore protection in the Upper Rhine Valley against a 200-yearly flood event. The fulfillment of this objective requires a total retention volume of 256 Mio m 3 with a shared contribution of the adjoint regions (167,3 Mio m 3 for Baden-Württemberg, 30,3 Mio m 3 for Rhineland-Palatine and 58,4 Mio m 3 for France).

As of today, three out of 13 measures and retention areas (polders) that are foreseen in the Framework Concept for the Integrated Rhine Programme of Baden-Württemberg are operational. See their geographical locations and implementation status in figure 1. Two of them, the polder of Altenheim and the cultural weir near Kehl/Strasbourg have successfully operated for almost 20 years now. The polder of Söllingen/Greffern was brought to completion in 2005. This type of flood control operation helps retain 67 Mio m 3 of water [START_REF]The Integrated Rhine Programme -Flood control and restoration of former floodplains along the Upper Rhine[END_REF]. The retention are of the Rheinschanzinsel is currently under construction. Over the next years, further flood retention areas will be built.

Approach for the requirements analysis

In the first half of 2011, an analysis project in order to identify, collect and assess the functional and informational requirements for an IS-IRP is being carried out. Hence, as of today, just early results can be presented. As a first step, preliminary use cases have been proposed by the IRP experts of the regional governmental agencies (Regierungspräsidien) of Freiburg/Breisgau and Karlsruhe whose task is the thematic planning and implementation of the IRP including the consensus finding with the various stakeholders. These use cases are classified into four major domains according to the major data categories that are concerned:

1. Operational data of retention area facilities (dams, weirs,…). 2. Groundwater and surface water monitoring data 3. Ecological sampling data (including soil data) and ecological assessment data 4. Groundwater modeling After their identification these use cases are discussed and refined in workshops with the end-users and stakeholders. These workshops need to be facilitated and documented by a system analyst. As a starting point they are described in structured natural language according to a template in tabular format that just requires the name, the description, the major actors, the required information resources (input information objects) and the resulting information resources (output information objects) to be specified following the SERVUS methodology [START_REF] Usländer | How to Analyse User Requirements for Service-Oriented Environmental Information Systems[END_REF]. Optionally, a sequence of actions to carry out the use case may be added. It is then up to the system analyst to transform this semi-formal description into a formal representation, which, according to SERVUS, comprises a representation of the use cases and related information resources in the Uniform Modeling Language (UML). It is the advantage of this formal transition step already in an early analysis phase to detect inconsistencies and missing information as quickly as possible. The UML specification helps to (re-)discuss and check the use cases together with the thematic experts.

Use case example

As an example one use case of the ecological domain is presented in more detail. It is dedicated to fulfill statutory obligations stipulated in decisions of official planning approvals for the assessment of polder landscapes. This may be to validate that ecological floodings improve the mixture of fauna and flora species in the designated areas of the alluvial floodplains. Ecological floodings are controlled flooding events of a floodplain according to a defined procedure. Their purpose is to habituate the fauna and flora to flooding situations and, hence, to foster the formation of an alluvial forest.

Such a validation procedure requires the selection of indicator species, e.g. selected plants that characterize alluvial landscapes or epigeal fauna species such as ground beetles or snails. For these indicator species dedicated ecological monitoring programmes have to be defined. Especially, it has to be decided at which points in the alluvial floodplain the ecological observations should take place. As indicated in figure 2, a regular raster grid may be defined for plant monitoring, whereas individual points may be selected for fauna species.

The use case chosen is the performance of the monitoring programme as indicated above. The corresponding UML use case diagram is shown in figure 3. It is carried out by case officers in the IRP agency. It needs, among others, to read water gauges and further input data from groundwater information systems. It requires read and write access to nature protection data, e.g. to store the observation results of the flora and fauna monitoring as explained above. As a sub-ordinate use case the production of an ecological report is illustrated. As output information resource it produces an ecological report in pdf representation format.

Conclusion and outlook

This paper discusses how the process of analyzing the user requirements for the Information System, that shall support the implementation of the Integrated Rhine Programme in the Upper Rhine valley of Germany, is being carried out. It is a report about the practical application of a scientifically sound analysis and design methodology. The use case analysis is currently being performed in 2011 for all of the data categories listed above. In several workshops that include representatives of all stakeholders and thematic experts use cases as well as requested information resources are being identified. The workshops and the whole use case analysis process is supported and documented by a Web-based information management system. As an early result it may be said that the rigid but flexible and end-user oriented methodology heavily facilitates the discussion and consensus finding between the thematic experts and the IT specialists. Of particular help is the immediate documentation of the use case descriptions in a Web-based content and community management system. This system is available to all project participants with dedicated read and write access rights according to their roles.

The next step will be to derive an information model for the IS-IRP and discuss the consequences and the challenges for the design of the IS-IRP system architecture in the context of the other thematic applications of the Environmental Information System of the German federal state of Baden-Württemberg [START_REF] Keitel | A: Framework Conception for the Environmental Information System of Baden-Württemberg (Germany)[END_REF]. Particular emphasis will be put on the question how the generic services of the EIS Baden-Württemberg may be re-used for the IS-IRP, too. Service examples to be considered are a geographical information acquisition and rendering service (disy GISterm), the capability to manage links between thematic EIS objects or the various EIS capabilities to manage semi-and non-structured information, e.g. reports and images. A further design aspect is the integration with the Web portal of the environmental ministry and the agencies based upon WebGenesis® for the offering of the public IRP information. Due to the complexity of the project and especially the multitude and heterogeneity of the input data it is expected that the analysis and design of the IS-IRP will be run in multiple iterations.

The SERVUS methodology and the ICT design aspects for the IS-IRP may serve as a kind of template and blueprint for similar activities in other catchments and floodplains in Europe and beyond.

Fig. 1 .

 1 Fig. 1. Current status of measures and retention areas of the Integrated Rhine Programme

Fig. 2 :

 2 Fig. 2: Monitoring in the Alluvial Floodplains of Breisach, Germany [derived from a source figure of the RP Freiburg, 2011]

Fig. 3 :

 3 Fig. 3: Example use case "Perform Monitoring Programme" to be supported by the IS-IRP


Petr Kubicek

Eva Mulickova

Milan Konecny
email: konecny@geogr.muni.cz

Jitka Kucerova
email: 2jitka.kucerova@chmi.cz

Flood management and geoinformation support within the emergency cycle (EU example)

Keywords: Floods, geoinformation, adaptive mapping, context

Paper describes the state-of-the-art of flood management both in the Czech Republic and in the broader framework of EU. Special focus is given to geoinformation and cartographic issues within consecutive parts of emergency management cycle used in European Union countries (prevention, preparation, response, and recovery phases). For each phase an adaptive mapping solution is outlined. The principles of adaptive cartography and its applications are described.

Introduction

The goal of crisis management activities is to reduce the degree to which a community condition is worsened by a disaster relative to its pre-disaster condition [2]. The field of crisis management usually divides any situation into four components (phases) that roughly correspond to the before -called preparedness, during -called response, and after phase (recovery) of any particular event. The last but not least mitigation (and prevention) phase is concerned with minimizing the effects of possible disasters by mandating policies and regulations that will lessen the effects of hypothetical disaster. Each of these phases put particular demands on emergency managers and responders, and each can be informed and improved by the application of geospatial data and tools. These phases follow one another in a continuous cycle, with a disaster event occurring between preparedness and response phase (Fig. 1). Geospatial demands vary across the phases of disaster as well as across hazard types. Geospatial resources and processes thus must be able to adapt and respond to follow the changing demands.

In the case of crises management geospatial services can provide a unified environment allowing visualizing, analyzing, and/or editing data from various data sources within a single client. The main theoretical approach proposed for the crises management cartographic support is so called adaptive cartography. This method is based on the idea of geodata visualization automation and adjustment according to situation, purpose and user's background [START_REF] Friedmannová | Adaptive maps for crises management[END_REF][START_REF] Kubíček | Process Support and Adaptive Geovisualisation in Emergency Management[END_REF][START_REF] Erharuyi | Task-Centred Adaptation of Geographic Information to Support Disaster Management[END_REF]. Adaptive maps are still supposed to be maps, i.e. correct, well legible, visual medium for spatial information transmission. While all map modification processes are incorporated in electronic map logic, users can affect adaptive map just indirectly by a context.

Geospatial demands vary across the phases of disaster as well as across hazard types. Geospatial resources and processes thus must be able to adapt and respond to follow the changing demands. In order to document the adaptation process we are presenting the example of flood management and proposing the cartographic contexts and possible data sources for particular phases of disaster management cycle. Remainder of the text is structured as follows: Chapter 2 brings overview of flood management in the Czech Republic -it describes its legal framework and points out some activities and responsibilities. Chapter 3 analyses the current flood (geo)information resources according to the phase of the flood situation it relates to. Chapter 4 describes the adaptive mapping approach applied to the flood and defines selected contexts.

Flood management in the Czech Republic

The causes and consequences of flood events vary across the countries and regions of Europe. Flood risk management should therefore take into account the particular characteristics of the areas and ensure relevant coordination within river basin districts and promote the achievement of environmental objectives. This fact led to the establishment of Directive 2007/60/EC of the European parliament and of the council of 23 October 2007 on the Assessment and Management of Flood Risks [START_REF][END_REF]. Based on this directive member states shall make available to the public flood relevant documents and information -namely the preliminary flood risk assessment, the flood hazard maps, the flood risk maps and the flood risk management plans. For each type of documents the following is then recommended:

• The preliminary flood risk assessment -states, for which part of river basin district, the flood risk assessment will be accomplished. Only selected river basin areas will be further processed. • The flood hazard maps, the flood risk maps -show the potential adverse consequences associated with different flood scenarios, including information on potential sources of environmental pollution as a consequence of floods. • The flood risk management plans -It should focus on prevention, protection and preparedness. The elements of flood risk management plans should be periodically reviewed and if necessary updated, taking into account the likely impacts of climate change on the occurrence of floods.

Legal framework

In the Czech Republic flood protection is in focus of many legislative documents. Protection itself is secured according to Flood Management Plans and, in the case that crisis situation is declared, according to Crises and Emergency Plans. Protection against the natural floods is controlled by Flood Authorities that are (on territorial basis) responsible for organization of flood prevention and response; further they administer and coordinate the activities of other responsible actors within flood prevention and response. Character and activity of Flood Authorities are specified for two periods -beyond flood and during flood; their specification in hierarchical order is shown in Table 1. Watercourse managers and managers of touched object (or other subjects ordered by Flood Authorities) are responsible for Flood Security Activities (e.g. measures against water pollution, removing blockades of ice) that must be coordinated with the River Basin Authorities. Fire Rescue Service (FRS) as one of the component of Integrated Rescue System (IRS) has many tasks within Flood Rescue Activities (e.g. evacuation, rescue of citizens), Flood Security Activities (e.g. flood survey, indication of dangerous areas) and Organizational Activities (e.g. coordination of rescue works). Flood Authorities are responsible for planning (e.g. compilation of Flood Plan), organizing (e.g. local early warning), and securing (e.g. health care and emergency supply).

Flood related spatial data and services to support activities within the Disaster management cycle

In the following chapters we will review existing geospatial support for prevention activities (Risk Assessment), preparation activities (Pre-impact activities) and response activities (Emergency management).

Geoinformation for prevention -flood zone mapping, insurance maps, flood risk mapping

The main role of geospatial support within this particular part of cycle is to identify the potential areas of risk and minimise future losses of both lives and assets.

According The Water Act (No. 254/2001) Flood zone is an area that can be flooded during the natural flood event. Its extent is proposed by the particular watercourse manager for discharges occurring once per 5/20/100 years. Its delimitation is given by Legal notice No. 236/2002 and is based e.g. on hydrological data, on regulations of water structures influencing flood discharges, on longitudinal and cross sections of the river etc. Project of flood zone is elaborated on the ground map of the Czech Republic 1:10 000. Besides the flood zone also Active zone of flood area is determined. It is an urban area that influences drainage during floods.

Almost all property insurances in the Czech Republic use Flood Risk Assessment Tool (FRAT) developed by Swiss Re to identify high exposed risks. Users can be located by the address (street, house number, and city) or interactively on the map. The system generates information on the flood risk exposure of the selected location and displays it on-screen. The tool distinguishes four different flood risk zones: Zone 1: very low flood risk, Zone 2: low flood risk, Zone 3: medium flood risk, Zone 4: high flood risk. The insurance flood zones database is available not only for the main watercourses but also for local streams with drainage basin larger than 20 sq km.

The Czech Republic adopted the Flood Directive 2007 and proposed the national methodology for flood mapping. The methodology is based on matrix of risk [START_REF] Beffa | A Statistical Approach for Spatial Analysis of Flood Prone Areas[END_REF] and is closely connected to the standard database established, operated and administrated within the Czech water management. It comprises following main procedures: identification of the flood hazard, determination of vulnerability and semi-quantitative implication of flood risk by four-degree scale. The final methodology result is flood risk map combining information about danger and vulnerability of objects and activities in the floodplain. Landscape vulnerability is represented by objects and activities occurring in landscape. Resulting flood risk zones show areas where maximal acceptable risk is exceeded. The reached values of the flood danger in the corresponding colour scale are indicated inside each such highlighted area. For detail description of the corresponding methodology see [START_REF] Drbal | The Methodology for the Flood risks and Flood hazards map making[END_REF].

3.2

Geoinformation for preparation -Integrated Warning Service System, Flood Modelling Preparation or pre-disaster phase is characterised by a combination of warning services and spatially depending flood forecasts initiating the whole set of activities. Integrated Warning Service System (IWSS), a component of Integrated Rescue System of the Czech Republic, meteorology and hydrology warning service for the Czech Republic. IWSS is provided jointly by Central Forecasting Office (CPP) of the Czech Hydrometeorological Institute (CHMI) [2] (within Ministry of the Environment) and the Department of Hydrometeorological Services of the Military Geographical and Hydrometeorological Office (within Ministry of Defence). IWSS provides evaluation of up-to-date meteorological and hydrological data, information and forecasts and delivering integrated warning information. The part of Central Forecasting Office (CPP) is Warning and Information Office; its main activity is to alert in the case of dangerous meteorological phenomena (e.g. heavy rain, snow cover, snowdrift, strong wind, frost in vegetation time) and other weather phenomena (smog, dangerous air substance transmission etc.).

Czech Hydrometeorological Institute (CHMI) employs two hydrological models for discharge prediction -HYDROG and AQUALOG.

HYDROG is rainfall-runoff model for flood simulations and discharge prediction. Inputs are discharges, controlled water reservoirs run-offs and precipitation; in winter also data about temperature and snow cover.

AQUALOG is programming tool for simulation, prediction and run-off management and water quality in real time and in the past. It allows numeric simulations of creation and melting of snow cover, rainfall-runoff transformation, simulation and management on reservoirs, and modelling of diffuse processes on surface waters.

Geoinformation for response -Flood Management Plan

When flood becomes a reality than it is necessary to follow certain strategy in order to minimise the potential flooding impact. Flood Management Plans are sources of information for this part of disaster cycle. The Flood Management Plan is divided to factual, organisational, and graphic parts.

Factual part includes information necessary for securing specific object, municipality, complex basin or other territory, directive limits for declaration of degrees of flood activity, informs about the possibilities to influence discharge, etc. Organisational part includes list of names and addresses, describes communication links between involved persons, specify tasks for people and organization concerned with flood protection, assists with securing local early warning system etc. Graphic part includes following maps: Flood Committees & Evacuation Places, Gauging stations & Precipitation Station, Flood areas, Watercourse and water structures, Transportation.

There are four types of Flood Management Plans (FMP) corresponding with hierarchical order of flood authorities -FMP of the Czech Republic, FMP of the Region, FMP of the Municipalities with Extended Powers, FMP of the Municipality and the fifth one (Other Flood Management Plan) that is done for the buildings and parcels that either lay in the floodplain or can influence the progress of the flood.

Adaptive mapping in crisis management

Chapter 3 documented exiting sources of geoinformation and services related to floods. Flood management plans offers set of analytical maps; they are sources of essential information but in time limited situations in preparation and response phase may be not effective. They are thematically oriented (e.g. transportation, gauging stations) but not task oriented. Existing maps have predominantly information function, i.e. it inform about "what is where". But modern cartography can offer more; it can shift map to decision-making tool. So called adaptive mapping [START_REF] Friedmannová | Adaptive maps for crises management[END_REF] brings to crisis management opportunity to be more effective by adaptation of cartography outputs to needs of users. User is supplied only by the information that is necessary for decision making and is given in the most comprehensive form for the user. Context in which the geographic data are presented plays the key role; thus the term context cartography is also used. Cartography visualization (e.g. map) is adapted to user's context. Context is the set of characteristics dealing with the user, environment and the purpose [START_REF] Friedmannová | Adaptive maps for crises management[END_REF][START_REF] Erharuyi | Task-Centred Adaptation of Geographic Information to Support Disaster Management[END_REF][START_REF] Reichenbacher | Adaptive Methods for Mobile Cartography[END_REF][START_REF] Dey | Towards a better understanding of context and contextawareness[END_REF].

The aim of adaptive mapping is to facilitate different users to work over the same data. Even though the context maps portray the same objects and phenomena, the knowledge the users get from it depends on the task they are responsible for. The visualization reflects the role the object plays in decision making process, e.g. object school play different roles in task of flood prediction and in task of navigation. In the former case, the maps supply the knowledge about the "object of social character with people that need special protection". In the later, the school plays the role of "object that eases orientation". Cartography model for each context map must reflect this fact; different roles of the same object in reality are expressed by different map symbols and in different implications.

Conceptual framework -study "FLOOD"

Our approach followed the idea of [START_REF] Dey | Towards a better understanding of context and contextawareness[END_REF] and modified it with the respect to cartography visualization in crisis management.

Context is the set of factors that influence legibility and usability of the map [START_REF] Friedmannová | Adaptive maps for crises management[END_REF]. There is an indefinite number of such factors and thus it is necessary to chose those with the highest influence.

We distinguish three main context types: 1. Identity context. This type of context refers to questions like "Who will use the map? Who is responsible for what?". This context influences the visualization since users having diverse professional background are using different visualization methods and map symbols. Further, this information is used for authorization rights purposes, i.e. which data (data layers, properties) can be managed and administered by the user. For example POLICE can edit information about roads, watercourse managers about objects on the river, etc. 2. Functional context. It deals with questions "How the map will be used? What Question WHAT? implies the ACTIVITY, e.g. What activity should be supported with the map? Activity embodies the range of tasks that the user is responsible for. It is the most crucial factor that determinates the specific view of the reality; by familiarity with the knowledge that user must get to be able to perform decision making it is possible to guess about relevance of spatial object and thus to define map content. Following five main activities were defined for the event FLOOD: -PREDICTION AND PROGRESS -development and expected progress of the flood -TECHNICAL SUPPORT -technical support in inundation area -support of Flood Security Activities -RESCUE -evacuation of the citizens -ORGANIZATION -organization of power and means -PUBLIC INFORMATION -information for public about flood development, evacuation etc. Question WHEN? specifies the STAGE, e.g. In what phase of the emergency event the activity is realised? The crisis management is not limited to the response phase of the event but pass the entire disaster management circle. We can specify four phases of crisis management circle [START_REF] Lumbroso | Review report of operational flood management methods and models[END_REF] that correspond to the four STAGES:

prevention (out of the flood) preparation (shortly before the flood) response (during the flood) recovery (after the flood) Figure 1 illustrates which emergency core contexts are defined based on the activity and the stage. For example, to realize the activity rescue in preparation phase user chose the context evacuation preparation for which data content is defined. g. what should be on the map. The other parameter is OPERATIONAL RANGE that relates to WHERE? and deals with questions like Where the event takes place? What is the event extent? What is the activity extent? This parameter does not influence the map content "thematically" but tackle the problem how many information can be portrayed on the map so that it is still legible. It influences character of generalization; it must be not only quantitative but also semantically based. Five basic operational ranges were defined: one for detailed information -e.g. part of floodplain: LOCAL three due to hierarchical system of flood management: REGION, DISTRICT, MUNICIPALITY one due to the necessity to flood monitoring in natural borderlines: CATCHMENT Map scale of the corresponding operational range spans from large (i.e. 1:5 000 -1:2 000) for LOCAL to small (i.e. 1:500 000 -1: 1 mil.) for REGION and CATCHMENT to capture appropriate (administrative or natural) unit. Operational range is assigned to each emergency core context and defines in which level of detail information will be (most probably) used. Users are not limited to work in the dedicated operational range but out of it they may get less information.

Context composition

Appearance and functionality of final context map will be set by the combination of all particular contexts: identity, functional and core emergency. The user can define, for example, the context map by the following profile: Identity context: Fire Rescue Service Functional context: control Emergency core context: evacuation + preparation Content of the invoked map will be to ensure the evacuation (emergency accommodation, access roads etc.), symbology and access rights for fire rescue service will be called out and GUI will allow editing of attributes (e.g. user can change the status of evacuated building to evacuation terminated). Process of context map composition is illustrated on figure 2.

Conclusion

Paper described state of the art within flood case of emergency management cycle and has shown a wide variety of both users' requirements and available geoinformation sources. In accordance with [START_REF] Diehl | Investigation of user requirements in the emergency response sector: the Dutch case[END_REF] and [START_REF] Kubíček | Process Support and Adaptive Geovisualisation in Emergency Management[END_REF] we can conclude that intuitive interfaces and dynamic visualization are highly demanded. Thus the adaptive cartographic visualization with simple associative icons and symbols can significantly improve the communication. [START_REF] Staněk | Selected issues of cartographic communication optimization for emergency centers[END_REF] documented that an adaptive cartographic (context based) approach applied for integrated rescue system operators led to lighter maps which were more efficient than existing overloaded multipurpose maps. In the next phase we plan to fully implement the adaptive approach for a selected flood management area and consequently test the cognitive issues for selected tasks within the emergency cycle.

Fig. 1 .

 1 Fig. 1. Emergency core context definition within disaster management circle Activity and stage are parameters that primarily define map content, e.g. what should be on the map. The other parameter is OPERATIONAL RANGE that relates to WHERE? and deals with questions like Where the event takes place? What is the event extent? What is the activity extent? This parameter does not influence the map content "thematically" but tackle the problem how many information can be portrayed on the map so that it is still legible. It influences character of generalization; it must be not only quantitative but also semantically based. Five basic operational ranges were defined:one for detailed information -e.g. part of floodplain: LOCAL three due to hierarchical system of flood management: REGION, DISTRICT, MUNICIPALITY one due to the necessity to flood monitoring in natural borderlines: CATCHMENT Map scale of the corresponding operational range spans from large (i.e. 1:5 000 -1:2 000) for LOCAL to small (i.e. 1:500 000 -1: 1 mil.) for REGION and CATCHMENT to capture appropriate (administrative or natural) unit. Operational range is assigned to each emergency core context and defines in which level of detail information will be (most probably) used. Users are not limited to work in the dedicated operational range but out of it they may get less information.

Fig. 2 .

 2 Fig. 2. Context map composition

Table 1 .

 1 Flood Authorities beyond and during flood on different hierarchical levels

		Beyond flood	During flood
	Municipality level	Municipality authorities	Flood Staff of the
			Municipality
	District level	Authorities of the	Flood Staff of the
		Municipalities with Extended	Municipalities with Extended
		Powers	Powers
	Regional level	Regional authorities	Flood Staff of the Region
	State level	Ministry of the Environment,	Central Flood Staff
		Ministry of the Interior
	2.2

Activities in the flood management Flood

management is very complex set of tasks. Flood Authorities are responsible of coordination of activities of different user groups. It includes e.g. units of the Integrated Rescue System (Fire Rescue Service of the Czech Rep., Police of the Czech Rep., Ambulance Service etc.), River Basin Districts Authorities, Watercourse managers, etc. These users are responsible for different tasks in flood management; some of them can (or must) be supported by geoinformation.

  is the function of the map in the decision making process? We can distinguish three groups of users: users that only needs to know "what is where" -function INFO), user that needs to update status of spatial objects (e.g. bridge is destroyed, road is closed) -function CONTROL, and users who need to create new object (e.g. place where intervention is necessary, place of ice blockage) -function ORGANIZE. 3. Emergency core context. It is the most complex one. It refers to the issue of data content. Within it two particular questions are dealt: What? and When?


Gerhard Triebnig
email: gerhard.triebnig@eox.at

Andrei Diamandi
email: diamandi@meteoromania.ro

Richard Hall
email: richard@ksat.no

Eirik Malnes

Lars Marklund
email: lars.marklund@smhi.se

Sari Metsämäki
email: sari.metsamaki@ymparisto.fi

Thomas Nagler
email: thomas.nagler@enveo.at

Jouni Pulliainen
email: jouni.pulliainen@fmi.fi

Helmut Rott
email: helmut.rott@enveo.at

Christian Schiller
email: christian.schiller@eox.at

Rune Solberg
email: rune.solberg@nr.no

Andreas Wiesmann
email: wiesmann@gamma-rs.ch

CryoLand -GMES Service Snow and Land Ice -Interoperability, Service Integration and User Access

Keywords: snow, glacier, ice, spatial data infrastructure, service architecture

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The CryoLand project [START_REF]CryoLand Project Web Page[END_REF] is expected to establish new snow and land ice service capacities targeting its specified user communities. It will provide geospatial products on snow extent and snow pack physical properties, maps of glacier area and other glacier parameters, and on fresh water ice from EO data. Significant uptake of these products and suitable business models for long-term operational supply will have to be supported.

This paper describes preliminary results of the service requirements and system architecture definition activities aiming at setting-up the spatial data infrastructure of CryoLand including the interfaces for interoperability with neighbouring systems and to end-users.

Infrastructure Requirements

High-level Requirements

The CryoLand Infrastructure will be designed to support advancements of product generation chains (e.g. for automatic integration of space and in-situ data into hydrological process models) including tools for Sentinel-based snow and ice products as well as chains for product delivery in near-real-time after (satellite) observation. It will be the platform for testing and validation of snow and ice products tailored to user needs and the associated product generation and access services. It will also serve for demonstration, training and service up-take activities by identified external customers.

A GMES-embedded, pre-operational, Internet-based service infrastructure shall be designed such as to be transferrable at the end of the project into sustainably operational multi-provider environments.

Neighbouring Systems

Fig. 1 shows how the CryoLand system will conceptually be surrounded by other infrastructures. A significant number of external interfaces will have to be dealt with in order to integrate CryoLand's snow and ice services into the wider geospatial infrastructure. A heterogeneous set of input data sources will have to be connected. Furthermore, the CryoLand services must be prepared for being consumed by a (yet unknown) number of client-side systems supporting virtual and real users. There is also the requirement to establish native access via the CryoLand's own Web site.

3 CryoLand Architecture

Architecture Definition Approach

The CryoLand architecture elements for (1) user access, (2) service integration, and (3) data storage management are being defined, designed, implemented and documented in alignment with the definition and design of the thematic snow and ice processing and product generation services. The architecture definition methodology applied is based on RM-ODP (ISO 10746) which essentially requests to look at the architecture from the interrelated "five viewpoints" as further explained in sections 3.3 through 3.7.

Architecture Baseline and Good Practice

CryoLand attempts to build on the state-of-the-art for geospatial data systems with particular considerations on good practice in EO satellite payload data ground segment infrastructures. The following is a summary of the areas impacting the design of the CryoLand infrastructure: INSPIRE geodata infrastructure standards framework and implementing rules OGC geospatial standards/tools framework and best practices OASIS security standards FP7 GENESIS environmental service concepts and software re-use Heterogeneous Missions Accessibility (HMA) framework and GMES Coordinated Data access Service FP7 geoland2 concepts, interoperability requirements and service interfaces Other GMES Core and Downstream Infrastructures (PASODOBLE, ENDORSE, etc.) ESA algorithm development, processing, service support environments and user service interfaces (KEO, G-POD, SSE, ngEO) GEOSS Common Infrastructure integration Legacy snow mapping infrastructures provided by CryoLand project partners (who themselves are involved in a range of national and international thematically related projects) are, naturally, the starting points of the good practice analysis. The CryoLand project is performing a thorough assessment of this legacy and heritage in order to define re-use and evolution strategies from existing and available infrastructure solutions.

Enterprise Viewpoint

This RM-ODP (see section 3.1) viewpoint asks for the definition of CryoLand's purpose, scope, policies, and related business which altogether are impacting infrastructure implementation decisions. In addition to the high-level requirements stated in section 2.1 the infrastructure shall support:

Higher automation degree of processing lines, workflows and logistics Coordinated data storage management Standard interfaces of network services and for user access (INSPIRE and GEOSS compliant) Services operations in multi-provider environment Validation of Sentinel-1 utility and service lines Production facilities for European Climate Change Initiative (probably)

The implementing organizations (i.e. the FP7 consortium partnerssee affiliation list of paper authors) and some 40 formally committed user organizations are in the process of formulating their different operational mandates, commitments and business expectations related to the future sustained operations of the CryoLand provided services.

Information Viewpoint

This viewpoint is concerned with the semantics of information or products as well as of the information processing to be implemented by CryoLand. The CryoLand Information Model -aligned with OGC geospatial information modelwill define in all details the complete sets of (1) Applications and Output Productssee Table 1, (2) Input Data/Products, and (3) System Management Data/Information. Building on results from [START_REF] Malnes | Multi-sensor monitoring of snow parameters in Nordic mountainous areas[END_REF], [START_REF] Nagler | Retrieval of wet snow by means of multitemporal SAR data[END_REF], [START_REF] Nagler | Snow classification algorithm for Envisat ASAR[END_REF] and [START_REF] Solberg | Multi-sensor and time-series approaches for monitoring of snow parameters[END_REF] it will also describe the algorithms of choice which will generate information and knowledge from data. This will be the data processing recipes for e.g. improving the quality of the snow cover products, in particular in forested regions and in areas of complex land use; for capitalizing on the enhanced sensor characteristics and coverage of the GMES Sentinel satellite series; for the integration of systematic in-situ measurements and remote sensing data; and the like. The extensive list of Input Data/Products corresponding to the input data interfaces indicated in Fig. 1 will include optical EO data (including when available: Seninel-2 & -3), radar feeds (Sentinel-1), in-situ/reference data (e.g. topography models), and GMES Core Service products (e.g. Pan-European Degree of Soil Sealing).

In Table 2 a preliminary list of System Management Data types is shown which will be essential for the functioning of the CryoLand services. Very relevant in the definition of these data will be the OGC Geospatial Information Model [START_REF]CryoLand Project Web Page[END_REF] since it standardizes geographic features (and mark-up language), spatial referencing, geometry and topology, and provides OGC Schema Repositories and many more important elements. Service Registration Data, Process Metadata

Computational (Service) Viewpoint

This viewpoint is concerned with the functional decomposition of the overall CryoLand system into a set of services that interact at interfaces. The design activites will fully draw upon the OGC Service Model [7] which establishes the principles for the service oriented architecture and points to the extensive set of specifications related to the OGC Web Services. A number of those will be essential to implement interoperable CryoLand service interfaces. For the implementation of raster data flows (up-und downloads) between CryoLand system components the Web Coverage Service and its transactional extension (WCS-T) is considered a capable mechanism. In particular the recent developments of the EO Application Profile of WCS 2.0 [START_REF]WCS Earth Observation Application Profile[END_REF] demonstrate the usefulness of this protocol in the distributed facility organization of CryoLand (see section 3.7).

Technology Viewpoint

This viewpoint will address the specific software to be used for the implementation of the CryoLand service components and make decisions on the hardware platforms which are needed for deployment and hosting of the software instances. The project has an orientation towards Free and Open Source Software (FOSS) but not made any decisions so far on the specific software platforms for the system at the various stages of evolution.

Engineering Viewpoint

This viewpoint defines a set of components that provide the basis for deployment of the CryoLand system in a distributed environment as shown in Fig. 2. These engineering components are accessed by services (see section 3.5). The CryoLand Engineering Model -aligned with OGC model of reusable patterns for deploymentforesees a multi-tier architectures with a number of distributed nodes representing CryoLand service partners each acting as processing and service provider. The Spatial Data Infrastructures will link these nodes with the input data providers. These include space EO data acquisition and archiving centres providing Level-1 data (calibrated, swath-based satellite data), e.g. ESA processing and archiving centres (PAFs), the KSAT PAF, etc. Another important link is with the GMES Land Monitoring Core Service (LMCS) centre, as LMCS products will be integrated with satellite data for producing enhanced satellite snow products of CryoLand. Links to in-situ data providers (archives) will be set up according to user needs. Additionally, the CryoLand service concept foresees to maintain a Level-2 product archive (swath-based geophysical product, e.g. snow area extent) if required. This facilitates the production of customized (Level-3) satellite-based products that are derived from the same basic input data. Each node will be protected under a jointly organized security scheme. The interface for the users to the individual CryoLand nodes will be through a portal, providing virtual centralized access to the decentralized, chained services and the generated products.

Fig. 2. CryoLand multi-provider & distributed network

Status of Development

The starting points of the CryoLand project are offerings of legacy snow and ice services available at project partner organizations. Based on user requirements assessed within the early project phase the services and products will be harmonized and tailored to match the customer needs. The infrastructure is already and will remain -by principle -distributed to designated service operators with a unique reference Web location [START_REF]CryoLand Project Web Page[END_REF] providing a logical entry point to these services. Currently a number of WMS-based viewing services to snow products are shown for demonstration purposes. Furthermore, a collection of example products is put online to indicate the future CryoLand product portfolio by showing early results.

Conclusion and Outlook

A GMES-embedded, pre-operational, Internet-based service infrastructure supporting the generation and provision of seasonal snow, glaciers, and lake / river ice information products is designed and will be implemented by the CryoLand project such as to be transferrable into sustainably operational multi-provider environments at project end. The overall project time span is February 2011 to January 2015 with service pre-operations and consolidation during 2013 -2014. Services and products making use of data from the first GMES satellite Sentinel-1 (currently planned for launch in the first quarter of 2013) are expected during 2014.

Fig. 1 .

 1 Fig. 1. CryoLand and its neighbouring systems

Table 1 .

 1 CryoLand applications and output product groups (preliminary)

	Topic	Main Parameters
	Seasonal Snow	Snow extent, snow mass, melt state of snow (wet / dry)
	Glaciers	Glacier outline (area), snow / ice extent, ice velocity,
		glacier dammed lakes
	Lake / River Ice	Ice extent, temporal changes of ice extent, snow burden

Table 2 .

 2 CryoLand system management data/information (non-comprehensive)

	Use	Data / Information
	Security & User Management	Authentication and Authorization Data,
		Access Policies
	Discovery Service & Annotations	Metadata
	Service
	Portrayal Service	Geo Data Visualizations
	Archive & Resource Management	EO Datatsets,
	Service	EO Dataset Metadata,
		In-situ Datatsets
	Workflow Services

Table 3 .

 3 Abstract service types to be implemented by CryoLand based on OWS specifications

	OGC Web Service (OWS)	Abstract service / Use
	CSW	Catalogue
	WFS (-T)	Download Feature
	WMS & EO AP	View/Portrayal
	WCS (-T) & EO AP	Download Coverage
	SOS	Sensor Observation
	SPS	Sensor Planning
	WPS	Processing Invocation
	-T = Transactional (Upload)	AP = Application Profile

Input to CryoLand CryoLand Network

		CryoLand
	Web	Portal &
	Browser	User Services
			Snow & Ice Processing
	Enterprise		(Level 2) & Archiving
	System
		CryoLand
		Product
		& Service
	CryoLand	Provider
	Product & Service		Space EO Data (Level 1)
	Provider
			In-situ Data
	CryoLand
	Product
	& Service
	Provider	CryoLand
		Product
		& Service
		Provider	Land Monitoring Core Service

Acknowledgements

The work described in this paper is partly supported by funding from the European Community's Seventh Framework Programme ([FP7/2007-2013]) under Grant Agreement n° 262925.