Nigel W T Quinn
email: nwquinn@lbl.gov

Brian Hughes

Amye Osti

Joel Herr

Elwood Raley

Jun Wang

Real-time Web-based Decision Support for Stakeholder Implementation of Basin-scale Salinity Management

Keywords: salinity, TMDL, decision support, forecast, web-based

Real-time salinity management increases annual average salt export from the agriculture-dominated and salt-impacted San Joaquin Basin. This strategy also reduces the likelihood of potential fines associated with exceedences of monthly and annual salt load allocations which could exceed $1 million per year based on average year hydrology and State-mandated, TMDL-based salt load export limits. The essential components of this program include the establishment of telemetered sensor networks, a web-based information system for sharing data, a basin-scale salt load assimilative capacity forecasting model and institutional entities tasked with performing weekly forecasts of River salt assimilative capacity and coordinating westside drainage return flows. San Joaquin River (SJRRTM) Online (SJRO) is a new web portal that combines WARMF-Online a dedicated web portal for sharing model input data and salt assimilative capacity forecasts with an informational website for increasing stakeholder awareness of the unique characteristics and opportunities for enhanced water and water quality resource management in the River Basin. .

Introduction

In the USA, the Total Mass Daily Load (TMDL) is a policy instrument, developed by the US Environmental Protection Agency (EPA) for attaining compliance with water quality objectives for pollutants of concern for receiving waters (CEPA, 2002;CRWQCB, 2004aCRWQCB, , 2004b)). A unique provision in the published salinity TMDL for the San Joaquin River Basin (SJRB) was the admission of a "real-time" management salt load control strategy which substituted the attainment of a 30-day running average pollutant (salt) concentration for the typical load-based salt load allocations developed for watershed sub-basins upstream of the compliance monitoring point on the San Joaquin River (SJR). This strategy increases potential management flexibility for agricultural, wetland and municipal dischargers to the River and provides an opportunity to maxim-ize salt load export from the Basin without exceeding environmental objectives -however it assumes a level of coordination and cooperation amongst stakeholders that does not currently exist. The core requirements of this program include: the development of a basin-scale, sensor network to collect real-time monitoring of flow and salinity data; an information dissemination system for effective sharing of data among basin stakeholders; a calibrated simulation model of hydrology and salinity in the SJR and its contributing watersheds to allow forecasting and daily assessment of River assimilative capacity (Figure 1); the development of a stakeholder-based institutional entity responsible for coordinating salinity management actions and ensuring compliance with State salinity objectives; and finally the sanction of the Central Valley Regional Water Quality Control Board (CRWQCB). Not only could successful matching of salt load export with River salt load assimilative capacity permit greater export of salt load from the watershed during normal and wet years [START_REF] Quinn | Real-time management of water quality in the San Joaquin River Basin, California[END_REF][START_REF] Quinn | A decision support system for adaptive real-time management of seasonal wetlands in California[END_REF][START_REF] Quinn | Real-Time Water Quality Monitoring and Habitat Assessment in the San Luis National Wildlife Refuge[END_REF][START_REF] Quinn | Environmental decision support system development for seasonal wetland salt management in a river basin subjected to water quality regulation[END_REF][START_REF] Quinn | Environmental sensor networks and continuous data quality assurance to manage salinity within a highly regulated river basin[END_REF] it would also help to overcome salt accumulation in the shallow groundwater system which would ultimately degrade the groundwater resource within the Basin. The combination of real-time monitoring, simulation modeling and forecasting of SJR assimilative capacity has the potential to optimize use of available River salt assimilative capacity, generated by releases of high quality Sierran water, which provides dilution to saline west-side agricultural and managed wetland return flows. However there needs to be coordination and sufficient lead time to allow entities being asked to charge drainage practices or alter reservoir release patterns to be able to respond. Agricultural return flows and salt loads are highest during the summer irrigation season whereas return flows and salt loads from seasonally managed wetlands are highest during the spring months of March and April, when most seasonal wetland ponds are drained to promote establishment of moist soil plants and habitat for waterfowl. These anticipated hydrologic patterns help to screen the array of practices on both the east and west sides of the Basin that will be most effective at managing salinity. Given the uncertainty associated with estimates of salt assimilative capacity, the need for adequate lead time for stakeholders to adjust tributary inflow and drainage return flow schedules and the fact that most weather forecasts provided by news organizations rarely extend beyond two weeks -a two week forecast period and one week hindcast period was chosen for the real-time salinity management program (RTSMP). The one week hindcast refers to the technique of beginning the simulation one week in arrears so that the first week of the forecast can be compared to observed flow and electrical conductivity (EC) data. Model parameters affecting River and tributary inflow and water quality such as the partitioning coefficients that allocate watershed runoff and deep percolation to groundwater can be adjusted to recalibrate the model during periods when model output and River observations diverge. Stakeholders have embraced the suggested two-week forecast and one-week hindcast periods.

2

Real-time Salinity Management

Monitoring Networks -Data Measurement and Telemetry

The monitoring of flow and electrical conductivity (EC) at seven purpose-built monitoring stations along the SJR and from its major east-side and west-side tributaries is undertaken mostly by water agencies such as the California Department of Water Resources (CDWR) and the US Geological Survey (USGS). These stations include the current salinity compliance station at Vernalis on the San Joaquin River, the current upstream boundary monitoring station at Lander Avenue, two major salt load conveyances from the west-side that account for up to 65% of the annual salt load to the River and three major east-side tributaries -the Stanislaus, Tuolumne and Merced River's that receive releases of most Sierra water from eastside reservoirs. Most of these stations have more than 20 years of flow and EC monitoring records and are maintained monthly. The complementary San Joaquin River Restoration Program(SJRRP) is a comprehensive long-term effort to restore a self-sustaining Chinook salmon fishery in the San Joaquin River from Friant Dam to the confluence of Merced River, Full restoration flows began on January 1, 2014 and the previously dry sections of the River are now permanently re-wetted. Full merger of the current RTSMP with the .SJRRP will add five or more River monitoring stations to the current sensor network and will enhance the reliability of model simulation of upper boundary inflow. Water districts and local agencies are responsible for flow and salinity monitoring within the watersheds, some of which directly discharges to the San Joaquin River. Critical data on SJR diversions is currently only collected for the major westside SJR diverters -however this data is not reported on a real-time basis. Recent California legislation requires estimation and reporting of SJR diversions by all riparians with an established right to SJR water supply. This new policy directive has provided an opportunity to coordinate and improve the reporting of stakeholder diversion data using a common reporting protocol.

For the three largest diverters on the westside of the SJR this will require creating external ftp-accessible directories, firewalled from each water districts main server, that can be polled and the data contents uploaded to a single dataserver supporting the forecasting model. A variety of telemetry technologies are used to transmit data from monitoring stations to the end user including CDMA cellular phone, GOES satellite and RF radio. State and federal agencies such as the CDWR and the USGS report real-time data to publicly available sites such as the California Data Exchange (CDEC) and the National Water Information system (NWIS) respectively -whereas most irrigation districts utilize SCADA-based monitoring networks which are private and require username and password access. One of the challenges of developing a basin wide real-time salinity management system is accessing and operationalizing these data in a timely manner that supports daily decision making while maintaining database autonomy and data security.

Data Quality Control and Assurance

Although data quality assurance protocols for discrete environmental sampling are well established and data quality control plans are necessary functions of all hydrologic and water quality monitoring projects -there has been incentive to integrate these activities to promote uniformity and coherence. For continuously recorded and reported data, the protocols for monitoring site visitation, rating procedures, data management, data processing and error correction are often inconsistent leading to a reluctance for stakeholders to share or rely on each other's data. Established software tools used by local water districts (WISKI) the CDWR (HYDSTRA) and the USGS (AQUARIUS) facilitate and guide these tasks that use QA data to error-correct and apply averaging techniques to continuous records. However the response time is currently insufficient to support daily forecast model runs with QA-censored data. In the case of CDWR a separate division is tasked with developing the agency-published time series data which occurs 6-12 months after data acquisition by CDEC. The USGS has a similar turn-around time for published data on their agency NWIS website. All data prior to being published is labelled "Preliminary". In the project we strive to produce a reliable data record that can be publicly shared and readily utilized in the salt assimilative capacity forecasting model. For forecasting purposes we seek daily mean data for flow, electrical conductivity (EC) and temperature (used to make corrections to EC which is temperature dependent) that has undergone at least a preliminary level of data quality assurance. Inaccurate or absurd data posted to a project website can cause irreparable harm by producing erroneous model simulations and forecasts that can quickly lead to a loss of confidence within the stakeholder community. Since four stakeholder entities have already adopted the (Kisters Inc.,2013) WISKI hydrological data management toolbox and the CDWR uses its sister product HYDSTRA we resolved to encourage more widespread use of this common IT platform as a means of fostering the collaboration and data sharing activities required under the RTMP. The WISKI platform is capable of a large number of data quality assurance operations -the most important for our purposes are the screening and removal of values that exceed normal upper and lower threshold values or that exhibit a rate of change between readings that cause the readings to be flagged (in the watershed abrupt changes in flow and EC are not typically observed and are considered aberrant). The software is able to interpolate missing values using a variety of linear and non-linear algorithms including cubic splines which pass through control points. A similar technique is also deployed to perform data shifts that allow real-time data to be fitted to flow and EC sensor quality assurance data, performed monthly in the case of the water agencies and weekly by water districts such as Grassland Water District.

