Eric Braun
email: eric.braun2@kit.edu|thorsten.schlachter@kit.edu

Thorsten Schlachter

Clemens Düpmeier
email: clemens.duepmeier@kit.edu

Karl-Uwe Stucky
email: karl-uwe.stucky@kit.edu

Wolfgang Suess
email: wolfgang.suess@kit.edu

Wolf- Gang Suess

A Generic Microservice Architecture for Environmental Data Management

Keywords: Microservices, Data management, Environmental Information Systems (EIS), Databases, Time Series, REST, Semantic Web, Linked Data, Big Data 1

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

Introduction

Nowadays the Internet of Things and modern Internet infrastructures lead to a massive amount of data stored in data centers all around the globe. In the field of environment, the sensorization of the environment and new crowdsourcing applications will also produce large amounts of data which have to be stored, managed and analyzed timely in order to provide early input for decision makers and the general public. Often, the acquired data in such applications consists of a mixture of measurement data, more general time series data, structured master data or unstructured text or binary assets. The most useful tools to get an insight into this data are visualizations and data analysis. However, classical information system architectures and desktop data analysis and visualization tools have severe problems in handling large amounts of data and new techniques are needed to manage these amounts of data in a scalable way. Therefore, the Web based Information Systems (WebIS) and Data Life Cycle Lab Energy (DLLE) groups at KIT/IAI work on a new data management runtime environment based on microservices [START_REF] Fowler | Microservices -definition of this new architectural term[END_REF], which can be easily integrated with Big Data infrastructures, and scalable data analysis and web based visualization tools. Based on the microservice reference architecture introduced by Gartner1 a new modular set of distributed services instrumenting a polyglot distributed data management model on top of an underlying Big Data environment was implemented. These services can be used with additional infrastructure services to provide a very generic and flexible scalable data management infrastructure with all the features needed by modern large scale web based information system applications. Based on these services, existing environmental backend applications for data management, such as the environmental information system applications within the LUBW 2 , can be brought to a state-of-the-art level of technology to provide a future-proof way of managing the massive amounts of data which will be gathered and analyzed by future Web and mobile environmental information system applications. This paper describes the chosen basic architectural approach and then focuses on the mentioned collection of basic microservices that were conceptualized and implemented to create a generic solution for an efficient large-scale (environmental) data management. Further papers will describe other aspects of the architecture and specific microservices.

Basic Concepts and Main Goals

Data management is needed in many application domains other than the environmental domain. For example, the research groups at the KIT are also involved in several smart grid projects in which it is critical to gather and analyze large amounts of data for future energy system solutions. Therefore, the KIT was looking for a data management solution which not only applies to the environmental but also to the smart grid domain. The architecture described in this paper fulfills this requirement and is conceptualized based on very generic data type notions that enable data management for nearly any domain.

Current information system applications in the environmental area are often still implemented as big monoliths using a standard multitier architecture, in which the data tier is concentrated in one relational database model and access layer. The resulting data model has a very strong structure but ties the whole data management to one application or application domain and does not scale horizontally to meet performance needs in a world of big data. A microservice based architecture can replace this monolithic data management concept by providing a set of modular and low coupled data services whereas each service defines its own data management tier based on a more generic and reusable data model and the most adequate database technology underneath which is not necessarily a relational database system. Microservices in general can be defined as follows:

"In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies." James Lewis and Martin Fowler, 2014 [emphasis added]

Microservices are typically designed to scale horizontally to meet the currently needed performance. Since microservices separate functionalities into distinct services, each functionality can be scaled independently from each other according to the need. This advantage directly applies to data management because often scaling is not needed for the whole data model, e.g. for some rather static or seldomly used parts, but only for providing access to highly frequented parts of the data.

In a polyglot data model different data services use different database technologies to provide a more generic data handling and data access. For example, a document oriented database can be used to implement a very generic model of structured master data storage without tying the implementation too much to a specific master data schema. Nonetheless, a separate schema service which describes specific types of master data more precisely can provide all benefits of having a strong schema without hardcoding the data type schemas into the implementation of the master data service.

Another advantage of microservices is the more modular development approach allowing projects to be performed by smaller independent development groups, each of them having to manage just one or a few microservices. The communication between microservices is often realized using REST over HTTP(S). This communication interface is the only component of a microservice that is visible from the outside. Everything else, like application and data logic, is hidden within the service. Therefore, the REST API is the only interface that has to be standardized across development teams. This has the benefit that all technical interfaces between the otherwise separate projects are externalized. However, this also makes it crucial to define a proper API with an appropriate documentation and manage these APIs application or enterprise wide (called API management) in order to guarantee long term stable interaction between microservices and clients. This paper will demonstrate how dedicated microservices can be conceptualized which allows the management of large amounts of different types of data by instrumenting a polyglot data model. The different services follow a common philosophy which leads to a REST API that is similar in its core for all services. A first prototypical implementation that proves this concept and solves first development challenges is discussed.

Fig. 1. Overview of microservice based architecture

The architecture can be split into three main functional areas: microservice management capabilities, actual microservices and operational capabilities. In the following only the second part is of major importance. Although management and operational capabilities are crucial for operating and maintaining a microservice architecture, this paper mainly focuses on which microservices are needed as part of the inner architecture to provide a scalable data management functionality for large scale information system applications.

Typically, microservices are designed to be load balanceable which leads to a (horizontally) scalable system. Therefore, the management layer of the Microservice Architecture contains an API gateway which distributes incoming client calls with the help of a discovery and routing service onto different instances of the inner services. Communication with the management layer and clients is generally achieved by using REST over HTTP(s) or WebSockets 3 . The communication between different microservices is implemented using a message channel (e.g. Apache Kafka4 ) to realize asynchronous messaging. This leads to more autonomous services because there are no synchronous and therefore blocking dependencies. Each microservice has its own execution environment which enables a service to be deployed as a container using container virtualization technologies (e.g. Docker 5 ). This enables services to be automatically deployed, updated, and to run on many different platforms. Container automated services can also be scaled by increasing or decreasing the number of replicated instances. Service instances are registered with the discovery service and a heartbeat detection checks if instances are still alive. The execution environment of a service instance may also include a private, internal database system but usually the database systems are separated from the microservices in order to keep the latter stateless. This enables databases to scale independently from the used services. As already mentioned for operating such microservice based applications a computing cluster with support for container virtualization is needed (this is typically the case in modern cloud environments). If the cluster or cloud environment also supports a Big Data stack (such as Apache Hadoop 6 ), then Big Data tools, like NoSQL database technologies, can be used and integrated with the inner architecture microservices. As already explained the term polyglot data model means that each service is supposed to use the database technologies which are optimized for the data type managed by the service.

Figure 2 displays a more detailed architecture of the data management services. It shows the gateway as the single access point for client applications which allows to use a single harmonized URL space as well as a single REST API pattern to access the different services. This harmonized URL space and single API is key for the integration of the otherwise on several services distributed data. Each data object stored in a data management service is represented by a unique URI and URIs can be linked to each other to implement relations. Additionally, semantic services define the structure and interrelationship of the otherwise distributed data and provide this knowledge to the application and/or other services.

Fig. 2. Data management architecture

The inner architecture for data management consists of five microservices which are briefly described as follows:

• Link Service: a semantic service that is used internally to create relations between data. This service is crucial to create semantic links between different data objects. The service follows the concepts of linked data and semantic Web [START_REF] Bizer | Linked Data -The Story So Far[END_REF]. • Schema Service: a semantic service that manages schema descriptions (format, data types, etc.) of data objects stored in the different services. • Master Data Service: manages structured data describing specific objects, i.e. master data.

• Time Series Service: manages time series data. Persistence is usually achieved using a time series database. The separation of time series data into a separate service has many advantages as already depicted in [START_REF] Leighton | A Best of Both Worlds Approach to Complex, Efficient, Time Series Data Delivery[END_REF]. • Digital Asset Service: manages digital assets similar to systems like Alfresco 7that feature a CMIS8 interface.

