ERiskA, data model, information analysis, risk management, harmonisation requirements

Transcription

1 A7.6-D2 Information model and harmonisation issues of HS-ERiskA Title: A7.6-D2 Information model and harmonisation issues of HS-ERiskA Author(s)/Organisation(s): Astrid Fichtinger (TUM), Marian de Vries (TUD) Working Group: WP7, WP9 References: 754-system_specification_hs_eriska-tum-001-final Short Description: This document contains the information analysis for the HUMBOLDT Scenario ERiskA. It gives detailed information on the datasets needed and available for the ERiskA use cases as well as on the harmonisation issues arising from those. It also contains a first draft version of the common ERiskA data model. Keywords: ERiskA, data model, information analysis, risk management, harmonisation requirements History: Version Author(s) Status Comment 000 Marian de Vries new 001 Astrid Fichtinger rfc filled template with information about ERiskA 1

2 Table of contents 1 Purpose and scope Information analysis Use cases of the Scenario Scenario main functionality (Spatial) information needed for the use cases Data model Datasets needed (use cases HS06-01 and HS06-03) Road Railway Watercourse and Standing Water Gauge Flood Area Water Level Measurement Discharge Measurement Warning Level Warning Level Classification Elevation Aerial Image Topographic Map Harmonisation requirements Data format Spatial and temporal reference systems Spatial reference system Conceptual data model Geometry types Identification and Versioning Importance of time (temporal attributes) Classification Terminology Metadata Scale/resolution, level-of-detail, aggregation Portrayal Processing functions Multilinguality Spatial, temporal and thematic consistency of data

3 Spatial consistency Priorities To discuss Scope of data model Access to needed datasets Related projects and initiatives Glossary References Annex: ERiskA datasets

4 1 Purpose and scope This document contains the information analysis for the HUMBOLDT Scenario ERiskA. It gives detailed information on the datasets needed and available for the ERiskA use cases as well as on the harmonisation issues arising from those. It also contains a first draft version of the common ERiskA data model. A second version will be provided in PM Information analysis 2.1 Use cases of the Scenario The following use cases have been specified for ERiskA (cf. 754-system_specification_hs_eriska-tum- 001-final) HS06-01: Information exchange HS06-02: Post crisis feedback process HS06-03: Producing regional ERiskA profiles The data model presented in this document especially deals with the information involved in use cases HS06-01 and HS06-03, which were given top priority for implementation. There is still a lack of information availability for HS Therefore in the next sections a short description is given of the overall functionality of these use cases as background information for understanding the data model. 2.2 Scenario main functionality The ERiskA Scenario aims at developing a cross-border disaster management application for the Lake Constance Region which includes Swiss, Austrian and German territories. This application can be used as an add-on to the existing dispatching systems in place at command and control centres dealing with the different steps in the disaster management cycle (e.g. prevention, preparedness, response) in the case of floods. Summary of use case HS06-01: Information exchange: Information on potentially flooded areas and hence resulting inundation of infrastructure like roads and railways has to be exchanged between employees of the command and control centre ( END USER OF GEODATA ) and end users ( END USER OF SPATIAL INFORMATION ) of other agencies or the public in different parts of the cross border Lake Constance Region. This can be the case in an actual flood event or in a simulation / preparedness exercise. The END USER OF SPATIAL INFORMATION requests information if roads or railways in his area of interest are still passable, already flooded or probably flooded soon. The END USER OF GEODATA selects the gauges relevant for the area of interest and accesses information on the current water level at these gauges. Based on this information a corresponding flooded area extend feature is chosen and overlaid or spatially intersected it with the road and / or railway features (for each gauge, pre-calculated potentially flooded area extends for different water levels based on two-dimensional hydrological modelling are stored). The END USER OF GEODATA delivers the information either as a map or he calls the END USER OF SPATIAL INFORMATION. 4