Flow/water Quality Modeling, Simulation and Forecasting

The Watershed Management Framework (WARMF) model [START_REF] Herr | User's Guide to WARMF: Documentation of Graphical User Interface[END_REF]Chen et al., 2001, Herr and[START_REF] Herr | San Joaquin River Model: Calibration Report. CALFED Project ERP-02D-P63 Monitoring and Investigations for the San Joaquin River and Tributaries Related to Dissolved Oxygen[END_REF]) is comprehensive decision support tool specifically designed to facilitate TMDL development at the watershed-level. The WARMF-SJR application simulates the hydrology of entire San Joaquin River Basin which is drained by the SJR -the model performs mass balances for a broad suite of potential contaminants including total dissolved solids. The model, whose simulation domain is shown in Figure 2, simulates tributary inflows from the major east-side rivers, agricultural and wetland drainage return flows, accretions from shallow groundwater, riparian and appropriative diversions and uses hydrologic routing to calculate flow and water quality at approximately 1.6 km intervals along the main stem of the SJR. Wetland drainage from the Grassland Ecological Area is partitioned into component State, Federal and private wetland subarea watershed contributors to SJR salt load.

A GIS-based model graphical user interface (GUI) facilitates the visualization of model input flow and water quality data. Although data templates are built-in to expedite automated data retrieval from State and Federal agency hydrology and water quality databases to facilitate the automated updating of model input files we opted to utilize the OpenNRM engine (described later) to facilitate this retrieval for both the model and the SJRO web portal to avoid potential inconsistencies. Water managers can enter daily schedules of diversions and discharges using a customized spreadsheet-like data interface that is also operationalized through OpenNRM. Standardized model output graphics aid the dissemination of flow and water quality forecasts exported to the dedicated WARMF-Online web portal are now part of the combined SJRO web portal. What makes the new SJRO web portal unique is the integration of real-time watershed data and model-generated flow, salinity and salt load assimilative capacity forecasts.

The RTSMP serves a diverse stakeholder community consisting of agricultural, wetland and municipal entities. The agricultural community comprises more than 40 individual water districts which exhibit their own distinct diversity among the 7 geographic subareas previously identified (Figure 1) that also generally define: (a) native soil salinity; (b) irrigation supply water quality; (c) drainage relief with respect to proximity to the San Joaquin River; and institutional support within stakeholder-led coalitions. The eastside water districts are larger, wealthier with greater resources all of which serve both agricultural and municipal customers. Since the source of their water supply is the Sierra-Nevada mountains water quantity and electrical power rather than water quality have been the major focus of District activities. Because do not divert water from the SJR they are less impacted by salinity and have been more challenging to "bring-to-the-table" for real-time data coordination activities in support of the WARMF-SJR salt assimilative capacity forecast modeling. The westside divided into Grasslands and Northwest side subareas are distinguished from each other primarily by the higher concentration of native salts and the diminished reliance on SJR diversions as a source of irrigation water supply in the Grasslands subarea.

Outreach to westside agricultural stakeholders has concentrated on familiarizing farmers and water district managers with the concept of salt load assimilative capacity and how it varies with season and by water year type. These stakeholders have a wellevolved skepticism of models and model-based analyses and an important aspect of outreach has been the simultaneous display of model flow, EC and salt load assimilative capacity forecasts and real-time observations, as shown in an example (Figure 3), to incrementally build trust in the ability of the model to simulate ambient conditions. Discussion in open forums of WARMF-SJR based salt assimilative capacity forecasts are also used as a vehicle to encourage greater stakeholder engagement including sharing of real-time drainage discharge and River diversion information. We have demonstrated, during stakeholder presentations, the significance of errors that can occur, especially during dry and critically dry years, when default model diversion data (nine year averaged daily mean) are used in-lieu of actual data from westside riparian diverters. The threat of having inaccurate data associated with two of the three major westside riparian diverters has been effective in catalyzing initial data transfer of historic daily diversion data from these water districts.

The wetland entities that form the 140,000 acre (64,000 ha) Grassland Ecological Area (GEA) similarly exhibit their own unique diversity largely on account of their institutional status as State and Federal wildlife refuges on one hand and privately owned duck clubs (some that combine cattle grazing) on the other. Habitat objectives dictate the fall wetland flood-up schedule and more importantly the spring wetland drawdown period. Discharges of salt load between late February and the end of April each year coincide with agricultural pre-irrigation -problematic for those agricultural stakeholders that divert the majority of their water supply from the San Joaquin River. Coordination of salt load discharge schedules for the GEA is being undertaken by the Grassland Water District that has been the first to embrace the concept of RTSMlargely on account of being able to use the same sensor network of 50 flow and EC stations for both water conservation and salinity management purposes. We have found that technology transfer and embrace of web-based sensor technologies occurs faster and more effectively between stakeholders facing similar problems than from vendors of technical experts in water agencies.

Web-based Decision Support

Collaborative Resource Management System for Data Visualization, Analysis and Decision Support