Another important feature of the architecture is shown in Figure 3 using e.g. the Time Series Service. Each of the data management services is connected to the persistence layer through one or more specific adapters that create a mapping between a concrete database technology used to implement a persistence layer and the respective service. This enables the independent development of persistent layers using different database technologies. The service itself is completely generic and has no dependencies on the underlying database technologies.

Services in Detail

This chapter focusses on the following services: Schema Service, Link Service and data discovery. The other services mentioned in the previous chapter are discussed in more detail in Schlachter et al. [START_REF] Schlachter | A Generic Web Cache Infrastructure for the Provision of Multifarious Environmental Data[END_REF]. The Schema Service stores the structure, data types and other semantic information of the data stored in the basic data services. The Master Data Service benefits most from the Schema Service because master data is meant to be of a specific structure using specific data types. The main exchange format for the different services is JSON. Therefore, the Schema Service uses JSON schema9 as default format to store and exchange schema information. An example for such a schema is depicted in Figure 4. It is a schema for an air measurement station. Beside the required attributes id and name this example contains two attributes that hold information about the particulate matter limit and current value. Additionally, the attribute timeSeries is a complex type that is not part of the official JSON schema standard. Such a complex type usually has an own schema also described in the Schema Service. The service itself uses a document oriented database to store the JSON schemas efficiently.

The service is meant to be used internally mainly by the Master Data Service to validate incoming data and to add schema information to the data to implement linked data. The concept of linked data [START_REF] W3c | JSON-LD 1.0 W3C Recommendation[END_REF] can be used by applications that consume both; master data and their semantics.

Furthermore, the Schema Service can also be directly accessed from clients (through the gateway) to request a specific schema. This feature is used by applications that generate generic inputs and need the structure of the different fields to do so.

An additional requirement for the Schema Service is the support of different versions and namespaces. The structure of data can change over time which leads to an updated schema for the data. With introduced versions, the schema can exist in more versions and the Master Data Service can associate the data to the appropriate version depending on the changes. The namespace can be used to use the same schema name in different contexts.

{

"title": "Air Measurement Station", "type": "object", "properties": { "id": { "type": "string" }, "name": { "type": "string" }, "pm10Limit": { "type": "number" } "pm10Current": { "type": "number" } ... "timeSeries": { "type": "timeSeries" } }, "required": ["id", "name"] }

Fig. 4. JSON schema of an air measurement station

Simple applications only need one of the services because they process a single type of data but more complex applications might need multiple data sets and most probably data sets that are related to each other. Using a microservice architecture, the data is distributed among different services which means that there is a need for a service that defines relationships between different data sets and objects. This service is called Link Service in our architecture. It allows to fully support linked data. The Master Data Service can only support the linked data concept for one data object but with the help of the link service data, corresponding schema information and relationships between data objects can be aggregated into one linked data description of complex interrelated data.

Links are implemented using URIs that point to the data. Additionally, relationships can define additional properties. Applications have the possibility to get a data object with all their links as URIs or with resolved links which lead to nested data objects. Figure 5 presents an example with both options in a pseudo format that is not part of the specification but only to explain the link resolving concept. The first option is the master data object for the air station mentioned above that contains two links that point to time series data for the measurements of air pollutants NO2 and PM10. These links have to be fetched separately from the application in order to get the actual time series data. The second option contains the same master data object but the links are already replaced by the data. Additionally, both objects have a PM10 limit and a current value that obviously matches the last value of the time series.

Fig. 5. Time series link resolving

A third concept that will be discussed in this chapter is data discovery. Unlike the described services, the Data Discovery Service will only be used internally and has no external API. It closes the gap between data services (e.g. Master Data Service, Time Series Service) and a specific adapter. As discussed in the previous chapter, data services are implemented by internally using an abstract persistence interface which decouples them from specific implementations of the persistence layer using a certain database technology. One data service can use more than one persistence layer implementation. This abstraction leads to the requirement that a data service needs a way to find out in what persistence layer a specific data set (e.g. master data object or time series) is stored, and this information is provided by the Data Discovery Service. Figure 6 depicts an example for the Time Series Service. The Time Series Service gets the storage location of data using the identifier that is externally communicated as lookup key to the Discovery Service which returns the storage location. The request can then be forwarded to the appropriate adapter. This separation of core services and their underlying persistence layers allows the services to be much more flexible and generic. The Data Discovery Service can be used by every service that stores data in a location that is not known by this service itself.

Fig. 6. Time series service and Data Discovery Service interaction Prototype and Evaluation

The generic microservice based architecture was implemented as a prototype and evaluated in context of concrete information system applications, such as environmental information systems and smart energy systems control center software. The Gateway Service is implemented manually in the current prototype environment omitting load balancing features for the moment. In the future, it will likely be replaced by gateway tools like Netflix Zuul10 for more complete operation. The data management services except the Digital Asset Service are already implemented to some extent. All microservices are implemented using the Java Framework Spring Boot11 as implementation framework. The Schema Service and the Master Data Service use the document-oriented MongoDB NoSQL database as one persistence layer option by using specific adapters as described above. The Time Series Service is implemented with an OpenTSDB adapter. The adapters are implemented as own microservices which convert the HTTPS requests from database specific requests into abstract requests and vice versa. The communication between microservices as well as between the gateway and the client applications is realized using REST over HTTP(S). The asynchronous messaging channel mentioned while describing the architecture will be used in the future version to lower the synchronous coupling between services. Instead, services will cache data from other internal services. Decoupling and data actualization of cached data will be instrumented via the message channel. An appropriate solution using spring cloud stream and RabbitMQ was already tested in a separate prototype.

Fig. 7. Environmental information system Umweltnavigator

The Link Service is implemented using the Neo4j graph database12 to model the different relations. To connect two data objects only their URI and a relation key are stored. Data can be fetched using the unique URI. The relation key can be used to further filter data by relation type. Such a relation key can describe the multiplicity of the relation or its semantic context. The first prototype using the generic microservice architecture was implemented as background data service infrastructure for a showcase of the environmental information system "Umweltnavigator Bayern" of the "Bayerisches Staatsministerium für Umwelt und Verbraucherschutz". As shown in figure 7, a web page of the Umweltnavigator displays a map of different air measurement stations. A specific station can be selected within the map resulting in the display of more information about the selected station in the right panel and the display of the related measurement data within the bottom visualization. Multiple backend services are accessed in parallel to aggregate this page. The map is filled with information from a geo service that contains the location and icon information of each measuring station. The panel to the right shows more detailed information about the station which is fetched from the Master Data Service. The visualization at the bottom uses the same master data object and fetches the different available time series datasets referenced by the master data object. The URIs pointing to the time series datasets are resolved by the Master Data Service using the Link Service which contains the relationship information between measuring station and the measured time series. This example shows the interaction of the basic data services and more complex services like the Link Service or the Geo Service. The second prototype (figure 8) is used as a background data service infrastructure for a web based dashboard solution that displays the energy consumption of buildings. The prototype of the dashboard solution beside the backend services was developed in a diploma thesis [START_REF] Pathomkeerati | A new generic Approach for Web based Dashboard Solutions in a Microservice Architecture[END_REF]. The following description explains the usage of the web page from the point of view of a user and of a dashboard manager who creates and customizes pages. An end user accessing the dashboard web page with his browser can select a building on the map which then changes the visualizations of the measurement data accordingly to data that belong to that building. Similar to the previous prototype the visualization uses the master data and the Time Series Service to display the data. Furthermore, the dashboard solution offers additional functionality to customize the structure of the dashboard web page. A dashboard manager can change the information that is shown based on what the master data object that is displayed (in this case: a building) offers. The Schema Service provides this information for the dashboard configuration dialog. Therefore, the dashboard manager sees the different properties that a building can have, including the time series datasets. This allows him to customize every block of the dashboard page that can display information of an arbitrary master data object of a certain type (e.g. a building). In contrast, using a less generic solution, each building needs a manually customized page which does not scale for a large amount of buildings. This more complex scenario shows that the additional use of the Schema Service allows the development of smart applications that provide generic features.