5 Summary of use case HS06-03: Producing regional ERiskA profiles: The employees of the command and control centre ( END USER OF GEODATA ) is responsible for providing international teams with adequate warning maps and/or reports in case of a cross-border flood event. A DATA INTEGRATOR creates regional profiles taking into consideration differences in regulations and classifications of warning levels as well as symbology and terminology used in the regions in the test area. The END USER OF GEODATA applies the appropriate classification schema and matching portrayal rules to the water level measurement at a gauge to generate a map matching the regional profile Functionalities required for the ERiskA application include: providing harmonised cross-border base data for the test area including roads, railways, watercourses, standing waters and elevation as well as background raster data including topographic maps and aerial images. Data harmonisation needs to be done in pre-processing and harmonised base data needs to be stored locally for fast and secure access also during disaster event (complete system is time critical) desktop GIS (or an adapted rich client) as front-end for accessing online and offline data sources as well as visualisation and processing functions (e.g. intersection, bufferin, etc.) selecting features based on spatial operators using interactively created features (e.g. area of interest polygon) or stored features selecting features according to different input parameters (also by resolving non-spatial references e.g. between a certain water level and a corresponding flood area extend feature) integration of in-situ measurement values at gauges (water level and discharge) by accessing the relevant information published online (different providers in the regions of the test area) or by editing of measurement values manually (in case of non-availability of web service). recalculating measurement values (e.g. taking into consideration different vertical reference systems) reclassifying warning levels according to different regional classifications applying individual styles according to different classifications possibly also (multilingual) thesaurus providing support for harmonising hydrology / flood risk terminology 5

6 2.3 (Spatial) information needed for the use cases Information item Road Railway Watercourse Standing Water Gauge Flood Area Water Level Measurement Discharge Measurement Warning Level* Warning Level Classification* Elevation* Aerial Image* Topographic Map* Purpose Information on location and characteristics of roads; also used for spatial analysis (intersection with flood areas) Information on location and characteristics of railways; also used for spatial analysis (intersection with flood areas) Information on location and characteristics of watercourses; also used for choosing relevant gauges Information on location and characteristics of watercourses; also used for choosing relevant gauges Information on location and characteristics of gauges; also used for symbolising warning levels at the gauge Information on location, extend and characteristics of flooded areas derived from hydrological modelling (pre-calculated at certain intervals); also used for spatial analysis (intersection with roads and railways) to determine whether roads and railways are passable or not Information on current and forecasted water levels at a certain gauge provided by in-situ sensors. Used for selecting the appropriate flood area extend feature corresponding to the current water level and for determination of current warning level. Information on current and forecasted discharge values at a certain gauge. Used for determination of current warning level (in cases where it is not determined according to current water level). Information on current warning level at a certain gauge during a flood event Information on characteristics of classification applied to current water levels or discharge values at a gauge in order to determine warning level Information on land elevation used for calculating flood areas Used as background image for orientation purposes and information on types of land cover (forest, settlement, grassland, water, ). Used as background image for overview and orientation purposes * not yet included in the UML data model presented in chapter 3. 6

7 3 Data model Based on the use case description the following sketch for the common data model can be made (see Figure 1-3). pkg Railways and Roads TransportLink + id: Identifier + centrelinegeometry: GM_Curve «lifecycleinfo» + beginlifespanversion: DateTime + endlifespanversion: DateTime [0..1] + name: GeographicalName + validfrom: DateTime + validto: DateTime [0..1] RailwayLink + designspeed: Measure + electrifiedrailwaylink: Boolean + numberoftracks: Integer + railwaytype: RailwayTypeValues + maintenanceauthority: CI_Citation + locationcategory: LocationCategoryValues 1..* RoadLink + fictitious: Boolean + maintenanceauthority: CI_Citation + numbeoflanes: NumberOfLanesType + width: Measure + roadsurfacecategory: RoadSurfaceCategoryValues + functionalroadclass: FunctionalRoadClassValues + formofway: FormOfWayValues + locationcategory: LocationCategoryValues 1..* RailwayLine + railwaylinecode: CharacterString 1 Roa d + europeanroadcode: CharacterString [0..1] + nationalroadcode: CharacterString [0..1] 1 AggregatedTransportLink + id: Identifier «lifecycleinfo» + beginlifespanversion: DateTime + endlifespanversion: DateTime [0..1] + name: GeographicalName + validfrom: DateTime + validto: DateTime [0..1] Figure 1: Package railway and road (Note: The prefix GM_ means that the ISO narmes for the geometry types are used.) 7