Collaborative, real-time salinity management (RTSM) is best facilitated when all stakeholders have a forum and toolset for aggregating and accessing the data and information used to inform management decisions and operations. The SJR RTMP has developed a comprehensive resource (San Joaquin River Real Time Management -(SJRRTM) Online (abbreviated to San Joaquin River Online-SJRO) that combines WARMF-Online -the dedicated web portal for sharing model input data and salt assimilative capacity forecasts (Figures 4 and5) -with an informational website for increasing stakeholder awareness of the unique characteristics and opportunities for enhanced water and water quality resource management in the River Basin. SJRO supports collaborative efforts to improve salinity management in the San Joaquin River and gives stakeholders access to resources (reports, GIS, datasets), reporting dashboards for viewing WARMF model output and supplemental data as well as a collaborative workspace for evaluating and discussing system conditions. SJRO aims to provide stakeholders with timely information and a transparent process for coordinating system-wide salt loading schedules with reservoir releases of high quality flows from the East-side of the Basin. The web based data management platform OpenNRM, is a Collaborative Natural Resource Management software tool developed by 34-North Inc. in concert with the project team.

OpenNRM allows users to create, modify and manage data and content collectively and provides filtering capability to parse information based on regions, areas of responsibility, hot spots, presets and more using mapping and data dashboard interfaces. Geocoded information is enabled for all data types extending the map and dashboards to include document libraries, projects databases, datasets, visualizations, wiki knowledge bases, publications and miscellaneous file types related to specific locations. The framework supports simple and robust construction of dashboards, common operating pictures, adaptive management scenarios, regional management cyberinfrastructure, workspaces and project collaboration tools.

OpenNRM is currently implemented as five hosted open data management platforms throughout the State of California. This open data federation approach provides instant access to State and Nationwide datasets and services including the California Irrigation Management System (CIMIS), California Data Exchange (CDEC), National Water Information System (NWIS), National Oceanic Atmospheric, Administration (NOAA), water quality databases including STREAMWATCH, CEDEN, STORET and hundreds of GIS Layers. CIMIS, CDEC, NWIS and NOAA provide real-time data used in the development of San Joaquin River salt assimilative capacity forecasts using the WARMF-SJR model. The OpenNRM platform has been customized to provide stakeholders with the following decision support resources and tools:

1. Data tools to visualize and analyze current watershed conditions. Baseline data and baseline conditions. 2. Data and information needed to assess future environmental conditions and support management actions using the WARMF-SJR model and real time analytics. 3. Data aggregation and formatting tools to efficiently run the WARMF-SJR model and system wide assessments. Support resources to better understand how the San Joaquin Basin functions including research catalogs, regulatory resources, interactive maps, real time data visualizations, charts and graphs. 4. OpenNRM also addresses the need for a collaborative workspace for supporting, organizing, managing, analyzing, visualizing, archiving and reporting project and operations information. 5. The creation of SJRO facilitates analysis, synthesis, assessment and communication to develop a credible process in which stakeholders can participate in order to ensure that data are appropriately assessed, interpreted, and reported.

Customized SJRO Features for Real Time Salinity Management

The data aggregation toolset in SJRO prepares data packages from a variety of agencies and data sources that include approximately 356 monitoring sites (meteorological hydrologic, and water quality data) using preset and user defined time extents. The assembled data is formatted and converted to make the data compatible for import into the WARMF-SJR forecasting model as well as the online reporting dashboards and assessments. This tool also generates base line data for modelers and stakeholders running independent analytics. A second key feature is the simplification of data management and access by centralizing key datasets and management tools. To better understand the characteristic behavior of the SJRB sensor data is spatially organized using interactive maps and data dashboards allowing stakeholders to track flow, salinity, salt load export and irrigation diversions from the upper reaches of the SJR through to the Sacramento -San Joaquin Bay Delta. The data are collected from a wide range of sources and made comparable using map based data visualizations alongside interactive charts and graphs. Users can compare Electrical Conductivity (EC), River Discharge, and Salt Load from both the forecasted model output and real time observations. Customized post-processed visual outputs such as the GOWDY Output (Figure 6) allow the user to directly access WARMF-SJR model simulation results and toggle between views of flow, EC and salt load for the entire San Joaquin River between Lander Avenue and Vernalis (a 96 km reach) for a single day in the year. On the left panel flows into the River show as green horizontal columns superimposed over the input source whereas diversions from the River show up as red horizontal columns to the left of zero. In the top and bottom panels to the right of the screen are shown travel time showing an initial value of 1.8 days diminishing to zero days at the Vernalis compliance monitoring station. Flow is shown increasing from left to right as the east-side tributaries discharge into the River. The lower right-hand panel shows the same cumulative flow relative to cumulative River diversions. Powerful visualization aids such as the Gowdy Output provide the user with a comprehensive daily window into the complex characteristics of flow and water quality in the San Joaquin Basin.

Although Basin stakeholders have endorsed the concept of RTSM the novelty of decision support implications of RTSM implementation are unclear to the majority of these stakeholders. Hence the primary initial goal of SJRO has been to educate stakeholders on the characteristics of the Basin, the various means of generating salt assimilative capacity within the Basin and the potential performance of various salinity management strategies (that include both incidental measures such as river diversions and drainage water reuse and deliberate strategies such as short-term ponding of drainage in small reservoirs). Other short-term goals are specific to water managers within each of the major contributing subareas to the SJR. For example west-side agricultural water districts that divert directly from the SJR for a portion of their agricultural water supply will be interested in assessing compliance with the newly promulgated upstream salinity objectives at the upstream Crows Landing monitoring station -which directly impacts the salinity of their River diversions. The wetland entities which include private duck clubs, State and Federal wildlife refuges will be concerned with scheduling of their annual wetland drawdown during the months of March and April so as not to exceed available River salt assimilative capacity. East-side water districts that control reservoir releases along tributaries to the SJR that generate much of the River's salt assimilative capacity will want to develop a better understanding of how to optimize the timing of these events with west-side salt loads and their own salt loading to the River and how to improve communication of these opportunities. salt load to be interactive and viewed spatially on a map. Attribute tables determine how the values from surrounding monitoring stations are assigned to each watershed polygons and color coded using the OpenNRM display tools. Data is delivered using the OpenNRM content management system that ingests a binary and proprietary RIV file. The result allows the end user to see the salinity conditions over a user-specified time window -typically two weeks for the salt assimilative capacity forecast.

The SJRO visualization tools are designed so that model simulations and forecast runs can be repurposed and enhanced for additional studies or analysis. When fully implemented SJRO will supply real-time flow and salinity data from public water agency websites, cooperating water districts and other stakeholders to enable reliable daily simulations and forecasts of River assimilative capacity to the San Joaquin River. Future forecasts will utilize a single web-based version of the model application. This web based model will be continuously calibrated and upgraded with new algorithms and bug fixes. Future WARMF-SJR model forecast runs will be made by a small core group of stakeholder and/or agency personnel with write access privileges to the model. Model outputs and post-processed visualizations will continue to be made available to the public through SJRO web portal.

Coordinated Stakeholder Decision Support for Salinity Management

In early 2016 the San Joaquin Valley Drainage Authority (SJVDA) initiated informational quarterly stakeholder meetings on behalf of the Westside San Joaquin River Watershed Coalition (WSJRWC) on the topic of data management, data coordination and mechanisms for data sharing -a core requirement for RTSM. The WSJRWC (www.sjvdc.org) currently: (a) represents water districts and other agricultural and wetland stakeholders located within the Grassland and North-West side subregions; (b) manages data collection at a large number monitoring sites and; (c) submits reports on these data to the CVRWQCB. Similarly on the east-side of the Basin the East San Joaquin Water Quality Coalition (ESJWQC) (www.esjcoalition.org) files required monitoring reports with the CVRWQCB on behalf of its 1000+ farmers and stakeholder entities, provides conditional waiver coverage for members of the coalition, develops and is responsible for implementation of the real-time water quality monitoring program. The ESJWQC communicates and advises landowners when water quality monitoring indicates the occurrence of a problem exist and helps with the timely development of equitable solutions. Ultimately the WSJRWC and the ESJWQC will need to develop a Memorandum of Understanding for joint implementation of the real-time management program recognizing the use of the WARMF-SJR model as a decisionmaking tool to forecast availability of River assimilative capacity. Realization of the potential of RTSM may require the formation of a basin-scale salinity management entity built upon the WSJRWC and the ESJWQC with the authority to encourage compliance with sub-basin salt load targets through incentives or penalties set at mutually agreed-upon salinity compliance monitoring locations. In Figure 7 a simplified workflow, feedback and control schema is shown that provides an overview of the current institutional decision support framework. Weekly salt load forecasts will be made for each of the seven subareas and compared to salt load allocations for these same subareas determined using the procedures published in the Water Quality Basin Plan for the San Joaquin Basin. The salt load allocation procedures are based on current flow conditions and subtract background salt loading, groundwater accretions and point source load allocations from River assimilative capacity (estimated by multiplying the same flow condition by the salinity compliance objective at the Vernalis monitoring station). It is assumed that only 85% of the available assimilative capacity is available -hence a factor of safety of 15% is applied to each salt load allocation for each of the seven contributing subareas. While salinity objectives are being met at Vernalis no action is required to control and make scheduling adjustments to salt export to the River. However at times, such as during dry or critically dry years, when the objective might be violated -those subareas not in compliance would be obligated to reduce salt export or enter a salt load trading arrangement with compliant subareas to bring the entire system into compliance.

Following the schema in Figure 7 -real-time watershed data used by the WARMF-SJR model to develop weekly forecasts are compared with subarea salt load allocations using the same flow and EC predictions provide by the model and reviewed by the separate eastside and westside stakeholder coalitions. The (as yet un-named) coordination entity would be responsible for managing salt export in those subareas in instances where the model-based forecasts suggested a potential future violation. During the past decade there have been less than five violations of the Vernalis objective that would have required action by stakeholders that might invite complacency. However the Regional Water Quality Control Board requirements for real-time salinity management require that a response program be ready and implementable if stakeholders are to continue to enjoy the economic and environmental benefits of being part of the Program. The Board can impose a fine of up to $5,000 per day to any Subarea within the basin that is found in violation of Subarea salt load limits during any period of violation of the Vernalis salinity objective.

Summary and Conclusions

Technical advances in data acquisition and information dissemination technologies have made possible the initial stages of implementation of a real-time salinity management program in California's SJRB. Experience to date with respect to implementation of RTSM in the San Joaquin Basin suggests the following principles moving forward, that have been discussed in the paper: (a) necessary stakeholder participation in the design and operation of existing and planned flow and water quality monitoring stations and web-based IT solutions that provide easy access to the real-time data being collected; (b) decision support system enhancement that utilizes technical expertise within the WSJRWC and ESJWQC and works toward implementation of a common system; (c) WARMF-SJR simulation model enhancements with full GIS capabilities and made more robust in its ability retrieve real-time data through the current WARMF-Online and SJRO web browsing tools. A state-of-the-art visualization engine with imaginative graphics to enhance stakeholder understanding of the current system and how their actions can impact salt load export; (d) more widespread support for data quality assurance technologies such as WISKI and HYDSTRA to improve accuracy of the real-time data being utilized by the WARMF-SJR forecasting model and reduce the fear of posting erroneous data; (e) greater automation of the process of providing salt assimilative capacity forecasts and an eventual transition from weekly to daily forecasts which allow feedbacks between stakeholder actions that update the state of the system; (f) institutional arrangements that formalize and streamline salt loading trading between subareas within the eastside and westside stakeholder coalitions that minimize institutional oversight and remedy potential salinity compliance violations before they occur..

The process of implementing RTSM in the SJRB will further encourage innovation -successful implementation will have significant transfer value to other highly regulated river basins where water quality is a concern.

Figure 1 .

 1 Figure 1. Subareas within the San Joaquin River Basin draining to the San Joaquin River defined in the salinity TMDL (CRWQCB, 2002).

Figure 2 .

 2 Figure 2. The WARMF-SJR model interface showing the disaggregation of watersheds contributing flow and salt load to the San Joaquin River into component drainages. The hydrology of the San Joaquin Basin is such that the political boundaries of individual agricultural water districts are the most appropriate primary unit (sub-watershed) for monitoring, management and control of salt loading to the San Joaquin River from the west-side. Sub-watersheds on the east-side of the San Joaquin River are determined by the irrigation supply and surface drainage network.

Figure 3 .

 3 Figure 3. Prototype WARMF-SJR model-based forecast graphic being used to encourage stakeholder interest and engagement in RTSMP activities. Given the newness of the concept of RTSM -stakeholders do not necessarily know a-priori their preferences for data visualization and quantitative representation of the concept of salt load assimilative capacity. The WARMF-Online web portal is being developed through feedback at scheduled stakeholder meetings.

Figure 4 .

 4 Figure 4. San Joaquin River (SJRRTM) Online (SJRO) web portal using the OpenNRM visualization toolbox. The web portal provides data access to visualizations of WARMF-SJR model output. The model provides forecasts for weekly salt assimilative capacity and GIS-based data analysis.

Figure 5 .

 5 Figure 5. Visualization of WARMF-SJR model results in SJRO -published daily for collaborative viewing of forecasted conditions of the River and its tributaries in the Basin. Visualizations are supported with additional analytics for comparing observed and forecasted data. The web portal provides data access to more than 365 monitoring sites throughout the basin. Reporting dashboards are in real time and can be compared with modeled data.

Figure 6 .

 6 Figure 6. Gowdy customized outputs showing daily inflow and diversions every 1.6 km along the mainstem of the San Joaquin River for a chosen annual time series output from the WARMF-SJR simulation and forecasting model.

Figure 7 .

 7 Figure 7. Process workflow showing the main steps in developing weekly salt load assimilative capacity forecasts and the role of the coordination entity in allocating resources to improve San Joaquin River salinity during periods of exceedence.

Acknowledgements. The authors acknowledge support from the US Bureau of Reclamation that has financed development of the essential tools for RTSM implementation.


Adam Kučera
email: akucera@mail.muni.cz

Tomáš Pitner

Semantic BMS: Ontology for Analysis of Building Operation Efficiency

Keywords: Facility Management, Building Automation Systems, Semantic Sensor Network Ontology, Decision Support, Energy Efficiency, Operation Efficiency 1

Building construction has gone through a significant change with the emerging spread of ICT during last decades. Intelligent buildings are equipped with building automation systems (BAS) that can be remotely controlled and programmed. However, such systems lack convenient tools for data inspection, making building performance and efficiency analysis demanding on large sites. The paper presents an adaptation of Semantic Sensor Network ontology for use in the field of building operation analysis. The proposed Semantic BMS ontology enriches the SSN with a model of building automation data points and describes relations between BAS and physical properties of a building. Proposed ontology allows facility managers to conveniently query BAS systems, providing decision support for tactical and strategic level planning.

Introduction

Each organization needs to ensure various aspects of its operation that are not directly involved in reaching its primary goal (e.g. providing service to a customer or sell its products). Such tasks are the core part of the Facility Management discipline. In recent years, environmental aspects of facility operation gain attention in the eyes of facility managers, both because of the legislative requirements and a close relation to sustainability and low operation costs.

We can distinguish several systems and/or data sources that can be utilized to support and simplify tasks of facility management staff.

Computer Aided Facility Management (CAFM) systems facilitate tasks such as assignment of employees to rooms, a log of maintenance plans, requests, and tasks, or energy consumption data. A Building Information Model (BIM) contains spatial information about building constructions, parts, and technologies installed in them. Modern ("intelligent") buildings are equipped with a variety of sensors and controllable devices (e. g. HVAC, security systems). The devices are integrated into the Building Automation System (BAS), also referred as Building Management System (BMS). The devices incorporated in BAS can be remotely controlled, monitored, and queried. Individual information objects (such as current temperature in particular room measured by a sensor) accessible in the BAS network are referred to as "data points" further in the paper.

A crucial part of sustainable and effective facility operation is benchmarking. Benchmarking methods in facility management are covered in EN 15221-7 standard, including environmental awareness. Requirements placed on benchmarking Key Performance Indicators (KPIs) are summarized in [START_REF] Alwaer | Key performance indicators (KPIs) and priority setting in using the multi-attribute approach for assessing sustainable intelligent buildings[END_REF]. Among others, the authors mention flexibility, the quantitative nature of the KPIs and simplicity of use. BMS data satisfy the first three requirements, the simplicity of use is a downside of current BAS solutions.

The BAS contains a large amount of a precise, up-to-date, and detailed data that are valuable for a building operation analysis and cannot be obtained any other way. However, data points of the BAS are described by their location in the network topology, not by the role that algorithms, sensors, and actuators fulfill in the building operation. Using BACnet protocol as an example, data point representing temperature sensor is identified by the network address of the device that reads the value, data type of the input (Analog input) and ID of the input within the device. Besides this identification of data point, BACnet provides only several free-form string attributes such as Name or Description, which are intended to be easily readable by human operators.

The absence of structured semantic information prevents efficient querying of the data points for analytical purposes, as it is not possible to select and filter the data based on criteria such as a type of a source device, location of a measurement or measured quantity kind. If the data from data points are required (e. g. electricity consumption for last month for each of the buildings on the site which will be later compared), the operators of the system must manually gather the data point addresses by inspecting the building plans or user interface of the BAS.

The above-mentioned problem clearly emerges when operating large BAS system. Masaryk University utilizes BAS network consisting of approximately 1500 devices communicating using BACnet automation protocol with hundreds of thousands of data points available. The network covers 35 buildings with the overall area of 120 000 m 2 at the site of University Campus Bohunice in Brno, Czech Republic and several more over the whole Brno city. Previous attempts of data coming from the BMS of the university have been published in [START_REF] Kriksciuniene | Sensor network analytics for intelligent facility management 1[END_REF] and [START_REF] Kriksciuniene | Data analysis in the intelligent building environment[END_REF]. The requirements of effective operation of large-scale installations of automation technologies are discussed in [START_REF] Kučera | Intelligent facility management for sustainability and risk management[END_REF].

This paper presents Semantic BMS ontology that aims to provide a semantic description of the building automation systems. Such description can be easily queried for building operation data needed for benchmarking, providing decision support in tasks such as improving facility efficiency, sustainability and increasing organizations' environmental awareness.

Related Work

The semantic description of sensor networks is a subject of ongoing research, as it combines two significant trends in computer and information science -Semantic Web (Open Linked Data) and Internet of Things. Furthermore, the trend towards "Smart Cities" stimulates research on the integration of automation systems and building automation data analysis.

The Open Geospatial Consortium (OGC) provides Sensor Web Enablement (SWE) suite of standards, ensuring syntactic model of sensor networks (SensorML) as well as interfaces and protocols for data exchange. OGC's Observation&Measurements (O&M) provides a limited semantic description of sensor networks. The SWE however does not cover a domain specific semantics.

Probably the most notable ontological description of sensor networks is Semantic Sensor Network Ontology (SSN) developed and maintained by W3C Consortium [START_REF] Compton | The SSN ontology of the W3C semantic sensor network incubator group[END_REF], which adopts the scheme of Observations&Measurements Model.

In architecture, engineering and construction industry, integration of different Building Information Model solutions is facilitated by Industry Foundation Classes standard in current version IFC 4 (ISO 16739:2013). The object-based data model together with the provided file formats ensure data exchange between BIM systems and can be viewed as a source of semantic information that can be used for analysis of building performance, as shown in [START_REF] Menzel | Capabilities of IFC 4 for Advanced Building Performance Management[END_REF]. However, the IFC does not aim to model complex semantic information concerning data points available in the building automation systems. In [START_REF] Schuelke | A middleware platform for integrated building performance management[END_REF] and [START_REF] Wang | Integration of BIM and Live Sensing Information to Monitor Building Energy Performance[END_REF], direct mapping of data points to IFC entities is used for building operation analysis. As noted by the authors of [START_REF] Wang | Integration of BIM and Live Sensing Information to Monitor Building Energy Performance[END_REF], the IFC itself does not provide builtin capabilities for describing features of interest and properties observed by sensors.

Standardized building automation protocols such as BACnet (ISO 16484-5), Lon-Works (ISO 14908-1), KNX (ISO 14543), or ZigBee generally cover the operation of building automation devices, providing specifications for physical communication layer, data link and networking layer and application layer on the highest level. Automation protocols focus on communication interfaces and do not provide tools for the complex and structured description of the semantics of the data points.

The MOST project presented in [START_REF] Zach | MOST: An opensource, vendor and technology independent toolkit for building monitoring, datapreprocessing, and visualization[END_REF] provides a framework for building operation analysis. The MOST uses a relational database for storing basic semantic information about operation data.

In [START_REF] Ploennigs | Adapting Semantic Sensor Networks for Smart Building Diagnosis[END_REF], the SSN is extended by a model of physical processes occurring in the building (e.g. adjacent room exchanging energy) to provide tool for building operation diagnosis and anomaly detection.

The Open Linked Data approach for building automation data streams is facilitated by EDWH Ontology proposed in [START_REF] Mehdi | On-the-fly Generation of Multidimensional Data Cubes for Web of Things[END_REF]. The aim of the EDWH ontology is to provide a bridge between the SSN ontology and the W3C RDF Data Cube vocabulary, as the data are meant to be analyzed by OLAP data cube techniques.

In [12], [13] and [START_REF] Hasan | Toward Situation Awareness for the Semantic Sensor Web: Complex Event Processing with Dynamic Linked Data Enrichment[END_REF] the authors use a SSN-based ontology for energy management based on sensor data using OLAP and Complex Event Processing. The semantically described BAS data help to establish situation awareness at the strategy level and allow multi-level evaluation of energy consumption (from organization level to the level of individual appliances).

In general, existing ontologies either aims to describe different aspects of BAS than data analysis, use proprietary/ad-hoc structures for storing semantic data, ignore integration with BIM systems or do not provide a domain-specific mapping of BAS systems to the SSN ontology.

Semantic BMS Ontology

The goal of presented research is to provide a BAS-protocol-independent model of intelligent building systems. The Building automation system can be viewed as a sensor and actuator network for the purposes of data analysis. A semantic description of sensor networks is a subject of extensive research, resulting in frameworks and tools such as SensorML language, Observations & Measurements (O&M) model or Semantic Sensor Network ontology (SSN). However, for the use in the domain of building automation, certain differences have to be taken into account.

The Semantic BMS Ontology (SBMS) proposed in this paper is thus an extension of the SSN ontology, addressing domain-specific requirements of building automation data analysis. The SBMS remains "fully backward compatible" with the SSN ontology (meaning no modification were made in the SSN itself, it was only extended) and at the same time provide greater semantic description strength for the target domain that "pure" SSN.

Fig. 1. Overview of the SBMS Ontology

The proposed ontology aims to represent information (data) available for operation analysis. It does not aim to describe physical topology of the BAS network or physical properties of the sensors and actuators such as operating range. Standardized building automation protocols themselves also provide limited metadata description of the system as well as other services such as a data store. Similarly, the BIM and CAFM provides additional sources of semantic information. As a result, the semantic description of the BMS is not required to contain some information that would be a duplicate (copy) of data available in the BAS, BIM or CAFM systems. The aim of the presented research is to enrich the BAS/BMS with semantic links to entities present in other systems (BIM, CAFM) and add a new layer of semantic metadata that are not available elsewhere.

The SBMS ontology enriches the SSN by adding the concept of a data point, which is distinct from a sensing device. While a sensing device is a source of data presented by a data point, a data point conceptualizes a measured value available in an automation system. It describes a representation of measured data in building automation software.

Figure 1 presents standard components of the SSN ontology together with their specializations defined in the SBMS ontology. The center point of the SSN is the ssn:Observation concept. The observation connects all actors and objects that take part in the process of obtaining measurement data, and thus provide all available semantic information via its properties. The specialized sbms:Observation as well as properties defined in the SBMS limits domains and ranges to those concepts that are usable in the domain of building automation. The changes affect the definition of the feature of interest, observed property, sensing methods and sensing devices.

Key concepts for accurate semantic annotation of sensor/actuator data are "Observed property" (OP) and "Feature of Interest" (FoI). The concepts were defined in O&M framework and adapted by the SSN ontology. The FoI represents an object of measurement. The OP represents specific information that we observe. In the domain of building automation, we can demonstrate the concepts on examples such as energy consumption (OP) of a specific building (FoI) or speed (OP) of a specific fan (FoI). The SBMS ontology further specializes the concepts for use in the domain of building automation.

The ssn:Feature of Interest is restricted by the subclass sbms:Scope to be site, building, floor, room, or device further described in the BIM database. This restriction reflects a nature of a data available in BAS. Since BAS ensure operation of the building, every piece of information available in the system can be related to specific part of a facility or to a piece of installed equipment. Class and property definitions are restricted so as valid FoI can be either a device (e.g. valve, pump, engine, or PLC) or a location (site, building, floor, or room).

A similar restriction is applied to the ssn:Sensing Device by the subclass sbms:Source. Every piece of information available in the BAS must be measured by some device connected to the BAS network. Such devices are naturally present in the BIM database. As a result, each individual of sbms:Source has to be a device described in the BIM database, represented by sbim:Device class.

The SBMS ontology contains a simplified model of selected elements from the BIM systems. Such concepts reside in dedicated namespace sbim. Namely, it contains concepts describing locations and parts of the facilities (sbim:Site, sbim:Building, sbim:Floor, sbim:Room), and devices (sbim:Device and its descendants) that provide sensor data or that are observed by the building automation system. Classes representing specific types of building equipment are adapted from the IFC 4 specification.

3.1

Semantic description of BMS Addresses

The SBMS ontology adds a representation of an address that publishes observed data in the BAS. Identification of a sensing device is not sufficient in case we need to obtain the data from the BAS system. The sensing device is identified by ID in the BIM. The BIM ID, however, cannot be used for accessing data in the BAS, since certain sensors are represented in the BIM as independent devices, but they are primitive and do not directly communicate within the BAS. An example of such device is a temperature sensor, which is a simple thermistor in a casing, connected to a PLC. The sensor is represented in the BIM as a separate entity, but the data is accessible via the PLC.

The sbms:Address class defines several subclasses, most important are sbsms:Input and sbms:Output, representing sensor reading and actuator command.

Results

The presented ontology is designed to model the data sources available in the BAS and provide additional semantic information regarding relations of respective data points to a physical environment of the building. The newly added semantic information can be used by developers of new analytical applications for the domain of building operation analysis. Such applications will provide decision support for improving building performance and efficiency. Typical environment-related tasks for such applications are related to energy consumption and workplace temperature conditions.

In case of energy consumption, the ontology can be easily used for selecting data points containing electric consumption. The combination of appropriate parameters defines desired data points: Source device type --Energy meter, "Input" data point type and Property domain "Electricity"). The Scope attribute in the result set then describes facilities that are responsible for a consumption measured by a given data point.