Both prototypical implementations present first proofs of the concept and already show the great potential of the envisioned solution. The generic data service infrastructure is used in both use cases to provide application specific data to web applications belonging to different application domains. Both applications directly use the REST API of the different services which result in an easy and lightweight communication. The scalability of the backend was not tested yet but overall the architecture is scalable because every microservice can be deployed multiple times behind the gateway without changes to the implementation of the prototypes. Furthermore, although the data services work with a very generic data model, the Link Service and the Schema Service can be used to implement applications that use additional meta information like relationships or schemas to fulfill very specific and more complex requirements regarding the data semantics of the stored data objects. This information is not hard coded within the implementing data services but can be configured as needed by using the semantic services.

Conclusion and Outlook

This paper shows a concept for a generic service oriented data management infrastructure for managing a large variety of data which can be implemented with state-of-theart microservice frameworks and database technologies. The framework uses a polyglot data model and provides distinct services for managing large amounts of heterogeneous data in a generic way. Especially the separation of schemas, master data, time series data and digital assets was discussed in detail. An additional feature of the architecture discussed is the abstraction from database technologies. This enables the microservice architecture to be even more generic because the exposed interface is completely independent from underlying technologies. A prototype was implemented and used for an evaluation of the concepts with two web applications belonging to different application domains. The evaluation showed that the presented microservice architecture can be used in many application domains that have to deal with heterogeneous data, different databases, and that need a high performance and scalability which can be provided by horizontal scaling of the microservices.

The concept and the prototype can and will be extended in various ways. Firstly, the Gateway Service will be replaced by a tool like Netflix Zuul or NGINX Plus which is more reliable and has more features than the service implemented in the prototype. Secondly, an upcoming version of the prototype will also provide an additional binary and therefore faster communication interface than a pure REST API (e.g. by using web sockets). Tools like RabbitMQ13 and Apache Kafka14 can and will be used as messaging systems implementing a publish/subscribe protocol for decoupling clients and services which makes the whole system more elastic. Additionally, they will support distributing data to other services beside the Data Management Service, like dedicated data analytics pipelines. Another step towards the compatibility with more Web applications is to add services that can provide data in generic ways (e.g. in feed formats). Such services can be full text search or geo services (see [START_REF] Schlachter | A Generic Web Cache Infrastructure for the Provision of Multifarious Environmental Data[END_REF]). Furthermore, the generic web visualization framework [START_REF] Braun | Generic Web Framework for Environmental Data Visualization[END_REF], which is also developed by the WebIS research group, is already integrated with the microservice architecture and it is already implemented using a microservice backend. This will allow to easily explore data by using advanced visualizations.

Fig. 3 .

 3 Fig. 3. Abstraction layer between the Time Series Service and time series databases

Fig. 8 .

 8 Fig. 8. Dashboard solution using the service infrastructure

http://blogs.gartner.com/gary-olliffe/2015/01/30/microservices-guts-on-the-outside

Baden-Wuerttemberg State Institute for Environment, Measurements, and Nature Conservation, Karlsruhe, Germany

https://tools.ietf.org/html/rfc6455

https://kafka.apache.org

https://www.docker.com

http://hadoop.apache.org

https://www.alfresco.com

http://docs.oasis-open.org/cmis/CMIS/v1.1/cs01/CMIS-v1.1-cs01.html

http://json-schema.org

https://github.com/Netflix/zuul/wiki

http://projects.spring.io/spring-boot

https://neo4j.com

https://www.rabbitmq.com

http://kafka.apache.org

Architectural Overview

The microservice based architecture used is inspired by the reference architecture of Gartner [2]. Figure 1 shows this reference architecture.


Peter A Fischer-Stabel
email: p.fischer-stabel@umwelt-campus.de

Environmental Software Systems in National Park Monitoring and Management

Keywords: National Park Monitoring, Environmental Software System, National Park Management

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

Introduction

The world network of nature reserves has remarkable high natural values (high ecological integrity, high biodiversity, limited human use, rather unstressed systems, resource management is not extraction-oriented, etc.) and often high cultural values in addition. Within this network, because of their large coverage, especially the National Parks (NP), but also the UNESCO MaB Biosphere reserves serve as sites for traditional environmental monitoring and, in addition, as laboratories for research and demonstration of ways in progressing towards sustainability of human-environment interactions (including wise-use and economic development). Terabytes of data are collected in the different application domains in the long term monitoring programs of a national park, but also in single one shot data acquisitions, analysing and discussing highly specialized research topics. This paper gives an overview about the very high diversity of data collected in national park monitoring and management and of the variety of software systems required to deal with all these data. The concrete setting is the youngest national park in Germany -the NP Hunsrück-Hochwald, inaugurated in 2015.

National Park Hunsrück-Hochwald

Behind all national parks worldwide, there is a common idea: the conservation of 'wild nature' for posterity [START_REF]Living Parks, 100 Years of National Parks in Europe[END_REF]. The International Union for Conservation of Nature (IUCN) discusses the parameters defining a national park. In 1969, the IUCN declared a national park to be a relatively large area (> 1000 ha) with the following defining characteristics [START_REF] Gulez | A method of evaluating areas for national park status[END_REF]:

• One or several ecosystems not materially altered by human exploitation and occupation, where plant and animal species, geomorphological sites and habitats are of special scientific, educational, and recreational interest or which contain a natural landscape of great beauty; • Highest competent authority of the country has taken steps to prevent or eliminate exploitation or occupation as soon as possible in the whole area and to effectively enforce the respect of ecological, geomorphological, or aesthetic features which have led to its establishment; and • Visitors are allowed to enter, under special conditions, for inspirational, educative, cultural, and recreative purposes.

In addition, national parks can be used as laboratories for research and demonstrate ways to re-establish it´s original, natural state. 1). A low mountain range with an almost never-ending forest area characterizes the Hunsrück and differentiates the area from the surrounding best wine-growing regions of Germany: the Moselle, the Rhine, the Nahe and the Saar. The Federal Agency for Nature Conservation already counts the Hunsrück as a "hot spot region for biodiversity" [START_REF] Ackermann | Identifizierung der Hotspots der Biologischen Vielfalt in Deutschland[END_REF]. Therefore, visitors can especially experience one thing: forest and wilderness.

Research plays, in accordance with the concept of the national park, an important role in the park. Nature conservation, forest development and ecology as well as local added value and the acceptance of the national park by the regional population are examined.

Data Sources

In national park monitoring, software systems are intelligent pencils to manage, analyse and visualize the environmental data coming from lots of different sources.

Therefore, before discussing environmental software systems, we will have a deeper view to the data collected in national park monitoring and management. Figure 2 gives an overview to relevant subject fields in the national park monitoring process. Thereby, the provenience of the data is as manifold as the fields covered in the monitoring process. International (e.g. earth observation), national (e.g. hydrologic network) and federal (e.g. air quality measurements) responsibility is found as well as NGO databases, crowd sourcing applications or dedicated field surveys in R&Dactivities of single research groups.

On the other hand, looking at the data sources, NP management is not as diverse as it is in the field of environmental monitoring. Only limited new data is collected (e.g. by Ranger activities in park supervision). In this application domain, tasks are focused on the documentation of ongoing activities including the characterization of the collected data sets, on presentation of derived information e.g. for educational activities and on mapping or Web applications. Figure 3 gives an idea about some activities in NP -management.

Data Quality Aspects

The data quality in data sets or in information systems becomes more and more important [START_REF] Redman | Data Quality -The Field Guide[END_REF]. The quality of data is usually described by multiple dimensions, e.g. accuracy, completeness, consistency, relevance, accessibility and timeliness. Quality defects during initial data acquisition lead to a huge additional effort to resolve. Practical experience showed that essential quality standards can easily be fulfilled by help of guidelines for data collection. Hence, corresponding guidelines should be worked out before the beginning of the collection, especially in long term monitoring programs. Additionally it must be defined how the data will be rechecked and actualised continuously.