8 pkg Hydrography and Flood SurfaceWater + geometry: GM_Primitive + id: Identifier + levelofdetail: IndicativeLoD [0..1] + localtype: LocalisedCharacterString [0..1] + beginlifespanversion: DateTime + endlifespanversion: DateTime [0..1] + geographicalname: GeographicalName [1..*] + hydroid: HydroIdentifier [0..1] + origin: OriginType + persistence: HydrologicalPersistenceType + managingauthority: CI_Citation Watercourse + condition: ConditionType [0..1] + fictitious: Boolean + length: Length + level: LocationType + tidal: Boolean + watercoursehierarchy: WatercourseHierarchyType [0..1] + width: WidthRangeType 1 + elevation: Length + meandepth: Length + surfacearea: Area StandingW ater 1 FloodArea + id: String + geometry: GM_Surface + gaugeid: String + methodofcalculation: MethodOfCalculationType + uncertainty: Float + waterlevel: Decimal 0..* 0..* WaterLevelMeasurement + id: String + timestamp: DateTime + gaugeid: String + waterlevelvalue: Float + statisticannuality: StatisticAnnualityType 0..* DischargeMeasurement 0..* + id: String + timestamp: DateTime + gaugeid: String + statisticannuality: StatisticAnnualityType + currentdischarge: float 0..* 0..* 0..* Gauge + id: String + geometry: GM_Point 1 + gaugeid: String + nameofriver: String 1 + spotelevation: Integer + managingauthority: CI_Citation + meandischarge: Float 1 Figure 2: Package hydrography and flood 8

9 pkg DataTypes Codelists and Enumerations «datatype» Identifier - localid: CharacterString - namespace: CharacterString - versionid: CharacterString [0..1] «enumeration» NameStatus «enumeration» EndonymExonym «datatype» GeographicalName + spelling: SpellingOfName [1..*] + language: CharacterString [0..1] + nativevalue: EndonymExonym [0..1] + status: NameStatus [0..1] + sourceofname: CharacterString [0..1] + pronunciationipa: CharacterString [0..1] + grammaticalgender: GrammaticalGender [0..1] + grammaticalnumber: GrammaticalNumber [0..1] Official Standardised Historical Other «codelist» GrammaticalGender + masculine + feminine + neuter + common Endonym Exonym «codelist» GrammaticalNumbe r + singular + plural + dual «datatype» SpellingOfName + text: CharacterString + script: CharacterString [0..1] + transliterationscheme: CharacterString [0..1] Hydrography and Floods «enumeration» WatercourseHierarchyType «enum» 1st 2nd 3rd 4th 5th other «codelist» HydrologicalPersistenceType + dry + intermittent + perrenial + seasonal + tidal + torrential «enumeration» OriginType «enum» natural manmade heavilymodified «enumeratio... LocationType «enum» onground aboveground belowground «datatype» HydroIdentifier + countrycode: CharacterString + id: CharacterString «enumeratio... Indicativ elod European National Regional Local «datatype» WidthRangeType + lower: Length + upper: Length «codelist» StatisticAnnualityType + 1year + 2years + 5years + 10years + 20years + 50years + 100years «enumeration» MethodOfCalculationType «enum» one-dimensional two-dimensional Railways and Roads «codelist» Railw aytypev alues «enum» + CogRailway = 1 + Funicular = 2 + MagneticLevitation = 3 + Metro = 4 + Monorail = 5 + SuspendedRail = 6 + Train = 7 + Tramway = 8 «enumeration» LocationCategoryValues «enum» OnGroundSurface = 1 SuspendedOrElevated = 2 Underground = 3 «data Type» NumberOfLanesType + numberoflanes: Integer + direction: DirectionValues «enumeratio... DirectionValues «enum» Positive = 1 Negative = 2 Both = 3 None = 4 «enumeration» RoadSurfaceCategoryValues «enum» Paved = 1 Unpaved = 2 «enumeration» FunctionalRoadClassValues «enum» MainRoad = 1 FirstClass = 2 SecondClass = 3 ThirdClass = 4 FourthClass = 5 FifthClass = 6 SixthClass = 7 SeventhClass = 8 EighthClass = 9 NinthClass = 10 «codelist» FormOfWayValues + BicycleRoad = 1 + DualCarriageway = 2 + EnclosedTrafficArea = 3 + EntranceOrExitCarPark = 4 + EntranceOrExitService = 5 + Freeway = 6 + Motorway = 7 + PedestrianZone = 8 + Roundabout = 9 + ServiceRoad = 10 + SingleCarriageway = 11 + SlipRoad = 12 + Tractor = 13 + TrafficSquare = 14 + Walkway = 15 Figure 3: Data types, codelists and enumerations 9