Another use case of the ontology related to environmental responsibility searches for rooms that are cooled or heated ineffectively. The ontology allows for easy selection of room temperature data. Data selection is very similar to the previous use case, finding data originating from temperature sensors measuring air temperature with Scope type of "Room". The data then can be gathered and outliers --rooms with unreasonably high temperatures in winter on low temperatures during warm periods --can be identified and inefficient behavior can be addressed and removed.

The novelty of the ontology allows selecting data according to mentioned criteria. Current building automation systems do not provide querying mechanism and do not annotate the data by desired attributes, such as Scope or Property domain.

In order to facilitate the development of analytical applications to maximal extent, the Semantic BMS framework is being developed (see Fig. 2). The framework is divided into two main parts --Data providers and Semantic providers. Data providers are used for accessing measurement data. The Semantic providers present data available in the SBMS ontology. The rest of this section will be focused on the Semantic provider.

As an ontology repository, Apache Jena TDB is used. The repository can be queried directly (using SPARQL) or via the Semantic API. ing sensing type and possibly time window if applicable for given sensing. Often repeated FILTER statement deals with type hierarchy in ontology language. The query selects only leaf, most specialized subclass of given individual. Results of such query are then returned in various serialization formats, such as SPARQL JSON.

Due to the complexity of SPARQL queries and generic SPARQL-JSON responses, semantic API was developed as a RESTful service providing semantic data using JSON format. The API uses Jersey framework ensuring RESTful capabilities and Apache Jena API for communication with the ontology repository.