Today, in national or federal monitoring programs, such as e.g. air quality monitoring, data quality aspects are addressed and appropriate actions are implemented [START_REF]Determination and Evaluation of Ambient Air Quality -Manual of Ambient Air Monitoring in Germany[END_REF]. On the other hand, with the installation of ad-hoc-networks or with some field surveys done by different research groups, aspects of data quality and representativeness often are not intensely discussed. In the worst case this can lead to data sets which are not usable in other context than the one focused on in the dedicated research. Because of the high diversity of the data in NP monitoring and management, there is no generic software available, dealing with all the different data in one shell. Beside some typical standard tools as e.g. Geographic Information Systems, Database Management Systems or even Spreadsheet Software, highly specialized software is in use to support the requirements of a national park monitoring. Due to the high importance of the spatial information of the data in environmental monitoring, the ability to store and to deal with this kind of information is common to all software systems used in this context. As shown in figure 4, there are a lot of individual software systems in use in the NP Hunsrück-Hochwald. Below, you will find a short description of these software systems. Because of the individual needs of the different national parks, the list below is without claim of completeness.

Standard Software

There are some standard software systems used in environmental monitoring programs in general. Below, some of them, which are in use in the NP Hunsrück-Hochwald, are listed: functionality and the familiarity of the user with the system, GIS are in use for documentation, analyzing and mapping of mainly vector data as e.g. Biotopes, Permanent Observation Areas (e.g. matured forest cells) or the Forest Inventory. In addition, the use of standardized display-and download services (e.g. WMS, WFS, WCS) offered by third party data provider (e.g. land surveying agencies) via spatial data infrastructures (SDI) is a further important functionality.

• Image Processing Software: Processing of images using mathematical operations by using any form of signal processing for which the input is an image, a series of images, or a video, or a photograph. In NP-monitoring, main sources for image data are Earth Observation (Single spectral-/ Multi spectral images in different spatial resolutions), Photo Traps (daylight or infrared photographs), Pass by imagery (daylight photographs), or even earth borne change detection photography systems (e.g. 360° recording).

• Database Management System (DBMS): A DBMS is the backbone in NP data management. If appropriately designed, it is able to integrate most of the different data gathered. In addition, the software can interact with further tools in use, such as GIS, statistical packages or content management systems.

• Statistical Packages: As specialized software for analysis in statistics, these tools are widely used to analyze and visualize e.g. sensor data regarding trends, in change detection analysis (e.g. climate change) but also in data quality management. Further applications are e.g. the estimation of population density of wildlife [START_REF] Ebert | Estimating wild boar Sus scrofa population size using faecal DNA and capture-recapture modelling[END_REF] or, with Geostatistics, focusing on spatial or spatiotemporal datasets.

• Spreadsheet Software: Widely used in field data collection, such as mapping of species including endangered or pest organisms, or as data sheets in vegetation or soil mapping.

• Content Management Systems (CMS): Software that supports the creation and modification of digital content, mainly used in Web content management to publish national park activities for the public, but also as Intranet for the staff. It is often used to support multiple users working in a collaborative environment.

• 3D-Modeling Software: 3D modeling is the process of developing a mathematical representation of any three-dimensional surface of an object. With the event of Roomscale VR applications or interactive App guides, 3D -modeling starts it´s career even in national parks. Especially cyber physical systems are now dealing with tourism promotion activities. In our case, some developments combining the recent earth´s surface derived from laser scanning data with reconstructed ancient roman and celtic sites are under way and promoted because of their innovative aspects.

• Geotechnical Software: Because of the specific geomorphologic situation and the presence of endangered biotopes as peat bogs, 3D soil-and drilling profiles but al-so data coming from Palynology analyses have to be documented and analyzed in our reference national park. Specialized, commercial of the shelf software is supporting the scientists in this field of research.

Individual Software

Beside the standard software packages, there are some individual software and dedicated information systems in the monitoring and management of the NP Hunsrück-Hochwald in use. Configured and developed for the special needs in individual parks, each park will have its own individual software, depending on the natural resources (e.g. forest, grassland, maritime) and/or on the focus of the development of the park.

• Documentation System of R&D-Activities: In order to ensure central and efficient access to the literature and data of the NP for all scientists from the respective institutions and for a long-lasting period, in the NP Hunsrück-Hochwald a "research server" was established. The system serves future researchers as a scientific information portal. The goal is to avoid expensive, redundant data acquisition as well as time-consuming information retrieval for the individual teams. Furthermore, research becomes more transparent and allows better use of possible synergistic effects [START_REF] Fischer-Stabel | Scientific Research Documentation -An Information Server for the National Park Hunsrück-Hochwald[END_REF]. The system of the NP Hunsrück-Hochwald is accessible under: http://fs.nlphh.de/

• Pest Monitoring System: Because of its special forest structure, the national park Hunsrück-Hochwald must be monitored regarding bark beetles calamities (mainly Ips typographus), to avoid significant damages in forests neighboring the park. This is done with a specific monitoring system collecting activity data of the beetles in traps, modeling the evolution of the population and resulting in an estimation of the damage risk for the forest. If there is a high damage risk for the forest, the NP administration has to take action to protect the forest outside the park. Further information can be found in [START_REF]Biotic Risks and Climate Change in Forests. Proceedings of the IUFRO Working Party 7.03.10 Methodology of Forest Insect and Disease Survey in Central Europe[END_REF]. The system is available under: http://ifffriskanalyses.boku.ac.at/typo3/index.php?id=74

• Dedicated Apps: With the intensive use of smartphones and field clients, there are dozens of Apps in use in NP-monitoring and management [START_REF] Newman | The future of citizen science: emerging technologies and shifting paradigms[END_REF]. Combining the ability to collect position information and link it with attribute data, Apps are supporting the rangers in park supervision, the collection of species data or are in use in crowd sourcing applications, e.g. monitoring the spread of invasive organisms. An example in the field of species data collection for the NP Hunsrück-Hochwald can be found under http://www.buergerschaffenwissen.de/projekt/artenfinderrheinland-pfalz.

• Laser Scanning Software: Airborne Laser Scanning (ALS) data acquisitions are providing the scientific community with very high resolution 3D -data regarding the earth´s surface. Starting with the raw point cloud data, specialized software tools are in use to derive high resolution elevation-but also surface models serving as input for many applications (e.g. vegetation analysis, erosion processes, micromorphological studies). In addition, the latter provide suitable information for 3D modeling applications.

• Camera Trapping Software: Camera trapping is increasingly becoming an important tool in ecological research. Capture-recapture surveys or the simple documentation of wildlife are nowadays common projects in national parks, collecting thousands of pictures. However, the organization of large collections of multimedia files and especially the efficient search for subsets of data is a challenging task. Camera trapping software makes classifying camera trap photos quick and easy, keeps track of camera trap, camera and species data and supports the management and retrieval of the photographs [START_REF] Bubnicki | trapper: an open source webbased application to manage camera trapping projects[END_REF][START_REF] Smeedley | Snoopy. Portable software for capture-recapture surveys[END_REF].

• Forest Meteorology and Climate Change Information System: This information system is a cross-section task with the emphasis on data management, information, consulting, advanced training and contacts at the different levels of expertise. The central product of the climate change information system is a publicly accessible web portal, which is intended to appeal to a broad public. The user is offered detailed information on climate change and possible consequences for the Rhineland-Palatinate but also for the National Park. Further Information to the information system can be found under http://www.klimawandel-rlp.de/ or www.am.rlp.de/

• Immission Monitoring Network and Information System: Since 1978, the agency for environment Rhineland-Palatinate has been operating the Central Immission Monitoring Network (ZIMEN) for Rhineland-Palatinate on behalf of the Ministry of Environment, Agriculture, Food, Viticulture and Forestry. This consists of 27 air measuring stations, which are telemetrically supervised by a measuring network in Mainz. It has the task to determine the long-term development of the air pollutants in cities and forest areas of the country by continuous measurements, in order to achieve a high protection level for human health and the environment [START_REF]Atmospheric Pollutants in Forest Areas: Their Deposition and Interception[END_REF][START_REF]Determination and Evaluation of Ambient Air Quality -Manual of Ambient Air Monitoring in Germany[END_REF]. (www.luft-rlp.de/ )

• Hydrologic Monitoring Network and Information System: On the one hand, the system is providing a quantitative measurement service on surface waters, precipitation and groundwater. Quantitative management of surface waters, management of groundwater and the protection of springs are tasks supported by the information system. Especially within, and in the surroundings of the NP Hunsrück-Hochwald, with its mineral springs and spa waters, there is a special focus on hydrologic monitoring. (www.quellenatlas.rlp.de/ , geoportal-wasser.rlp.de/ )