10 In the draft data model as shown in figures 1 3 feature types and data types of the following INSPIRE Data Specifications have been re-used: Hydrography (V 1.5.2): SurfaceWater, Watercourse, StandingWater, HydroIdentifier, WatercourseHierarchyType, OriginType, HydrologicalPersistenceType, LocationType, IndicativeLoD, WidthRangeType Transport Networks (V 1.6): TransportLink, RailwayLink, RoadLink, RailwayLine, Road, AggregatedTransportLink, RailwayTypeValues, NumberOfLanesType, FormOfWayValues, DirectionValues, FunctionalRoadClassValues, LocationCategoryValues, RoadSurfaceCategoryValues Geographical Names (V 2): GeographicalName, SpellingOfName, NameStatus, EndonymExonym; GrammaticalGender, GrammaticalNumber Generic Conceptual Model: Identifier At the current state of the data model, the following modifications have been made to the above mentioned parts of the INSPIRE Data Specification: The inheritance hierarchies have been "flattened" to a maximum of two levels. The aggregation between Road and Roadlink as well as Railway and RailwayLink has not been created via DirectedLink but directly Transport Network attributes were used directly as attributes in e.g. Roadlink feature type and not via relations to property feature types which are subtypes of the class TransportProperty (as suggested in the Transport Networks Data Specification) The current ERiskA data model is still in draft status and not complete yet (see also chapter 6.1). Additional analysis of the characteristics of the information available for use case HS06-03 (e.g. Warning Level and Warning Level Classification) has to be carried out. Furthermore a deeper look will be taken at the feasibility of the selected INSPIRE Data Specifications elements (e.g. if the complexity of the GeographicalName type is really needed for the use cases). The draft data model will also be discussed with the ERiskA key users again. 4 Datasets needed (use cases HS06-01 and HS06-03) A table in the Annex relates the feature classes identified in the data model to concrete data sources (in the form of static data in files or databases, dynamic data produced in real-time, or web services that serve the data on request) of the German states Baden-Wuerrtemberg (BW) and Bavaria (BY), the Austrian state Vorarlberg (VA) and Switzerland (CH). It also provides a detailed description of their characteristics and availability. Attributes taken from INSPIRE Data Specifications are marked yellow in the table. Concerning availability of data, there is a general licencing issue. Swiss data needed for the use cases is available at the ETHZ, but actually only licensed for usage at ETHZ. German data is available at TUM but only licenced for scientific usage within TUM. According to the terms of the licences it is e.g. not allowed to provide the data web service (neither publicly accessible nor in the HUMBOLDT intranet). 10

11 Further general issues are that conceptual data models formalised in a conceptual schema language exists only exist for Swiss vector data and not for German and Austrian data. Metadata described in a standardised way only exist for Swiss and Austrian data. Specific problems arrising from the different characteristics of the datasets are described briefly below. For further information, especially concerning street data, please refer to A7.0-D2 Data Harmonisation Processes V Road Road data was obtained from the mapping agencies of the four regions in the test area. German road is part of the digital landscape models of Baden-Wuerttemberg and Bavaria (ATKIS), Swiss road data is part of the cartographic model of Switzerland (Vector25) and Austrian road data was obtained form the regional SDI in the state Vorarlberg. This data had originally been extracted from the Austrian landscape model (DLM) but was updated and modified in Vorarlberg. Despite an identical data model and file format for Baden-Wuerttemberg and Bavaria, the resulting road data files differed considerably concerning due to different export processes. Another drawback of the shapefile export is that relations are destroyed witch leads to redundant data but also a loss of information. Thus it is hardly possible to generate a link-node-network. Further main differences between the different regions include: different classifications for functional road class and form of way different concepts of what a distinctive road feature instance is. VA: collection of line segments having the same street name; DE: collection of line segments distinguished by their functional class or international relevance (any other attributes distinguish the street segments); CH: collection of continuous line segments stretching from node to node. 4.2 Railway Railway data was obtained from the same sources as road data and thus the general issues are very similar to those described above. Looking at the attributes of the railway data of the different regions, it was found that they contain only a small portion of the information needed to fill the attributes foreseen by INSPIRE. This is especially true for the Austrian data. 4.3 Watercourse and Standing Water Watercourse and standing water data was also obtained from the same sources as road and railway data. Main differences between the different regions include: different classifications of river width different classifications of watercourse hierarchy 11