Fig. 2. Semantic BMS framework overview

As an example of API goals and capabilities, the "data points" endpoint will be discussed. The endpoint allows a consumer to query the ontology repository for data point semantic description based on given semantic criteria. Example of JSON response payload:

{ "dataPoints":[ {"bmsId":"1600.AV4", "dataPointType":"Input", "property":{"domain":"Electricity", "quality":"energy"}, "scope":{"bimId":"Building:A1","type":"Building"}, "source":{"bimId":"ElectricMeter-A1", "type":"FlowMeter"}, "sensing":{"type":"AggregateSumSensing", "window":"Months01"} }]}

The API provides following information about the data point with BMS ID "1600.AV4": ─ Data point type --Specifies a role of the data point in the BAS. ─ Physical quality and property domain --Specifies physical quality represented by the data point (e.g. temperature, humidity, energy, or output power). ─ Scope (Feature of Interest) --A scope specifies object the data point value is related to. Possible scopes are the location (e.g. building when measuring energy consumption) or device (e.g. fan in the case of data point representing fan speed). ─ Data source --Specifies the device that provides the BAS with the data. ─ Source device type --Describes the type of the source device (e.g. Flow meter). ─ Sensing method and time window --The simplest case is direct sensing (e.g. room temperature). Other (indirect) sensing methods employ computation or aggregation over some period (e.g. energy consumption total for the last month).

Presented examples of the Semantic API capabilities aim to show how the data stored in Semantic BMS ontology can be queried using convenient and easy to implement methods, thus significantly simplifying development of various analytical and decision support application for the field of building operation analysis.

Conclusions

The presented ontology aims to provide additional semantics to data points available in building automation systems. The ontology is designed to be automation protocol independent and describes available data in a way that can be utilized during decision support tasks needed for building performance analysis, evaluation, and improvement, which are crucial tasks to achieve energy efficient and environment-friendly operation of facilities. Using additional semantic layer, the process of obtaining and inspecting key performance indicator data is significantly simplified. Ontology design was based on long term experience with the operation of University Campus of Masaryk University as site equipped with hundredths of automation devices.