• Tools for Communication, Civic Participation and local Governance: Democracy relies on citizens participating in decision making, even or especially in national park regions with restricted use in landscape. Web 2.0 technology is enabling citizens to make their voices heard in new and innovative ways, important for civic participation and the decision making process in regional development. Some product examples can be found under [13,[START_REF]Software in civic participation[END_REF].

Summary and Outlook

Types of software systems used in NP monitoring are as manifold as the fields of scientific-and management activities are occuring in a park.

In general, software systems in NP monitoring and management are mostly highly adopted to the individual needs of a NP. This depends on specific landscape, features, or the research focus in the park, to name but a few. The software solutions are realized as a customization of standard software products, or, as individual software packages, designed and developed according to the special requirements of the fields of activity in a dedicated park. The case described in the paper was the NP Hunsrück-Hochwald (Germany).

In addition, the heterogeneity in software and information systems used in parks is strongly linked to the evolution process in environmental monitoring: Often, monitoring systems as e.g. air quality, hydrologic monitoring or forest inventory are implemented decades before the government decided, to install a national park in the region. Keeping this in mind, a mixture between historic and recently designed sensor networks and software systems is available. Especially with view to the long-term perspective, it is still difficult today, to combine and use all the information available in an integrated environmental monitoring in the park.

Regarding the future developments, it is the opinion of the author that there will be no significant changes: the heterogeneity of the data and software used will be similar as it was in the past or it is recently.

But, especially because of the long-lasting perspective in NP research and management, one important action the NP administration should focus on: a proper documentation of methods, datasets, publications and information systems targeting the NP, to make monitoring and management activities transparent, accessible and ready for future re-use.

Fig. 1 .

 1 Fig. 1. Orientation Map of the National Park Hunsrück-Hochwald."To Leave Nature Nature" -this principle shall be realized in the most recent national park in Germany. After several years of planning, the NP Hunsrück-Hochwald was officially opened in May 2015. It is a part of the nature park Saar-Hunsrück and comprises approximately 10,000 hectares, or more explicitly, 5% of the total area. The National Park Hunsrück-Hochwald is located in the southwest Germany and connects the federal states of Rhineland-Palatinate and Saarland (see fig.1). A low mountain range with an almost never-ending forest area characterizes the Hunsrück and differentiates the area from the surrounding best wine-growing regions of Germany: the Moselle, the Rhine, the Nahe and the Saar. The Federal Agency for Nature Conservation already counts the Hunsrück as a "hot spot region for biodiversity"[START_REF] Ackermann | Identifizierung der Hotspots der Biologischen Vielfalt in Deutschland[END_REF]. Therefore, visitors can especially experience one thing: forest and wilderness.

Fig. 2 .

 2 Fig. 2. Fields of Interest in National Park Monitoring -Overview.

Fig. 3 .

 3 Fig. 3. Fields of Activity in NP -Management.

3 Software

 3 Systems in NP Monitoring and Management

Fig. 4 .

 4 Fig. 4. Software in use in Monitoring and Management of the NP Hunsrück -Hochwald

•

  Geographic Information Systems (GIS): GIS are systems designed to capture, store, manipulate, analyze, manage, and present spatial or geographic data. Different technologies and methods are the foundation. Depending on the underlying


Eric Braun
email: eric.braun2@kit.edu|clemens.duepmeier@kit.edu

Clemens Düpmeier

Stefan Mirbach
email: mirbach@kobus-partner.com|lang@kobus-partner.com

Ulrich Lang

3D Volume Visualization of Environmental Data in the Web

Keywords: Environmental information systems, 3D volume visualization, WebGL, Lake Constance

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

Introduction

The demand for dynamic visualizations of data in the Web grows with the popularity of mobile platforms and many solutions, especially for the visualization of charts and maps, already exist. The WebIS group at the KIT (Karlsruhe Institute of Technology) works on a modern microservice based visualization framework (FlexVis) that is modular, highly configurable and allows the utilization of state-of-the-art technology for implementing reusable and easy to use interactive visualization components which are embeddable into web pages. A new research focus refers to implementing reusable 3D volume visualization components for FlexVis to display complex multidimensional environmental data in the Web. In cooperation with kup (Ingenieurgesellschaft Kobus and Partner GmbH) the development of such 3D data visualizations for displaying the propagation of chemical substances (e.g. sodium chloride, phosphate...) in Lake Constance ("Bodensee") is explored. Within the existing Web based information system BodenseeOnline one and two dimensional data visualizations of the substance flow in Lake Constance are already implemented by kup for the LUBW (State Office for the Environment, Measurements and Nature Conservation of the Federal State of Baden-Württemberg). However, since substance flows in a lake essentially depend on three dimensions the new 3D visualization already proves that 3D volume visualizations can provide more information to users of Web based applications like Boden-seeOnline.

In this paper, the concept of the 3D volume visualization component will be described in the context of the BodenseeOnline application as one use case. Also, basic concepts of the overall FlexVis framework for data visualization [START_REF] Braun | Generic Web Framework for Environmental Data Visualization[END_REF] and the integration of the 3D visualization component into this framework will be described. The paper will show that users of web based information systems can benefit from more complex multidimensional visualizations which can be implemented with modern web technologies. Additionally, the paper will show that the usage of the FlexVis framework provides many advantages for the implementation of complex web based information systems.

BodenseeOnline

Lake Constance is a transboundary lake situated partly in Germany, Switzerland and Austria and it is an important drinking water reservoir. More than 4 million people get their water at home from the lake without considerable treatment. Beside this, the lake is also used for a fishery, recreational purposes and tourism. For improved monitoring of potential risks which can be caused by emissions into the lake (e.g. from industrialized areas or the intensive use of agriculture around the lake), the environmental decision support and information system BodenseeOnline was developed in an interdisciplinary research project from 2005 to 2008 by five project partners including kup. Using three-dimensional numerical models, the distribution of hydrophysical and biochemical parameters in the lake is simulated on a daily basis using up to date data from measurement stations around the lake. Additionally, results from weather forecasts are used to provide a forecast for the next 78 hours. Measurement data from a wide variety of meteorological and hydrological data are gathered and stored in a database. The results from the simulations as well as the measurement data are visualized on a website and represent an important basis for decision making in case of accidents, disturbances or extreme events in or around the lake for local water authorities, disaster management and drinking water supply companies. The system is currently monitored, maintained and developed further by kup. Currently, the visualization of the three-dimensional model data is based on an interactive map application which allows the display of time series, profiles and longitudinal as well as transverse sections of data at arbitrary, user-defined positions in the lake. Additionally, the simulated movement of the flow field of substances can be visualized using animated vectors. The propagation of substances in the flow field can be calculated using a particle tracking algorithm. These 1D and 2D visualizations offer extensive possibilities for data analysis and are sufficient for most use cases, like the evolution of water quality parameters at water extraction sites, the vertical distri-bution of critical parameters such as dissolved oxygen and the movement of substances or objects at the water surface. However, in case of the 3D propagation of local plumes of substances the current methods of 1D and 2D visualization are of limited suitability to capture the dispersion in all three directions. Typical examples are the dispersal of wastewater plumes or the inflow of sediments during flood events, which can form complex patterns of propagation in different depths of water in the lake. Figure 1 shows an example of the latter by visualizing the suspended sediment concentrations at 140 m water depth in the lake during a flood event in the river Rhine. Not unlike an avalanche, the denser riverine water forms a turbidity current, flowing along the lake bottom into deeper regions. The limitations of a 2D visualization in capturing the propagation and extent of the current in the lake are clearly visible. In these cases, a 3D visualization could offer a much more convenient and intuitive analysis of the plume propagation on a qualitative and, maybe with certain limitations, on a quantitative basis.

The users to be reached by this application are mainly:

• sailors who are interested in the wind speed at the surface of the lake • fishermen who use information of wind speed and the height of waves for their advantage • divers who are looking for water flow and water temperature information in several depths • bathers who are also interested in the water temperature (mainly at the surface) • experts who want to track more complex information about the lake (e.g. suspended sediment concentration) With the current application, these users are provided with a limited view on the data because of the missing 3D visualizations. However, especially divers and expert users are interested in more detailed data since they want to see a full 3D picture of the lake. The next chapters describe enhanced types of visualization for those users.

3D Volume Visualization

One technique to visualize 3D volumes (e.g. the propagation of substances in a lake) is known from the medical area and is called volume visualization. It is used to visualize MRI scans, for example. However, there are many more use cases since a volume visualization only requires a 3D volume containing spatial information, e.g. density information. This could be the anatomy of a human body (for MRI scans) or the density of different substances that are present in a lake. The rendering of such visualizations is commonly accelerated using a graphics adapter.

Fig. 2. Ray marching and alpha blending

To visualize 3D information on a 2D screen, a ray marching algorithm can be used. The idea of ray marching is that for each pixel a ray is cast through the volume, starting at the camera. The values hit by this ray are captured as a specific step size along the ray. These different values can be translated into a color and the different colors can be accumulated by the graphics card using alpha blending, which is the combination of multiple colors with a specific transparency. Figure 2 shows this technique. The step size in Figure 2 is approximately equal to the length of one square. Therefore, the ray collects the colors of six squares and adds them up to receive a resulting color.

This can be implemented by drawing a cube in the scene which has the same size as the data volume itself. Afterwards, this cube can be shaded with custom vertex and fragment shaders to visualize the volume. The performance depends on the size of the volume and the resolution with which the ray samples the volume (i.e. step size).

Volume visualizations on desktop computers are typically implemented by using the OpenGL API. As for the Web, the WebGL API, which is supported by modern browsers on a decent computer, can be used. It allows the browser to directly render scenes on the graphics card. The current WebGL version is 1.0 and it implements the OpenGL ES 2.0 [START_REF]OpenGL ES 2.X[END_REF] features. This OpenGL version was released in March 2007 and it lacks various features of modern graphics adapters. One very important feature for volume visualization is 3D texture support which is unfortunately not included in WebGL 1.0. Therefore, the implementation of such visualizations for the Web has to simulate 3D textures with 2D textures which costs a lot of performance. Figure 3 displays how a 3D texture can be unpacked into a 2D texture. The 3D texture with the size of X * Y * Z is converted into Z different slices of 2D textures with the size of X * Y. This workaround adds a lot of complexity to the fragment shader but it is necessary until WebGL 2.0 is released. More details about the implementation of volume visualization in WebGL 2.0 can be found in the bachelor thesis by Michael Becher [START_REF] Becher | Interactive volume visualization with WebGl[END_REF].

Lake Constance Volume Visualization

Volume visualization as described in the previous chapter can now be applied to a volume that represents a specific substance present in Lake Constance, e.g. the density of sodium chloride (salt) in the water. The challenge is to determine a good mapping from values to specific colors. If the visualization only uses a grayscale color mode, the values for each step will be normalized between 0 and 1 and the resulting color c in the RGB color scheme would be rgb(c, c, c). The color scheme can be improved by the creation of a non-linear scaling which matches the human perception more closely. A screenshot of this color mapping for salt in Lake Constance is depicted in figure 4.

Fig. 4. Densities of sodium chloride in Lake Constance using the grayscale mode

A second approach is to use different color ranges for different density ranges. As shown in figure 5, the lake is divided into 3 colors. The area with the highest salinity is shown in green, medium salinity is colored in blue, and low salinity is colored in red. The comparison between both screenshots shows that different colors provide much more options to show the distribution in the volume.

Fig. 5. Different densities of salt in Lake Constance

This second approach allows the user to perceive more details from the visualization, especially if the values are not evenly distributed between the extremes or if there exist clusters of values. Figure 6 A feature of the 3D visualization component currently missing is some kind of orientation help. The data in our example have geographical meaning and users that know the structure of the Lake Constance should be able to see this structure at first glance. A possible enhancement is an option for the user to enable marks that show the nearby cities or villages. With additional markers, for example Constance and Lindau which are two cities near the lake, the user can immediately recognize familiar points of orientation. A second method which could help with spatial orientation is to add a compass of some sort which shows markers for north, south, east and west. These changes can easily be added to the current prototype and this will be the next step to improve the software. Additionally, in order to help the user select appropriate mappings, future user studies can be conducted to create a more intuitive and user friendly interface.

The prototype presented in this chapter can be integrated in the FlexVis framework for data visualization as an additional visualization type. The procedure for achieving this integration will be discussed in the next section.

Fig. 7. Complete user interface Integration of the Visualization in FlexVis

The FlexVis framework for data visualization in the Web can be used to provide web page creators the opportunity to add highly complex visualization components (such as the volume visualization) to web pages without the need to write any code. Instead, the web page creator can add the volume visualization component to the web page by configuration only. Such a configuration allows the user to change the features that the visualization provides, the behavior of the different features, the style of the visualization, as well as the selection of data sources which determine the data behind the volume visualization.

The data model of the FlexVis framework stores configuration information needed for a visualization in three separate services: a template, a data source and a visualization instance service. The most important configuration information for integrating the new 3D component into FlexVis is the definition of a new visualization type template for the new 3D visualization type. It contains a URL to an HTML5 web component that contains the implementation of the new component. This link allows the FlexVis framework to load the implementation of the 3D component into the web browser. The template also contains formal descriptions of configuration parameters which are used in the source code and will be customizable by a web page creator while embedding the component. Once defined, a template can be instantiated indefinitely on arbitrary web pages with different parameters each time. Finally, the visualization template also describes what parameters have to be defined by a web page creator when instantiating a visualization so that the framework can load data into the component e.g. from external data sources. In its simplest form, the location of data can be defined as simple REST URL that returns a JSON file when the components get instantiated.

Fig. 8. Web user interface to configure a template

After a visualization template is defined for the 3D component, one or more instances of the template can be created which contain, beside a link to the template, concrete parameter configurations including the parametrization for data loading for this particular instance. It is important to note that the instance configuration should connect the right data source to the template, e.g. the data model of the data returned by the data source should match the data model used in the web component implementation. If this requirement is fulfilled, the web component should be able to load the data based on the given configuration. The instance can be further customized according to the other configuration parameters that the template features. For displaying a visualization instance on a web page, only the tag of the FlexVis wrapper component with a data parameter specifying the instance id of the visualization instance has to be specified. The wrapper component itself will then load the code of the component and configure it accordingly to the instance parameter configuration.

To illustrate these steps the next figures will show how a new visualization template and visualization instance can be configured. Figure 8 shows the configuration of the template for the new 3D visualization component. The component URL points to the main file that defines the web component for the volume visualization. This file has to be accessible by the frontend browser. The tag defines the name of the web component which is important to embed the visualization into a web page. Finally, the parameters section contains different configuration parameters that are used in the source code. In our example, the configuration allows the settings panel and the color panel to be shown or hidden, the camera control can be enabled and three further parameters control the rendering behavior of the visualization (stepSize, maxSteps, alphaFactor).

Fig. 9. Web user interface to configure a visualization instance

The data source for the volume visualization is a URL that points to a volumetric data set to be loaded. The next section discusses the format of this data set. The resulting visualization instance (Figure 9) can be customized according to the template parameters. The instance can be embedded in any web page by adding the FlexVis web component and specifying the ID of the created visualization instance.

The main advantage of the FlexVis framework is that only the creation of the template requires some programming knowledge but the rest of the parts, e.g. the data source and the visualization instance, can be created and edited by configuration only. This section illustrates that even quite complex visualizations can be integrated in the framework and do not require any programming knowledge once the appropriate template is registered in the framework.

Data Management for 3D Volumes

The 3D volumes of Lake Constance used in the prototype for this paper are provided by a backend service that stores data in NetCDF files [START_REF]Unidata[END_REF]. The exchange format between the service and the visualization is a JSON object that includes a few parameters and the data itself as a three dimensional array. The client visualization converts the array into a JavaScript Typed Array. Figure 10 shows an overview of the used JSON format. The data are serialized as a flattened three dimensional array. The dimensions and interval properties are metadata that describe the size of the data and the range that the values describing the measured substance lie in.

{

"dimensions": { "width": 673, "height": 230, "depth": 57 }, "interval": [0, 0.02] "data": ... } Fig. 10. JSON object for the phosphate data set Data management can still be improved in different areas:

• The data sent to the frontend can be reduced in size by varying the resolution of the data if the user zooms out of the scene and vice versa. This can be achieved by precomputing the volume in different resolutions and selecting the appropriate resolution depending on the zoom level in the frontend. The disadvantage of this change is the higher storage need which scales with the amount of different precomputed resolutions. • A second way to reduce the size of the data sent to the frontend is to transmit only parts of the whole volume depending on the region the user wants to see. In this case the server has to precompute at least a second resolution that has more detail. This resolution will only be send partially depending on the selection the user makes.

• The backend and both previous improvements can be further improved by storing data in an appropriate database or data structure. This decreases the access time to retrieve the desired data and speeds up queries that only need a part of a volume (as described in the previous improvement). Additionally, the data will be preprocessed before inserting it into the database or data structure to eliminate any processing at runtime. This preprocessing can include handling of missing data and normalizing data. These features are not yet included in the prototype but can be extended in the future without changing core concepts of the architecture.

Evaluation

After a detailed description of the different aspects of the volume visualization concept, this section evaluates the web application. The main advantage of the new form of visualization is that BodenseeOnline users who are interested in 3D data sets can profit from new insights on the data. Especially divers and expert users, as mentioned in the second section of this article, can use the full advantage of 3D information. Divers can have a look at the water temperature for all depths at the desired diving location. They can immediately see the differences in temperature in a specific volume they are considering to dive in. This is an improvement in contrast to the 1D/2D visualization of the existing web application. Furthermore, expert users benefit from new 3D visualizations of different substances in the water. Figure 11 shows that a simple 3D visualization of the temperature reveals not only information about the temperature itself but also information about the flow of the water which is correlated with its temperature.

A second advantage of the visualization component is the customizability of colors. Users can define their own color mapping to customize the visualization to their needs. A user with color blindness for example can select different colors in order to get better contrast. Average users however do obviously not want to customize the colors in such a complex manner that the current implementation allows them to. Therefore, such users can be provided with some predefined color settings that are easy to understand. An expert on the other hand might want to operate on the full color mapping interface.

The evaluation shows that the requirements for the 3D visualization are met and that new insights on the volume data can be acquired. In order to further enhance the visualization, user studies can be conducted that lead to more specific requirements especially for the color mapping interface.

Conclusion and Outlook

A volume visualization constitutes a complex example of a visualization in the Web. However, its implementation for BodenseeOnline shows that even complex visualizations can be included as easy to use interactive web components into the FlexVis framework to provide a simple configurable interface for web page creators who want to add such visualizations to their web page but do not have the skills to develop a visualization on their own. The different configuration options mentioned in the previous section show that the volume visualization component can help the web page creator to visualize any kind of 3D volumes (not only substance flows in Lake Constance). This can be helpful in many environmental fields. For example, the tracking of substances in water and in air can be visualized in a new way providing 3D insight into the data that cannot be achieved with one or two dimensional visualizations. The flexibility that the visualization framework provides allows the creation of easy to use visualizations for the general public but also rich visualizations with many features for expert users. The only downside of volume visualization is that the client device, which renders the visualization, requires access to an appropriate GPU chip and that the backend has to manage the volumetric data accordingly. However, the number of devices that have no GPU chips has decreased substantially over the past few years. Even most mobile devices have a graphics card that can render visual-izations presented in this paper. Furthermore, most of the browsers nowadays support WebGL [START_REF]WebGL -3D Canvas graphics[END_REF].

In the future, volume visualization can be used in many different areas for the visualization of environmental data. As a short term goal, other water bodies can be visualized. As a long term goal, the visualization can be used to show the propagation and the density of pollutants in the air. The scenario is similar to the previous one but the amount of data can be much bigger since lakes or rivers can have much smaller volumes than a volume in the air. Thus, visualizations that cover the air of a whole city can raise new data management challenges and demand big data solutions and smart services for data management.

A further future enhancement could lie in the animation of a volume visualization. Such an animation can display the change of the volume over time. Again, this feature raises new data management challenges because the amount of data increases tremendously. Such an animation also raises new visualization challenges because the animation has to be visualized which means that the graphics card has to compute an image for every frame, including those frames that lie between two volumes that were captured consecutively.

Finally, the user interface consisting of the settings panel, color panel and main visualization can be enhanced in many ways. A more space-saving design can help the user to have more space on the screen for the actual visualization and a common theme for both panels gives the application an enhanced appearance.

Fig. 1 .

 1 Fig. 1. 2D slice at 140m water depth visualizing suspended sediment concentration

Fig. 3 .

 3 Fig. 3. Transformation of a 3D texture into a 2D texture

  shows the color settings of the previous screenshot. The gray lines show the distribution of the different values between the minimal value (left border of the rectangle) and the maximal value (right border). The distribu-tion has one cluster which was broken down into three different colors to visualize the different parts of the distribution in a clear way. The height of the color line indicates the brightness of the color.

Fig. 6 .

 6 Fig. 6. Color mapping and distribution of values

Fig. 11 .

 11 Fig. 11. Visualization of a small interval of temperature values in Lake Constance


Katharina Schleidt
email: kathi@datacove.eu

Evolution of Environmental Information Models Reusable properties bound to a persistent URI

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

Introduction

Access to environmental data is necessary for environmental research and control. Due to the complexity of environmental concerns, this task often requires the reuse of data originating from various sources. Triggered by this requirement, organizations from various environmental domains have started initiatives aimed at the provision of standardized access to environmental data; standardized data models for the exchange of various types of environmental data are now available, together with the required service definitions for discovery and access. These developments should guarantee easy access to standardized and harmonized environmental data. However, many standardized data models cover only common concepts pertaining to a wide range of usage areas; thematic extensions are required for the support of specific community's requirements. As the thematic extensions develop, domains with similar requirements create parallel extensions; while these may be semantically identical, this fact cannot be simply verified [START_REF] Tóth | A Conceptual Model for Developing Interoperability Specifications in Spatial Data Infra-structures[END_REF]. Thus, after much effort, we find ourselves dangerously close to the starting point.

After discussions with various stakeholder representatives, the conclusion was reached that the most efficient mechanism to allow for flexible extension in a complex environment as described would be the introduction of reusable properties, such as commonly used within semantic technologies. An overview of implementation options for reusable properties is provided, together with an analysis of their viability.

Background and State of the Art

Various initiatives have been launched in the last years aimed at providing easy access to relevant data stemming from various environmental sub-domains through the standardization of data models and service specifications. While data standards are provided for core concepts, there is always a need to extend these concepts in order to support new or alternative requirements.

Background

In this paper, we use the European INSPIRE Initiative [START_REF] Schleidt | Evolution of Environmental Information Models[END_REF] as an illustrative example, and thus focus on the first approach. This trend has in turn led to the creation of various standards beyond the classical spatial domain, including data and service standards covering the provision of measurement data, be they individual observations, time-series or multidimensional coverages.

2.2

State of the Art

The technological basis both for the creation of the underlying data models defining the structure of the data as well as the formats and technologies used for data provision varies across initiatives; the following approaches have been identified:

Methodology

Based on an analysis of existing approaches as well as a workshop ISESS 2015, the requirements for harmonized data model extension were analyzed; URI-Properties, defined as reusable properties bound to a persistent Uniform Resource Identifier (URI) [START_REF] Schleidt | Evolution of Environmental Information Models[END_REF], were identified as a potential solution. A set of requirements that must be fulfilled by URI-Properties was defined:

1. A URI-Property must be uniquely identifiable through an URI 2. The datatype of a URI-Property must be tightly coupled with its definition 3. The semantics of a URI-Property must be tightly coupled with its definition 4. A URI-Property must be persistent. We shall define persistence in analog manner to the definition used for Global Unique Identifiers (GUIDs) referencing data: A URI-Property may not be redefined with different semantics while retaining the same URI; while the definition of a URI-Property may at some point no longer be available, the reuse of the URI is not allowed.

The following sections describe the viability of the options identified for the provision of reusable properties within UML, as well as their conformance to the requirements defined above.

Data Types

Defining the semantics of data types via derivation hierarchies is state-of-the art. However, pushing the complexity of semantics into data type definition could cause difficulties, as a complex derivation hierarchy must be created and maintained; should this approach be pursued methods of coupling required data types with a formal ontology, i.e. formulated in OWL, should be explored [START_REF] Janssen | A database for integrated assessment of European agricultural systems[END_REF]. In addition, while base semantics are defined, the usage of these concepts as data types allows for definition of class attributes using the same data type but with subtly different meanings. Such differentiation could be as simple as the provision of a preferred concept together with an alternative concept, with no additional information on the subtle difference between these two concepts. Finally, as XML Schema doesn't currently support multiple inheritance, while the semantics stemming from the derivation hierarchy are available within the UML data model, no indication of this additional information is available within the XML Schema.

Interfaces

Interfaces are state of the art for provision of reusable attributes. However we encounter problems due to the fact that XML doesn't support multiple inheritance. While GML MIXIN overcomes this shortcoming by copying attributes and associations (copy down), this technique provides no information as to the source of these attributes and associations in the final XML Schema. Further, the utilization of interfaces for the representation of reusable properties would break a great deal of the visual clarity of UML; the properties provided by the interface are not visible in the class inheriting from the interface, nor for classes derived from this class. Thus, while the benefits of reusable properties would be valuable, the cost for both the creation as well as the interpretation of the model would be a great deal higher than with normal methodologies.

MOF Level Adjustment of UML

Initially, the approach of defining reusable URI-Properties at the Meta Object Facility (MOF) level seemed the most promising, as this would integrate the concept at the UML definition level. However, this proved not to be possible, as both attributes and associations have a minimal cardinality of 1 in the MOF definition. Thus a property cannot be defined without it being directly used.

3.4

Stereotypes

Stereotypes are well suited for the definition of reusable URI-Properties. Through the tight binding of the URI-Property to the URI, the semantics of the URI-Property can be provided through an external ontology referencing this URI. This URI is visible within the XML Schema defining the URI-Property via the appinfo element, allowing applications encountering this property to resolve the URI for more information on this attribute. In the final schema, the element name and data type are automatically supplied through the element reference. The schema encoding rules are in alignment with the requirements of the underlying GML and ISO standards, and should be easy to implement. The only problems currently identified with to this solution pertain to its integration in UML development tools. At present the use of URI-Properties requires discipline from the data modelers, as the constraints on URI-Properties are not checked by the UML tools, and thus inconsistencies will only be flagged during the schema generation process. In addition, registries of reusable URI-Properties would need to be developed and ideally integrated within the UML tools.

A final advantage of the use of URI-Properties is the fact that the definition is agnostic of the final serialization form. While well suited to serialization in XML, the logic behind the URI-Properties is also in alignment with the requirements ensuing from semantic serialization technologies such as RDF.

Analysis against requirements

The following tables shows the approaches analyzed against the individual requirements identified.

~ ~  Interfaces  ~ ~  MOF Adjustment     Stereotypes    

Stereotype Solution

Based on the insights presented above, UML Stereotypes were selected for the implementation of reusable URI-Properties is the use of UML Stereotypes. In the following section this is illustrated through the creation of the URIProp Stereotype.

4.1

UML Example

The URIProp stereotype, defined on both attributes and associations, adds the following tags to the attributes and associations it is applied to:

• URI: a unique URI for this property • Name: the name of the attribute or association role • Datatype: the datatype of the attribute or of the target of the association

In addition, the following three constraints are added to the URIProp stereotype:

• Property unique per class: A URI property can only occur once per class • Name aligned: The attribute name must be the same as the Name tag of the attribute, which must in turn be the same as that stored for the specified URI Property under the referenced URI • Datatype aligned: The attribute datatype must be the same as the Datatype tag of the attribute, which must in turn be the same as that stored for the specified URI Property under the referenced URI For the definition of reusable URI-Properties, the stereotype must first be applied to the definition of the URI-Property, be it for an attribute or for an association role. In the example below, we define two URI-Properties:

• euStationName: this URI-Property provides an attribute named euStationName referencing the data type CharacterString. The following diagram shows the UML Encoding of the URI-Properties:

Fig. 1. Definition of URI-Properties using Stereotypes

As part of the definition process for URI-Properties, the Tagged Values from the URIProp stereotype must be provided. This stereotype must then be added to the class attributes or associations that are utilizing an URI-Property as shown in the following diagrams.

Fig. 3. Usage of association URI-Properties using Stereotypes

The same tagged values as defined above for the definition of the URI-Properties must also be provided for each usage instance. The constraints defined for URI-Properties must be complied with, assuring alignment to the original URI-Property definition.

Serialization

While the schema encoding rules for data types and interfaces are specified in the GML and ISO standards, we must first define encoding rules for the use the URIProp Stereotype.

For the definition of URI-Properties, we will make use of the XML Schema option of defining an element by reference. The URI defining the URI property is provided within the appinfo section of the annotation element.

The element declarations for the URI-Properties pertaining to attributes are as follows: <xs:element name="euStationName" type="xs:string"> <xs:annotation> Once the URI-Property has been defined, it can then be referenced from the XML Schemas reusing this property as follows: <xs:element ref="st:euStationName"/>

The same pattern can also be used pertaining to associations: <xs:element ref="st:euStationNameAss"/>

The following XML snippet shows the serialization of the AirQualityMonitoring-Facility station name attribute using stereotypes: <st:euStationName>AT_AQ_Station1</st:euStationName> Namespaces:

• st: interface property schema When the URI-Property is defined as an association, it is possible to provide the information either inline, or via xlink to an external instance.

4.3

Reflection

Stereotypes are well suited for the definition of reusable URI-Properties. Through the tight binding of the URI-Property to the URI, the semantics of the URI-Property can be provided through an external ontology referencing this URI. This URI is visible within the XML Schema defining the URI-Property via the appinfo element, allowing applications encountering this property to resolve the URI for more information on this attribute. In the final schema, the element name and data type are automatically supplied through the element reference. The schema encoding rules are in alignment with the requirements of the underlying GML and ISO standards, and should be easy to implement.

The only problems currently identified with to this solution pertain to its integration in UML development tools. At present the use of URI-Properties requires discipline from the data modelers, as the constraints on URI-Properties are not checked by the UML tools, and thus inconsistencies will only be flagged during the schema generation process. In addition, registries of reusable URI-Properties would need to be developed and ideally integrated within the UML tools.

A final advantage of the use of URI-Properties is the fact that the definition is agnostic of the final serialization form. While well suited to serialization in XML, the logic behind the URI-Properties is also in alignment with the requirements ensuing from semantic serialization technologies such as RDF.

Conclusion and Outlook

Based on the analysis of the implementation options, the current best candidate for the implementation of URI-Properties is the stereotype solution.

Further analyzing the potential of the stereotype solution, it becomes apparent that the addition of URI-Properties via stereotypes serves to bring traditional UML data modelling closer to emerging semantic technologies, where properties are traditionally first class citizens. If an alignment between URI-Properties within a UML model and predicates as utilized within RDF and OWL is provided, it becomes possible to easily traverse between UML based data models and semantic data models. This would be beneficial, as the spatial data community is progressively moving towards semantic technologies, while wishing to retain as much as possible of the existing data model standards. Thus, by properly utilizing URI-Properties, it is possible to reuse the UML based data models for data serialization both via semi-structured technologies such as XML as well as semantic technologies such as RDF and OWL, opening up the scope of potential end users for the data provided.

Fig. 2 .

 2 Fig. 2. Usage of attribute URI-Properties using Stereotypes

Table 1 .

 1 Analysis Approaches against Requirements

	Requirement URI	DataType	Semantics	Persistence
	Approach	Coupling	Coupling	Coupling
	Data Types	

https://www.cdisc.org/

http://rs.tdwg.org/dwc/

https://www.niem.gov/

https://www.bioontology.org/

https://github.com/NCEAS/oboe/