12 4.4 Gauge Information location and characteristics of gauges in the Lake Constance Region is available from websites of flood risk management agencies (cf. chapter 4.6) but the actual point dataset to be used for ERiskA still has to be created. 4.5 Flood Area Originally it was planned to obtain flood areas created using hydrological modelling from hydrological institutes / agencies in the different regions. But since there are no such modelling results available at the institutes yet for the Lake Constance Area, provisional flood areas had to be calculated by the ERiskA team using simple terrain intersection based on the digital terrain models. Here different resolutions and different vertical reference systems of the digital terrain models had to be taken into consideration. The flood areas are now available at certain intervals of water levels for each gauge. 4.6 Water Level Measurement Current water level measurements (in m) are available for watercourses and standing waters from the websites of the four different flood risk management agencies in the Lake Constance Test area. The measurements are taken and the websites are updated at different intervals in the different regions. All websites provide alphanumeric data and charts integrated into the websites. Bavaria, Baden- Wuerttemberg and Switzerland also provide online warning maps using different symbology and different warning level classifications (see chapter 4.9). The water levels are measured against different reference heights in the different regions, e.g. referring to see level (also different: Triest or Marseille) or gauge level. A concept for integrating this dynamic information into the ERiskA demonstrator application is currently being developed. 4.7 Discharge Measurement Discharge values (measured in m³/s) are naturaly only avaliable for watercourses and not for standing waters. 4.8 Warning Level Information on the current warning levels at a the gauge are also available from websites of the different flood risk management agencies. They are calculated differently in the different regions (using water level or discharge value) and they are classified very differently (see chapter 4.9). 4.9 Warning Level Classification The warning level classifications differ considerably among the regions in the Lake Constance Region: Bavaria: four levels according to dimension of impact (e.g. agricultural areas flooded, basement of settlement areas flooded) Baden-Wuerttemberg: eight levels according to statistic annuality of water level at a gauge Vorarlberg: two warning according to fixed water level at each gauge 12

13 Switzerland: seven levels expressed as percentages of the long-term mean monthly discharge value This information item is not yet included in the table of annex I since there is further research necessary Elevation Main differences between the digital terrain model files from the different regions include different resolutions ranging from 1 m to 50 m as well as different vertical reference systems Aerial Image The aerial images differ mainly in resolution, ranging from 12,5 cm to 80 cm Topographic Map A cross-border topographic raster map (M 1:50000) is available for the Lake Constance Area from the project Bodensee Geodatenpool. This data has already been harmonised e.g. concerning scale, style and edge matching. 5 Harmonisation requirements This chapter is based on the table in chapter 5 of the ERiska System Specification (cf system_specification_hs_eriska-tum-001-final) as well as the ERiskA data harmonisation requirements as entered into the HUMBOLDT Requirements Site (Volere). These requirements are meant for all use cases. Chapter 5.12 summarizes which issues have the highest priority in the ERiskA Scenario. 5.1 Data format The majority of base vector data sets (e.g. roads, railways, watercourse) of the four regions is available as shapefiles, only some as Arcinfo route feature classes. Raster data formats include ASCII grid, geotiff, TIFF and Mr. SID. The target is to achieve syntactical interoperability by establishing standardised web services (WMS, WCS and WFS) for these datasets. The cross-border topographic map is already available as a web service. However, this is a proprietary solution which is not OCG conformant. 5.2 Spatial and temporal reference systems Spatial reference system The spatial reference systems (SRS) of the different regions are Bavaria (Germany): EPSG:31468 (DHDN / Gauss-Krüger zone 4) Baden-Wuerttemberg (Germany): EPSG:31467 (DHDN / Gauss-Krüger zone 3) Vorarlberg (Austria): EPSG:31257 (MGI / Austria GK M28) 13