At the moment, the ontology is populated with sample data representing several typical components of building automation systems. Further steps contain the development of proof-of-the-concept Data provider for the BACnet protocol. The ontology will be populated with information describing an actual building. Next, methods described in the "EN 15221-7 Facility Management -Part 7: Guidelines for Performance Benchmarking" standard will be used for evaluation of the ontology and API usability. Assessment of query retrieval performance is also planned in this step, leading to possible optimization of ontology model or query composition.


Ari Jolma

Ville Karvinen

Markku Viitasalo

Riikka Venesjärvi

Jari Haapala

Information System as a Tool for Marine Spatial Planning: the SmartSea vision and prototype

Keywords: Marine Spatial Planning, Planning Support System, Information environment, Web Mapping, Dynamic Tile Service, WMTS

Planning the use of marine areas requires support in allocating space to particular activities, assessing impacts and cumulative effects of activities, and generic decision making. The SmartSea project studies the Gulf of Bothnia, the northernmost arm of the Baltic Sea, as resource for sustainable growth. One objective of the project is to provide an open source and open access toolbox for marine spatial planning. Here we present a vision for the toolbox and an initial prototype. The vision is based on a model of information system as a meeting point of users, information providers, and tasks. A central technical requirement for the system was found to be a data model and related database of spatial planning and a programmable map service. An initial prototype of the system exists comprising a database, data browser/editor, dynamic tile map service, web mapping application, and extensions for a desktop GIS.

Introduction

Marine Spatial Planning (MSP) is a recently coined term for "a public process of analyzing and allocating the spatial and temporal distribution of human activities in marine areas to achieve ecological, economic, and social objectives that are usually specified through a political process" [START_REF] Ehler | Marine Spatial Planning: a step-by-step approach toward ecosystem-based management[END_REF]. The aim and challenge of MSP is to manage both increasing and competing sectoral needs, especially for energy and natural resources, and increasing interest in maintaining biodiversity and conservation of nature [START_REF] Jones | Marine spatial planning in reality: Introduction to case studies and discussion of findings[END_REF]. The European Union (EU) has recently (2014) issued a Maritime Spatial Planning Framework Directive, which sets minimum common requirements for national MSP. EU has also launched a website for sharing experience and expertise in MSP 1 .

Effective MSP should be integrated and bring industries, such as fisheries, aquaculture, tourism, marine biotechnology, ocean or offshore energy, seabed mining, and commercial marine transportation, together to make coordinated decisions about how to use the sea and marine resources sustainably [START_REF] Ehler | Marine Spatial Planning: a step-by-step approach toward ecosystem-based management[END_REF]. Some of these industries are strictly in competition, while some may co-exist in same space. There are also complex interactions between marine, coastal, and terrestrial industries and environment.

Several plans concerning sea areas have been carried out or are in progress in Europe. Jones et al [START_REF] Jones | Marine spatial planning in reality: Introduction to case studies and discussion of findings[END_REF] describe 12 cases that were studied in the EU-FP7 project MES-MA. Stelzenmüller et al [START_REF] Stelzenmüller | Monitoring and evaluation of spatially managed areas: A generic framework for implementation of ecosystem based marine management and its application[END_REF] introduce a framework for monitoring and evaluation of spatially managed areas (SMAs), which was tested on nine of these case studies. Katsanevakis et al [START_REF] Katsanevakis | Ecosystem-based marine spatial management: Review of concepts, policies, tools, and critical issues[END_REF] introduce and analyzes ecosystem based marine spatial management as a holistic approach that could be supported by MSP.

Stelzenmüller et al [START_REF] Stelzenmüller | Practical tools to support marine spatial planning: A review and some prototype tools[END_REF] reviewed software tools that could have potential to support MSP and then developed a set of prototype tools to support MSP. They defined three categories of tasks that a practical MSP tool should support: (i) allocating space to particular activities, (ii) assessing impacts and cumulative effects of activities, and (iii) generic decision support. Zoning (partitioning the planning region into zones that are designed to allow or prohibit certain activities) is a popular method for managing both spatial interaction and cumulative effects [START_REF] Halpern | Managing for cumulative impacts in ecosystem-based management through ocean zoning[END_REF]. However, in marine areas boundaries of zones are difficult to identify and enforce [START_REF] Stelzenmüller | Practical tools to support marine spatial planning: A review and some prototype tools[END_REF]. Also, zoning may result in a sectoral approach, which has been criticized [START_REF] Jones | Marine spatial planning in reality: Introduction to case studies and discussion of findings[END_REF].

Geodesign denotes a stated aim of developing plans, that is, synthesizing new geospatial data, with software tools [START_REF] Dangermond | GIS: Designing Our Future[END_REF]. Collaborative decision-making and networking is often emphasized in the development of geodesign tools [START_REF] Mitsova | A Collaborative Geospatial Shoreline Inventory Tool to Guide Coastal Development and Habitat Conservation[END_REF][START_REF] Merrifield | MarineMap: A web-based platform for collaborative marine protected area planning[END_REF][START_REF] Janssen | Decision support tools for collaborative marine spatial planning: identifying potential sites for tidal energy devices around the Mull of Kintyre, Scotland[END_REF]. For example, online tools like MarineMap2 and SeaSketch3 allow user participation and proposing of solutions, which can be compared. Merrifield et al [START_REF] Mitsova | A Collaborative Geospatial Shoreline Inventory Tool to Guide Coastal Development and Habitat Conservation[END_REF] describe a spatial decision support system that enables stake-holder participation in designing Marine Protected Areas (MPAs) and Janssen et al [START_REF] Merrifield | MarineMap: A web-based platform for collaborative marine protected area planning[END_REF] describe a method and a case of collaborative marine spatial planning involving the use of a decision support tool.

SmartSea is a research project (2015-2018), which aims to provide science-based guidance and new innovations for sustainable use of the marine resources of Finland. Finland is a Baltic Sea country and most of its foreign trade takes place by it. Finland is relatively poor on domestic energy sources and the shallow coastal waters of the Baltic Sea present an opportunity to develop offshore wind power. Due to its history, closedness, and current pressures, the Baltic Sea is a unique, fragile, and threatened sea area. Its environmental problems are, for example, eutrophication, lack of oxygen in the bottom layers, and the accumulation of environmental toxicants. The species diversity of the Baltic Sea is very low compared to oceans or lakes and rivers. Brackish water, young geological age of the basin, and the lack of certain habitats, such as tidal zone, cause the low biodiversity.

The SmartSea project will focus on Gulf of Bothnia (GoB), the northernmost arm of the Baltic Sea. GoB is divided into exclusive economic zones of Finland and Sweden. It is still a relatively undeveloped sea area with an area of 117 000 km 2 .

The aim of this paper is to present the vision for the SmartSea MSP toolbox and describe its first prototype. The MSP toolbox will build on and be free and open source software and provide open access to existing and new information resources and tools.

SmartSea MSP toolbox: the Context

The data that will provide input to marine spatial planning in GoB is extensive. A large amount of useful data already exists and a large portion of that is already openly available either as web mapping sites and/or downloadable datasets. The data is usually developed and maintained by national and international institutes. Especially, the Baltic Marine Environment Protection Commission (HELCOM), an intergovernmental cooperation body, collects, maintains, and provides a significant database on various aspects of the Baltic Sea. The data can broadly be divided into designated areas and boundaries; physical, chemical, biological, and ecological data describing the sea areas and species living there; and data about human activities.

An important data collection effort regarding the management of Finnish coasts and seas is the collaborative Finnish Inventory Programme for the Underwater Marine Environment (VELMU), where a large amount of data about underwater environment (e.g. abundance of keystone species and locations fish nursery grounds) has been collected since 2004. In VELMU, species specific data is extracted from the observations, such as underwater videos, and organized into geospatial layers, which are further used for species distribution modeling and other purposes. VELMU data is published on a web-mapping platform 4 .

Other examples of data that is available or that is being collected and developed for the project are wind conditions 5 , areas of importance for fisheries (surveys are being done by the Natural Resources Institute Finland), climate scenarios (developed by the Swedish Meteorological and Hydrological Institute), and the current and projected future oceanographic conditions (modeling and simulations carried out by the Finnish Meteorological Institute).

Spatial Data Infrastructure

Spatial Data Infrastructure (SDI) is a framework in which geographic data and metadata is made available for users and tools. When a connection between spatial data and its users is or is not a SDI is a debatable question but several characteristics has been given by researchers and practitioners. These include the use of specific technologies, such as the Internet, standards for data exchange and storage, policies for openness and other issues, and services for software applications and humans. The concept of Coastal/Marine SDI has been studied and promoted by the Global Spatial Data Infrastructure Association (GSDI) and the recently established Open Geospatial Consortium (OGC) Marine Domain Working Group.

The public SDI in Finland is based on INSPIRE (an EU SDI initiative) and implemented for example as a generic catalog 6 , a generic data browser 7 , and services maintained by individual institutes. A good example of what even a private individual can do with open marine data is the website aaltopoiju.fi, which presents current and historical meteorological and oceanographic data on a map interface.

Collaborative modeling