14 Switzerland: EPSG:21781 (CH 1903 LV03) These SRS also differ in datum, mean sea level reference (Amsterdam, Triest, Marseille) and projections used (Transverse Mercator and Oblique Mercator) For transforming data form the source SRS to the common target SRS (ETRS89?) there are generally several different options: a. Publish the datasets default in the WFS in the target spatial reference system b. Transform by the WFS upon request by the client (possible in WFS 1.1) c. Let data be transformed by a Web Coordinate Transformation Service (a WPS or other inbetween service) d. Transform data to common/target spatial reference system in the client (some clients do that automatically if they know the SRS of the incoming data). Since the base data for the ERiskA application needs to be pre-processed and stored locally in a harmonised way, the coordinate transformations to the common SRS (ETRS89?) will in many cases be handled during the pre-processing phase using the GIS client (option d.). For on-the-fly integration of further data, the usage of a Web Coordinate Transformation Service is needed. 5.3 Conceptual data model The conceptual data models for the base data sets (esp. transportation networks and watercourses) differ widely between the four regions in the Scenario. Current solutions to overcome the differences in data model rely on manual work. There are no (semi-) automated tools for data model harmonisation available. This document contains the first version of the ERiskA conceptual data model (see chapter 3), which suits and serves the use cases for ERiskA. Additionally we expect the HUMBOLDT framework to provide at least semi-automated solutions for the harmonisation of conceptual data models. They should facilitate the transformation data of different structures (concerning the data model) in a way, that the source data is available in the target structure. Currently, conceptual data models formalised in a conceptual schema language only exists for Swiss vector data (in INTERLIS). Thus the data models of the source data have to be created by reverse engineering from the data formats and feature catalogues (in case they are available), before (semi-) automated schema translation tools can be applied Geometry types This issue still has to be investigated further Identification and Versioning At the current state, it is not clear yet, if it s important to keep versions (history) of data. 14

15 5.3.3 Importance of time (temporal attributes) There are timestamp attributes for the water level and discharge measurements. All four regions of the test area lie within one time zone but there are different granularities (e.g. only full hour or also minutes). 5.4 Classification There are a number of codelists and enumerations in the source as well as the target data model as outlined in chapter 3 (see figure 3). For the transformation of the existing datasets to the common data model this means that the attribute values of these attributes will have to be reclassified as part of the data transformation. However, not all reclassification issues will prove as solvable. Mayor issues arise e.g. form different river width classes, classifications which are based on totally different aspects in different regions like the warning level classifications in the four regions (see chapter 4.9.) or the different watercourse hierarchy types (based on hydrological or administrative aspects). Especially the warning level classification profile issue needs further investigation within the ERiskA team. An ideal solution would be that different individual classifications can be applied to a certain water level measurement at gauge. E.g. the user can select a "German classification" to be applied to a Austrian water level measurement. 5.5 Terminology Terminology used e.g. for the hydrology / flood / warning level information items differ considerably amongst the regions in the test area (although sharing the same language). In case the mapping rules are defined manually (like it was done in the schema translation task force experiment) it is sufficient, if the person defining the mapping rules has expert knowledge of the terminology used in the four regions. The development of a common vocabulary based on a thesaurus could also be an option in case mapping rules are to be defined semi-automatically. This needs to be investigated further. 5.6 Metadata Currently metadata described in a standardised way only exist for the base datasets (transport networks and watercourses) and here only for Swiss and Austrian data. Metadata elements needed for the ERiskA application are currently being investigated. An ERiskA metadata profile based on (and probably extending) the common HUMBOLDT profile will be included in a later document. 5.7 Scale/resolution, level-of-detail, aggregation Datasets of the four regions are available in different scales (e.g. Austrian road data 1:1000 and German road data 1:25000). Source data available in a larger scale must be generalised in a way that it can be merged with smaller scale data with a certain positional accuracy (still to be defined). 5.8 Portrayal Individual styles must be applied according to different classifications. 15