MSP requires collaborative modeling because its aim is to bring together relevant information from several sectors, and biological, geological, and oceanographic knowledge needs be integrated with information about human drivers. At each sector modeling is needed to produce data that is comprehensive and/or further developed/computed from the observation data. At the planning stage these data need to be integrated, which again requires modeling.

In SmartSea, the project partners bring in geological, oceanographic, biological, social, and economic models. The NEMO-Nordic ocean modeling framework [START_REF] Hordoir | Influence of sea level rise on the dynamics of salt inflows in the Baltic Sea[END_REF] will be used to obtain water temperature, salinity, mean circulation, sea level, and ice extent scenarios in one nautical mile resolution. Simulations will be based on existing data from years 1980-2010 and the future conditions will be based on climate scenarios for the years 2030-2060. processing is required. Use of specific planning method tools usually requires lengthy data collection and preprocessing efforts. The private or local information environment can also greatly differ from the information environment shared among national, and especially international, MSP. Fig. 1. Information environment as a place where data and information from providers become available for users with needs.

The promises and goals of spatial data infrastructures, such as the European INSPIRE, has been multiple [13]: datasets are collected and kept at one location, where it originates or where it can be maintained most effectively; different data can be combined seamlessly together; data can be obtained at varying scales and levels, depending on the type of investigation at hand; and information about availability, usability, and constraints of data is easily available. While there has been progress towards these goals, it is still a challenge to bring existing data into MSP information environment due to reasons such as data size and format; and lack of suitable data or other service.

Typically, MSP requires new, specific datasets to be developed. These can be original datasets obtained by field research, or created with models of natural systems or human preferences. We see challenges in bringing these into the MSP information environment due to semantic problems created by differences in the user and provider communities, data interpretation requirements, and the level of collaboration required.

There are typically several software systems available or in operation in an information environment. Software systems need, in order to work efficiently, interoperability, which may take various forms and is one of the aspects of software architecture. MSP is, like planning in general, an activity where information is continuously added and processed until the result is satisfactory. The information environment is unbounded in this sense. Thus flexibility towards new information sources, and support for provenance become key properties of the overall system.

A Vision for the SmartSea MSP toolbox

MSP is a process that implements risk-averse ecosystem-based management of coastal and marine areas into practice, and enables integrated, forward-looking and consistent decision-making [START_REF] Ehler | Marine Spatial Planning: a step-by-step approach toward ecosystem-based management[END_REF][START_REF] Stelzenmüller | Practical tools to support marine spatial planning: A review and some prototype tools[END_REF]. In addition, it is an instrument whereby relevant stakeholder groups can be involved in a transparent manner. In MSP, planners assess the cumulative effects of human pressures and seek to make the use of marine resources more sustainable and proactively minimize the conflicts between sectors.

SmartSea aims is to provide information to MSP and to develop scientifically sound tools for risk analysis and decision-making. Gulf of Bothnia, the initial spatial context of the MSP toolbox spans six administrative regions in Finland. Regions are the first administrative division below the country itself. A region has a large autonomy in spatial planning, which adds a dimension to the overall national MSP.

Traditionally, MSP is based on static environmental data. However, considering ongoing climate change, any long-term plans should consider projected changes in the environmental parameters. In the GoB, the most apparent changes will be the increasing sea temperature, reducing ice cover, and decreasing salinity. All these will have considerable impacts on marine biota from plankton to fish species but they will also have an impact on fish farming and other marine related businesses and their possibilities.

The suitability of an off-shore location for activities depends on oceanographic, like wave height, sea level, sea surface temperature, and ice loads and geological conditions, like seabed substrate. A desirable feature of an MSP toolbox is thus to be able to consider return periods of extreme events and their characteristics.

The fundamental requirements for the SmartSea MSP toolbox have been identified as supporting identifying what could and what should not be done in various areas of the region, what would be the value and impacts of the activities, and where specific activities should be placed. These involve collection, analysis, and integration of spatial data that is relevant to possible uses of sea areas, information about gained benefits and ecological impacts of activities, and a consideration for shared use of areas.

Generic requirements for the SmartSea MSP toolbox are visualization of spatial data, both independently and as overlays to detect spatial competition. Modeling can be partially offline but for ad hoc type of queries and plans interactive use of some models will probably be needed. Design capabilities are needed for creating plans. Supporting collaborative and participatory planning requires tools for analyzing competing plans, capabilities for shared use, and visualization.

In a previous project 8 we developed a demonstration MSP tool. The tool was based on a workflow, where pressures from human activities and the current environmental state were first coded on spatial rasters of the planning region. Second, the competing plans were devised and their local and spatially distributed impacts were computed and stored as compatible rasters. In the third and final step, valuation weights were computed for impacts and the plans could be ranked based on a resulting single indicator value for each plan. The local and spatial impact and valuation computations were based on models implemented as Bayesian Networks. The tool was implemented as a QGIS (community developed free and open source GIS) 9 plugin.

Components of the SmartSea MSP toolbox

The SmartSea MSP toolbox is planned as a distributed application with one server and two types of clients. A work-in-progress setup of services has been developed on a server computer in a cloud infrastructure. The server hosts a database and services that build on it. The database comprises spatial data and data supporting the planning process. The services can provide data for desktop software such as QGIS and for applications running in a web browser. A simple web browser application for visualizing sectoral values, zoning plans, and competition was developed. Its core functionality is based on a WMTS service, which can dynamically compute spatial layers from existing layers based on simple rules. A goal is to be able to describe the logic of computing the value and impacts of, stimulating, allowing, and/or denying activities in areas as functions of the characteristics of those areas and activities as a set of sequentially applied rules. The source code for the toolbox is available at github 10 .

The Database

The database is implemented on a RDBMS (PostgreSQL+PostGIS) installation in addition to files in filesystem and it consists of three parts: the tool, the data catalog, and the datasets. The tool part is based on a data model for planning, which consists of core classes Plan, Impact, Layer, and Rule (See Figure 2.). A plan is a comprehensive allocation of zones in the planning region. A zone is assumed to have a designed use, which is a realization of a designed use class, which may comprise several activities. An activity should be a well-defined description of a single enterprise or a ban of such 11 . Thus it is possible to compute both the benefits and the negative impacts of a use for an area. It is clear that the composition of this kind of uses is a large task in itself.

An (environmental) impact is something that an activity causes. The activity -impact mapping is done via an environmental pressure as the EU Marine Strategy Framework Directive instructs. In the quantitative assessment, an attempt is made to determine numerically the probabilities of different pressures and the likely extent of the losses under a particular pressure. Several alternatives can be used to define the probability distributions attached to the pressures. These include, for example, statistical datasets, experimental data, modeling outputs, and expert knowledge. Expert assessments of relationships between activities, pressures, and impacts on ecosystem components have been obtained in other projects 12 . Structured expert judgement can be integrated into modeling approaches to improve predictions, and it can be particularly valuable if no relevant published data can be found. Further, as managers might believe that models do not result in better decisions than those supported by the opinions of experts, expert-informed modeling can contribute to bridging the gap between researchers and decision-makers [START_REF] Addison | Practical solutions for making models indispensable in conservation decisionmaking[END_REF][START_REF] Aizpurua | Reconciling expert judgement and habitat suitability models as tools for guiding sampling of threatened species[END_REF]. Experts give estimates for what pressures various activities create, what is their spatial range, how serious the impact of the generated pressure is to a range of ecological components, and how strongly the experts believe in their estimates. This data may be enough (assuming additional expert data is available, e.g., to account for cumulative impacts) to compute impacts of zoning proposals. However, this part of the project is still ongoing. Comprehensiveness of this kind of data is of course an issue since both the range of possible activities and ecological components is very wide. Based on the obtained results from the impact assessment, a decision analysis between the demand for marine resources and conservation of nature values will be performed.

A layer is a spatial dataset, prepared by the system as a 20 m x 20 m raster covering the planning region 13 . A layer represents an attribute (the layer class) associated with a use and it is obtained from a SDI or computed from datasets or other layers using rules. A rule is a mathematical expression for computing a layer from datasets or other layers. A rule consists of several elementary rules, which are combined in a specific way (the rule class). Rules can be combined exclusively, i.e., locations are deemed unsuitable for a use because of its characteristics; inclusively, i.e. locations are deemed suitable for some use because of its characteristics; multiplicatively, i.e., the value at a location is computed by multiplying values representing characteristics of it; or additively, i.e., the value at a location is computed by summing values representing characteristics of it.

Fig. 2. A diagram of important classes and their relationships in the prototype MSP toolbox,

see the text for explanations.

A layer can depict the value or benefit obtained from a specific activity or use, depict areas designated for a specific use or the suitability of locations for the use, or it can describe the impact of a use. The style is information how a dataset or a layer is visualized.

The data catalog is a simple database of metadata and provenance information that describes the datasets used by the planning tool. Its purpose is to document the origin of data and the workflow that was applied to prepare the data for the tool. The MSP toolbox will contain several datasets obtained and/or derived both from the national SDI and from research projects within the SmartSea umbrella and elsewhere. In order to retain this information and possibly reapply the workflow in the case of new versions of the original data come available, the provenance of the datasets must be kept.