16 5.9 Processing functions This issue still has to be investigated further Multilinguality All source data is available in German and the ERiskA application interface will also be in German. The target data model including attribute values according to codelists and enumerations is in English, since INSPIRE Data Specification have been re-used and the data model is supposed to be transferable also outside the immediate test area of ERiskA Spatial, temporal and thematic consistency of data Spatial consistency There are two types of spatial consistency issues in the ERiskA test area a. Cross-border: edge matching is required at the borders between the states / countries in the test area. A maximum distance threshold ("snapping tolerance") is still to be defined. b. Same geographic area: this applies e.g. to overlapping areas in datasets of adjourning states / countries but also to flood areas calculated for the Lake Constance based on different gauges located at its perimeter and digital terrain models. The input datasets need to be merged as seamlessly as possible 5.12 Priorities In order for the cross-border ERiskA application to work properly, all of the above harmonisation issues have to be solved at some point, but currently top priorities for ERiskA are: Conceptual data model Classification Spatial reference systems Scale/resolution Portrayal Spatial consistency 6 To discuss General issues to be discussed and dealt with in WP7 and WP9 include: level on which the data model harmonisation is to be carried out (level of conceptual data models in UML or exchange formats like GML) formalism to be used for describing the mapping rules 16

17 tools to parse the mapping rules ways to generate a transformation report containing all data manipulations carried out along the steps in the transformation chain in human readable form, esp. concerning the quality issues. usage of the HUMBOLDT Editor in the Scenarios means of extracting the data harmonisation requirements of the different HUMBOLDT Scenarios and feeding them into the HUMBOLDT framework specification process. 6.1 Scope of data model The following information items are not yet modelled in the current draft version of the data model: Warning Level Warning Level Classification Elevation Aerial Image Topographic Map Aerial images and topographic maps are only used as background images and will thus probably not be included in the data model. Further research is necessary to decide on how to model the warning level and warning level classification items. 6.2 Access to needed datasets A pragmatic solution has to be found for the data licensing issues described in chapter 4. 7 Related projects and initiatives In the process of creating the data model, the following related activities have been analysed: INSPIRE Data Specification Hydrography (INSPIRE Thematic Working Group Hydrography 2008) INSPIRE Data Specification Transport Networks (INSPIRE Thematic Working Group Transport Networks 2008) INSPIRE Data Specification Geographical Names (INSPIRE Thematic Working Group Geographical Names 2008) Generic Conceptual Model (Drafting Team Data Specifications 2008) RISE Conceptual Schema (RISE 2007) Water Framework Directive Data Model (Laboratório Nacional de Engenharia Civil 2007) Wide Information Network for Risk Management Data Model CrisisEvents (Wide Information Network for Risk Management 2007) 17

18 ArcGIS Hydro Data Model (ESRI 2003) Federal Emergency Management Agency Flood Hazard Geodatabase Design 8 Glossary TODO 9 References Drafting Team Data Specifications (Ed.) 2008: INSPIRE Generic Conceptual Model. Available online at (accessed 19 December 2008). ESRI (Ed.) 2003: ArcGIS Hydro Data Model Visio. Available online at (accessed 11 August 2008). INSPIRE Thematic Working Group Geographical Names (Ed.) 2008: INSPIRE Data Specification on Geographical Names Draft Guidelines. Available online at on_gn_v2.0.pdf (accessed 19 December 2008). INSPIRE Thematic Working Group Hydrography (Ed.) 2008: INSPIRE Data Specification on Hydrography Draft Guidelines. Available online at on_hy_v2.0.pdf (accessed 19 December 2008). INSPIRE Thematic Working Group Transport Networks (Ed.) 2008: INSPIRE Data Specification on Transport Networks Draft Guidelines. Available online at on_tn_v2.0.pdf (accessed 19 December 2008). Laboratório Nacional de Engenharia Civil 2007: The Water Framewok Directive Geospatial Data Model. Article 3 Dataset. RISE (Ed.) 2007: Conceptual Schema in UML. Version 1.1. Available online at (accessed 11 August 2008). Walker, S. 2006: FEMA Flood Hazard Geodatabase Design. Available online at (accessed 11 August 2008). Wide Information Network for Risk Management (Ed.) 2007: Data Model Specifications CrisisEvents data model. Available online at 20CrisisEvents.pdf (accessed 11 August 2008). 18

19 Annex: ERiskA datasets 19