The Web Services

Since the data is maintained on a server in a cloud, it is natural to provide an API to it as web services besides the native database interface and raw file download. The web services are divided into non-spatial and spatial services. The spatial services are OGC services and the non-spatial services are custom services providing JSON for applications and HTML for human users.

The spatial data services focus on WMTS (a raster tile service), which is ideal for creating responsive web mapping applications that need to cover large areas but also provide detailed views (using graduated zoom levels). In this project we defined a use case, where WMTS should provide layers that could be computed from several original layers using several rules and optionally the user should be able to edit the rules online. This clearly is not feasible using pre-computed layers. It also requires the concept of user in the service providing code so that it can use the correct parameter values for the rules when preparing tiles to the respective users. The current solution skips the capability document (thus the list of the available layers is not provided and the client program of the service must know how the layer names are constructed) but is able to compute layers very flexibly. The computation is based on coded layer names, where the code specifies the plan, the use, the type of layer, and the rules to use.

Another type of spatial service is one that is used to provide information from a selected location / area. The client sends the selected location or polygon area as WKT and information that tells, which (spatial) data to use for the reply, and based on those, the service computes a reply.

The non-spatial data services has two purposes: 1) to provide a document for applications, which lists the plans, uses, layers, and rules, that is, data to populate the GUI and also to construct WMTS requests (the layer names); and 2) to provide an interface to construct the plans, uses, and rules. The importance and complexity of this API was a finding for us in this research. The API is still developing since the database is developing but the overall structure is already quite stable. The construct API is a simple CRUD (create, read, update, delete) API and currently focuses on direct interactive use by humans and thus HTML. With this API the user is able to manage the objects in the database and their relations. The relationships are either associations (for example a use class is associated with one or more activities), compositions (for example a plan is composed of uses), or multiplicity (for example a use can have only one use class but multiple associated layers). The document API is there for client applications to obtain the tree-like data structure of plans, uses in them, layers in the uses, and the rules that are used to create the layers.

The web services were developed as Perl modules using the Starman web server14 and Perl modules related to it. The object-relational mapping is done using DBIx::Class 15 . The Perl Data Language (PDL) is used for raster computations and GDAL is used for spatial data access and management.

The Web Mapping Application

The focus of the user oriented development in the project has so far been on the web mapping application. The application is written in JavaScript using JQuery and OpenLayers libraries and it is according to the MVC design pattern 16 . The application presents the user an interface that relies of the plan-use-layer-rule model of the planning problem (See Figure 3.). Additionally, the GUI contains a select location / areainformation tool.

The plan-use-layer-rule model upends the traditional GIS interface paradigm, which guides the user to construct maps from input data layers, which are presented.

Here the result (the zoning or spatial allocation of uses) is what is presented to the user. Initially the whole region allocated for all uses and the paradigm is that the rules reduce (or add) the areas for uses.

The select location / area tool allows the user to select a location with a click or draw a polygon with a sequence of clicks. Once defined, the location or the polygon (as WKT) is sent to a server along with other selections made in the GUI, and the server reply is shown to the user. Currently this tool is a proof-of-concept only. Fig. 3. A screenshot of the web mapping application prototype showing a selected plan (SmartSea), a visualized and selected computed allocation of areas for offshore wind farms (essentially a suggestion for manual design), and a dialog box allowing the user to edit one rule.

5.4

The Desktop Tool Some of the tasks in MSP are unstructured and require generic tools capable of analysis and providing decision support. A desktop GIS is a typical generic tool for tasks that involve a spatial dimension. SmartSea project will develop open and freely available tools and QGIS was selected as the desktop tool for the SmartSea MSP toolbox.

The goal is to develop a QGIS plugin, which integrates with the other components of the toolbox. Currently very little has been done to further this task. Python is the main programming language for developing QGIS plugins and it is relatively easy to create one. In an initial test it was possible with a few lines of Python code to download the main GUI document in JSON from the web service and construct a tree of layers in the QGIS layer list in its GUI and download the WMTS layers. This is the first requirement since the WMTS server does not provide a layer list to choose from.

Discussion

MSP, despite being a novel topic, is a variation of the general theme of spatial planning. Numerous examples of how spatial planning can be supported with information technology exist.

Our vision for the SmartSea MSP toolbox is based on examples found in literature and our previous work. The toolbox will be based on an existing SDI but specific support needs to be built for representing zoning plans, impact computations, and negotiating between competing plans and sectoral needs.

The development of the application has so far been carried out completely within the research institute and all discussions related to its requirements and design have been among researchers. A public seminar organized by the Ministry of Environment announcing MSP in Finland was held in November 2016. The seminar revealed that only the administrative structure of MSP has been decided upon. The SmartSea project is a key endeavor towards supporting the actual planning. A series of workshops and collaboration will be organized for transferring knowledge and tools from the research community to the planning community.

INSPIRE is the directive defining the European SDI. One of its principles is that "it should be possible to combine seamless spatial information from different sources ... and share it with many users and applications" [16]. In our case the identified requirement to be able to dynamically compose planning proposals required us to download data from their sources to a dedicated server, which took care of the composition. This was in some cases necessary since the data was always not available as a service, or it needed some preprocessing. In those cases where the data was availa-ble as a service, moving it was considered a too fragile or slow operation to be a part of the MSP toolbox.

In a client-server environment for geospatial computing the map that is shown to the user can be rendered in the server or in the client from data sent by the server. If the data is dynamically changing, or, as in our case, the user has a great control over how the map is composed, the map needs to be generated dynamically. It is interesting that in the case of server side dynamically generated maps are usually considered only in relation to WMS and specifically not WMTS, which is seen as a set of statically rendered tiles17 . In our case creating a plugin system for dynamically rendering raster tiles was easy since the WMTS code was developed by the main author.

MSP should be carried out with tools, which take account of uncertainties and are supported by a strong scientific background. We hope that the SmartSea MSP toolbox can eventually help to solve and structure complex and multidisciplinary problems, integrate knowledge and uncertainty, and communicate risks. Our approach identifies and quantifies explicit decisions among different objectives and represents spatial possibilities for sustainable blue growth. This work will be further developed to a decision analytic tool, which will provide a scientifically sound and consistent valuation method for evidence-based MSP.

  datasets •Preprocessing •Collect provenance Develop Use-Activity-Impact scheme Develop spatial planning models •Value, suitability, and allocation for uses •Select method, criteria, and weights Location-based information services •Spatial extent: location/area •Various types of information •Measurement-based •Values, Uses •Model-based knowledge Information environment Planners Decision makers

http://www.msp-platform.eu

www.marinemap.org

www.seasketch.org)

http://paikkatieto.ymparisto.fi/velmu

http://www.tuuliatlas.fi/en/index.html is a website based on the wind data. It provides maps of average wind speed and estimated wind power production.

An information system for MSPMSP is a series of undertakings by planners and eventually decision makers to organize human activities on a sea area. We shall call the planners and decision makers as the 'users' of the information system for MSP. Goals of MSP comprise conflict minimization, ensuring viability of businesses, maintaining sustainability of the marine environment, and achieving maximal social benefits. Users need data, information, and knowledge together with social values, criteria, and goals. We shall call these the 'materials' of the information system. The users obtain the materials from data providers, science community, and various stakeholders, who we shall collectively call 'providers'.The information environment (Figure1.) has been defined[START_REF]information environment[END_REF] as the aggregate of individuals, organizations, or systems that collect, process, or disseminate information; and the information itself. The users' information environment dictates how well they can carry out their planning and decision making tasks. The state-of-the-art information environment in MSP is multifaceted: use of diverse Internet sources, official organizational data channels, elicitation of expert knowledge and stakeholder values, and personal efforts. Organization of these materials for planning, so that they can be used together in personal or organization information systems or software tools depends on they being in suitable formats. Otherwise manual data conversions and/or 6 http://www.paikkatietohakemisto.fi 7 http://www.paikkatietoikkuna.fi

Transboundary tools for spatial planning and conservation of the Gulf of Finland (TOPCONS) http://www.merikotka.fi/topcons/

http://qgis.org

https://github.com/ajolma/SmartSeaMSPTool

The description may, depending on what kind of MSP policy is adopted, include temporal and other conditions and thus be quite complex in the end.

These are mostly projects done within the HELCOM collaboration and include projects HOLAS II, TAPAS, and MARISPLAN.

It is possible to create such a raster layer or input for one from a vector layer on-the-fly using rasterization.

http://search.cpan.org/dist/Starman

http://www.dbix-class.org

The code from https://alexatnet.com/articles/model-view-controller-mvc-javascript was used as a boilerplate.

See for example the topic "Dynamically drawn map services" in the Penn State University course GEOG 585 at https://www.e-education.psu.edu/geog585/node/697

Acknowledgements. We wish to acknowledge the funding received from the Strategic Research Council at Academy of Finland for the project SmartSea -Gulf of Bothnia as Resource for Sustainable Growth (Grant No: 292 985). We also acknowledge the editors of these proceedings and the anonymous reviewers for their work. Their comments significantly improved this paper.