Michal Kepka
email: mkepka@kgm.zcu.cz

Karel Charvát

Marek Šplíchal
email: splichal@ccss.cz

Zbyněk Křivánek
email: krivanek@ccss.cz

Marek Musil
email: musil@ccss.cz

Šimon Leitgeb
email: leitgeb.simon@gmail.com

Dmitrij Kožuch

Raitis Bērziņš
email: raitisbe@gmail.com

The SensLog Platform -A Solution for Sensors and Citizen Observatories

Keywords: Sensors, VGI, SensLog, Citizen Observatories, Open Data;

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

Introduction

Sensors are an important part of data producers, especially in the field of spatial data.

There are large number of sensor data available on the Web in variety of formats encoding. Wide-ranging services and solutions for sensor data publishing for different type of sensors are usually very complex and complicated for non-expert users. The authors address this problem by designing tools and processes for effortless and straightforward utilization of existing sensors available on the Web. This work has been done in the scope of the Open Sensors Network pilot as part of the SDI4Apps project [START_REF] Kepka | Server-side solution for sensor data[END_REF] .

Reusing existing sensors operated by third-party providers is currently problematic. The problems range from initial search of services through metadata description of sensors to filtering of found sensor candidates. It could be understood as searching for suitable repairman company in yellow pages. In the same way, it would be useful to find some "yellow pages" for searching appropriate sensors and sensor data producers on the Web. A good starting point for reusing sensors is to find the rate between usability and complexity of sensor services and providing them straightforwardly. The SensLog application described in following paper can be given as an example of sensor data management for small and medium sensor networks. SensLog serves a data provider as a tool for collecting, processing and publishing of sensor data on the Web. SensLog allows to receive measurements from sensor networks (from sensors, gateways or by intermediate daemons) through defined web services. Received data are processed and stored in a data storage. Stored data can be published for data consumers by different web services in various formats and metadata of registered sensors can be exported to semantic sensor catalogues together with the endpoint description.

SensLog

SensLog is a software component for sensor data management on the Web. SensLog receives sensor data by requests over HTTP protocol and stores them in a database. SensLog publishes raw and/or processed sensor data using several interfaces. One of the communication interfaces is proprietary-defined but extensive RESTful API publishing data mostly in the JSON format. Another interface is based on the core methods of the OGC Sensor Observation Service2 version 1.0.0 standard. SensLog has also a simple graphical user interface (GUI) with several functions to visualize data. However, the application is intended to be used in combination with other standalone clients.

The SensLog application was designed as a modular solution from the very beginning. New modules were developed and tested during contemporary projects including SDI4Apps, FOODIE [START_REF] Reznik | Open Data Model for (Precision) Agriculture Applications and Agricultural Pollution Monitoring[END_REF] and OTN4 ). A module for collecting volunteered geographic information (VGI) was designed and developed with the emphasis on character and properties of such type of data. The expansion of precision farming utilization has affected the design and development of another SensLog module for telemetry of agricultural machinery. Both new modules are based on the SensLog core functions, methods and modules providing extensions to the current interfaces. The server-side part of SensLog is written in the Java programming language. The database part is written in the PL/SQL language and the Web GUI uses the JavaScript jQuery library.

The SensLog data model

The SensLog data model is based on the OGC Observations & Measurements 1.0 standard. The model was further extended based on requirements provided by the SDI4Apps, FOODIE and OTN projects. The SensLog data model is used for storage of raw sensor data and results of data analyses. A diagram of the last version of the SensLog data model is shown in Figure 1. The core tables of the model include units, sensors, phenomenons, observations and units_positions. The object unit represents a physical device that has got one or more connected sensors which are producing observations. A unit can be equipped with a GNSS chip to periodically determine its own position (e.g. in case of mobile devices monitoring), or the position of the unit can be defined by another method (e.g. in case of static in-situ monitoring).

The SensLog data model was recently improved especially for potentially large tables. The observations and units_positions tables are the largest ones. Their volume is growing in coherence with continuous data monitoring. These tables were supplemented with a table partitioning mechanism (shown as series of tables in Figure 1). The core SensLog model was extended by tables defined by the new VGI and telemetry modules. The consistency of stored data is ensured not only by the referential integrity but also by the system of triggers and stored functions. The consistency is ensured especially in the case that extension tables are stored in separate database schemas. In this way, child tables of partitioned observations and unit positions allow better querying, backing up and maintenance. The SensLog data model was implemented in RDBMS PostgreSQL 9.x+ with spatial extension PostGIS 2.x+.

SensLog VGI module

The importance of VGI is growing in present days and current projects brought requirements on incorporating this type of data into SensLog. The character of VGI does not allow to store such type of data directly to the present SensLog data model without loss of information. Therefore, a new module for VGI was designed and implemented. This VGI module contains new services for receiving and publishing data over the Web. The SensLog data model was extended with new tables with emphasis on variability of VGI. A VGI observation is characterized by several mandatory attributes and can be enriched with additional attributes. It's not necessary to define the final number and names of additional attributes before starting collecting VGI. The datatype of an additional attribute is only limited to data types which values can be stored in the JSON format. A VGI observation can include a list of multimedia files that are also stored in the data model. A schema of tables of the VGI module is shown in Figure 2. A common type of VGI is a point of interest (POI). The concept of POI is similar to the general observation concept. The implemented scenario defined by the SDI4Apps project considers a POI as a spatially and temporally localized observation with several attributes and an array of connected multimedia files. Each POI is classified into one of the predefined categories and is sorted as a user-defined dataset.

Fig. 2. The data model of the SensLog VGI module

The tables added by the VGI module include:

• observations_vgi -this is the main table that stores VGI observations with all attributes except for multimedia content, • observations_vgi_media -this table stores multimedia files connected to VGI observations, • observations_vgi_category -this table stores categories of VGI observations, the table uses a partitioning mechanism to sort categories, • vgi_datasets -this table stores user-defined datasets with dataset metadata.

The VGI observation has got relations to some core tables of the SensLog model. The information about the device that produced the VGI observation is stored in the units table. The information about the user is stored in the system_users table. The main VGI geometry is a type of point and it is stored in the units_positions table. The geometry of VGI represents the point where the VGI observation was localized. An additional geometry of different type can be stored as an additional attribute. The categories of POIs can be stored in tables inherited from the master table observations_vgi_category. This enables to store different kinds of categories in a hierarchical order.

SensLog RDF export of VGI

In order to publish data according to the Open Linked Data best practices and with a self-describing data structure, the Virtuoso graph model engine is used. The data are stored in quads, which consist of a graph name describing a dataset and a triple which maps an attribute value (object) to POI (subject). The mapping is done by using a property which is in the best case scenario defined in some public ontology thus making it easier to integrate data with other systems. The data can be queried and inserted into the quad-store through the SPARQL endpoint at http://data.plan4all.eu/sparql or uploaded and parsed on the server via RDF files if the amount in one batch exceeds 100 megabytes. An insert operation for one POI can be seen in the following example:

SensLog interfaces

The publication of stored data is provided by the system of web services. The system of web services allows publication of stored data in different levels of detail and in various export formats. The modularity of SensLog allows to have a different interface for each module with specific web services according to the character of the following application. The diagram in Figure 4 shows the structure of SensLog modules along with the corresponding interfaces and formats provided by each module.

Fig. 4. Diagram of the structure of the SensLog modules

On the one side, there is the feeder module for inserting new observations and positions through methods of the HTTP protocol. The feeder module is independent from other modules which enables having an allocated database connection for continuous insertion. Only authenticated clients are allowed to insert new objects.

On the other side, there is provider module that contains the system of web services via methods of the HTTP protocol to publish stored data. The provider module uses mainly the RESTful interface publishing data in the JSON format in a proprietary-defined form. The provider module contains also a standardized interface based on the core methods of OGC SOS 1.0.0. The proprietary interface contains a wider range of services with a variety of data formats.

The VGI module has also the RESTful interface defined with an emphasis on character of the VGI observation object. A VGI observation can be inserted encoded in the JSON format or as a multipart form of data. The insertion of a new VGI observation is variable due to the possibility of pushing VGI observations from mobile applications. There is an option to store a plain VGI observation with mandatory attributes and to add multimedia contents afterwards (e.g. while having a better Internet connection). The stored VGI observations can be published encoded in the JSON format in a proprietary form or in the GeoJSON5 format as the Feature or FeatureCollection object. The connected multimedia files are addressed in a form of a direct URL. An exporting web service according to the requirements from the SDI4Apps project was designed. This exporting service publishes stored VGI observations encoded in the RDF format to be further processed in the Virtuoso system.

The telemetry module uses mainly the previously described feeder module for inserting observations and positions. The telemetry module defines only standalone web services for publishing analysis results on utilization of machinery and farm fields. The data are provided in the JSON format in a proprietary form or in case of any listings, data are provided in the textual CSV format.

The import of sensor data to SensLog is provided by the services of the feeder module in most cases. The pattern of services of the feeder module is straightforward without the necessity of any specially object mapping. An ordinary scenario is to insert data to SensLog when the data are observed. In exceptional cases, especially when the data connection is lost for longer time and observations are restored from flash memory of gateway, data can be pushed into the SensLog storage by a script in a batch. In case of very long time series that need to be imported, it is possible to import data directly to the database model by PL/SQL scripts.

SensLog applications

The modularity of SensLog allows its use in a variety of applications. Currently, the authors are supporting three types of sensors as pilots including the monitoring of the level and quality of ground water, utilization of a wide spectrum of sensors in precision farming and utilization of SensLog as a gateway for collecting VGI directly by users.

Groundwater monitoring

The water quality is dependent on several aspects including the crop type, irrigation method, soil types, groundwater levels, soil and water chemistry, nutrient loads, limits on chemicals, salt tolerance of crops, leaching of salts and management of drainage water. There are several barriers to the reuse of wastewater in agriculture. The key barrier is that many stakeholders do not view wastewater as a resource, even if adequately treated. The stakeholders see the energy costs for treating wastewater to an adequate standard as being prohibitively expensive. One of the aims of the project pilot is to utilize recent innovations to turn wastewater reuse into a profitable, socially beneficiary and environmentally safe solution. A number of phenomena are monitored in this pilot including chemical and physical properties of the surface and underground water. The observations are produced by sensors deployed in shallow wells and they are sent by gateway stations on the ground in defined intervals. The observations are processed and user-defined analyses are run. There is a system of alerts that is triggered in case of reaching some defined thresholds. The services of the provider module are publishing not only measured data but also results of analyses and alerts.

Agrometeorological monitoring

Agriculture requires collecting, storing, sharing and analyzing large quantities of spatially referenced data. Such type of data, to be used effectively, must be transferred between different hardware, software and organizations. These data flows present a hurdle to uptake of precision agriculture. The use of multitude of data models, formats, interfaces and reference systems is resulting in incompatibilities. The management of huge amounts of data is a challenge. Spatio-temporal data is increasingly collected by remote or in-situ sensors rather than by field campaigns. Wireless communications have several benefits, but also pose challenges to the data exchange reliability and power supply. Sensor calibration and deployment as well as the maintenance of sensors need resources and technical skills and increase the costs of data acquisition. The increasing of both the data amount and the data quality awareness issue highlighted importance. An important part of using sensors in agriculture is represented by tracking of agriculture machinery to provide analyses oriented not only on utilization of monitoring of particular machinery but also on intervention monitoring of a particular field. The combination of machinery data together with field information provides a higher level of economic evaluation. The screenshot in Figure 5 shows a client application visualizing results of analyses provided by the SensLog telemetry module.

VGI and Citizen Observatories

A human as a sensor, also referred to as VGI monitoring, represents collecting measurements and observations by users by portable devices. It is a typical way of collecting spatially referenced thematic data in the domain of Earth observations. The characteristics of such type of observations include high variability of attributes of not only primitive data types and an uncertainty in data accuracy. An example of collaboration between pilots is shown by collecting of POIs. The Smart Points of Interest6 (SPOI) data set was developed in the frame of the SDI4Apps project providing information as linked data. SensLog became a segment in the chain of collecting and updating user-defined POIs. SensLog provides services to push new POIs collected by users in the database on the one side and it provides export services to pull sets of POIs to final storage based on the Virtuoso server 7 on the other side. Screenshots of client mobile application for collecting POIs is shown in Figure 6.

Fig. 1 .

 1 Fig. 1. Diagram of the SensLog data model

Fig. 3 .

 3 Fig. 3. Visualization of POIs in the HSLayers-NG client

Fig. 5 .

 5 Fig. 5. Client application for visualization of analysis results

Fig. 6 .

 6 Fig. 6. Mobile application for collecting POIs. Main screen on the right and attributes of the selected POI on the left side.

SDI4Apps -Uptake of Open Geographic Information through Innovative Services Based on Linked Data (http://sdi4apps.eu/)

Open Geospatial Consortium standard Sensor Observation Service (http://www.opengeospatial.org/standards/sos)

[START_REF] Reznik | Open Data Model for (Precision) Agriculture Applications and Agricultural Pollution Monitoring[END_REF] FOODIE -Farm-Oriented Open Data In Europe (http://www.foodie-project.eu

/)[START_REF] Krivanek | Alert System in Case of Excess Drawing of Ground Water[END_REF] OTN -Open Transport Net (http://opentnet.eu)

http://geojson.org

SPOI -Smart Points of Interest (http://www.sdi4apps.eu/spoi/)

OMA -Open Mobile Alliance (http://openmobilealliance.org/)

Acknowledgement

This paper was supported by the SDI4Apps project (CIP-ICT-PSP-PB 621129) which has received funding from the EU ICT Policy Support Program as part of the Competitiveness and Innovation Framework Program. This paper was supported by the European Union Research and Innovation programme H2020 under the grant agreement No 732064 "Data-Driven Bioeconomy" (DataBio). The author Michal Kepka was supported by the Grant No. SGS-2016-004 "Využití matematiky a infromatiky v geomatice III," awarded by the University of West Bohemia.

INSERT DATA { GRAPH <http://www.sdi4apps.eu/poi.rdf> { <http://www.sdi4apps.eu/new_poi/c72cf4a7> <http://purl.org/dc/elements/1.1/identifier> "http://www.sdi4apps.eu/new_poi/c72cf4a7". <http://www.sdi4apps.eu/new_poi/c72cf4a7> <http://www.opengis.net/ont/geosparql#asWKT>"POINT(13.431 49.741)"^^virtrdf:Geometry. <http://www.sdi4apps.eu/new_poi/c72cf4a7> <http://www.openvoc.eu/poi#class> <http://gis.zcu.cz/SPOI/Ontology#bus_stop>. <http://www.sdi4apps.eu/new_poi/c72cf4a7> <http://purl.org/dc/elements/1.1/title>"New point" }}

The data visualization is performed through a web-based map client based on the HSLayers-NG library (Figure 3). Map layers are dynamically generated for each graph (dataset) and category (http://gis.zcu.cz/SPOI/Ontology#bus_stop in the above mentioned example in Fig. 3) which can be found in a particular dataset. Displaying of the triples is based on principle that each subject in a triple is displayed as a new vector (point) feature in the map. Likewise each property and object is converted to the feature's attribute and value in GIS terms. Styling of the features such as choosing an icon and color is based on attribute (category) values and is application specific.


Tomáš Řezník
email: tomas.reznik@sci.muni.cz

Karel Charvát
email: charvat@lesprojekt.cz

Vojtěch Lukas
email: vojtech.lukas@mendelu.cz

Karel Charvát Junior
email: charvat_junior@bosc.cz

Michal Kepka
email: kepka@ccss.cz

Šárka Horáková
email: horakova@lesprojekt.cz

Zbyněk Křivánek
email: krivanek@lesprojekt.cz

Helena Řezníková
email: reznikova@lesprojekt.cz

Open Farm Management Information System Supporting Ecological and Economical Tasks

Keywords: open data, precision agriculture, geospatial services, FMIS, yield potential, machinery monitoring

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

Introduction

The importance of the agricultural sector is evident due its strategic importance around the world. The different groups of stakeholders involved in agricultural activities have to manage many different and heterogeneous sources of information that need to be combined in order to make economically and environmentally sound decisions, which include (among others) the definition of policies (with respect to subsidies, standardisation and regulation, national strategies for rural development, climate change), the development of sustainable agriculture, crop recollection timing and pricing, and plague detection, etc.

In the agriculture domain, the period of the past 20 years may be characterized by a shift from (conventional) farming to precision farming. This shift is caused by increased demand for higher yield on one hand but increased concern for loss of biodiversity which is quite significant in agricultural regions [START_REF] Tscharntke | Landscape perspectives on agricultural intensification and biodiversity -ecosystem service management[END_REF], [START_REF] Skokanová | Changes of Ortolan Bunting (Emberiza hortulana L.) habitats and implications for the species presence in SE Moravia, Czech Republic[END_REF] and might be also one of the driving forces in using precision farming. Even though precision farming is in general considered as a form of intensive agriculture [START_REF] Tilman | Agricultural sustainability and intensive production practices[END_REF] due to the fact that it enables using exact necessary amount of fertilizers or pesticides in explicitly spatially delineated plots it could be considered as an additional tool in so called ecological intensification [START_REF] Cassman | Ecological intensification of cereal production systems: Yield potential, soil quality, and precision agriculture[END_REF] or conservation agriculture [START_REF] Kassam | Conservation agriculture: global perspectives and developments[END_REF].

Precision farming relies on geospatial data and functionality that are available through a Farm Management Information System (FMIS). Any FMIS may also be considered as a kind of Geographic Information System (GIS) as it provides answers to two basic questions: what has happened and where. FMIS effectiveness from the geospatial point of view is limited chiefly by a lack of accurate data. This is a paradoxical situation, since there are proprietary FMIS's on the one hand and requests for open data and services to power proprietary FMISs on the other. A way out may be found in the form of an Open Farm Management Information System (OpenFMIS). We would like to emphasize that an OpenFMIS also uses both open and proprietary data. Open data are used as inputs into an OpenFMIS, geospatial data being the best example; e.g. starting from satellite and aerial images through cadastre to zones where the usage of nitrogen is forbidden. Proprietary data typically comprise sensitive economic information like the turnover of a farm, the consumption of fertilizers/pesticides/fuels, the wages of employees etc. Proprietary data remain in the system, no matter whether it is an FMIS or an OpenFMIS. The greatest difference between an FMIS and OpenFMIS lies in the presence of open application programming interfaces that allow (mostly) the (re)use of data and/or the functionality offered by other open applications. An OpenFMIS is also capable of exporting non-protected data, such as the better geometrical representation of a field. An OpenFMIS also offers modularity, i.e. any component with reference to geospatial/information technology standards may be added or taken away.

Moreover, world-wide concepts like the Digital Earth and Global Earth Observation System of Systems (GEOSS) are the ideal candidates for the integration of such agricultural pollution data from around the world.

The European project "Farm-Oriented Open Data in Europe" (FOODIE), funded between the years 2014 and 2017, addresses the above-mentioned issues. The FOODIE project aims at building an open and interoperable specialized agricultural platform hub on the cloud for the management of spatial and non-spatial data relevant for farming production, for the discovery of spatial and non-spatial agriculture-related data from heterogeneous sources, for the integration of existing and valuable European open datasets related to agriculture, and for data publication and the data linking of external agriculture data sources contributed by different public and private stakeholders allowing for the provision of specific and high-value applications and services to support the planning and decision-making processes of different stakeholder groups related to the agricultural and environmental domains.

Functionalities provided by the platform

The FOODIE approach supports the better adoption of Information and Communication Technologies (ICT) and also enables better collaboration between different stakeholders across the agri-food chain. It supports trusted software models as services for the farming sector. This will help farmers employ new types of solutions without the necessary investment and also allow the easy integration of existing platform through interoperable interfaces. This approach also incorporates the support of mobility platforms -the accessing of information and knowledge everywhere, and also the integration of different devices into all systems -as well as guarantees the accessibility of different types of information.

The FOODIE platform aims at being the "glue" in-between the public and private sectors by acting as a central platform (e.g., a Land Parcel Identification System) ICT system combined with intelligent and underlying hardware and software infrastructure that allows the storage of farmers' data (unique land parcel ids inside a region, farming activities performed), landowners, land use, orthoimages, satellite data etc. An open data model for (precision) agriculture was defined as the backbone of the FOODIE platform, as described by [START_REF] Reznik | Open Data Model for (Precision) Agriculture Applications and Agricultural Pollution Monitoring[END_REF] and [START_REF] Palma | An INSPIRE-Based Vocabulary for the Publication of Agricultural Linked Data[END_REF]. Portions of these datasets would remain private (e.g., famer data) whereas others like orthoimages and satellite data plus derived data from all European Member States and other open datasets could be accessed and used by all other user groups besides the Ministry of a Member State. The EU Directive concerning the re-use of public sector information sets down the legal framework in this respect. This would definitely transform ICT use in agriculture and forestry. As seen in the previous section, the INSPIRE Directive also goes in the same direction; that is, to establish an infrastructure for spatial information in Europe for the purposes of EC environmental policies or activities which might have an impact on the environment (see also [START_REF] Skokanova | Can we combine structural functionality and landscape services assessments in order to estimate the impact of landscape structure on landscape services?[END_REF]).

In order to implement the FOODIE concept and the associated service platform hub, the project aims at accomplishing the following technological objectives:

• to make use of the existing spatial information resources and services for various domains coming from different initiatives like INSPIRE (INfrastructure for SPatial InfoRmation in Europe; see [START_REF] Reznik | Geographic information in the age of the INSPIRE Directive: discovery, download and use for geographical research[END_REF]), Copernicus, GNSS, Galileo, GEOSS (Global Earth Observation System of Systems); GBIF (Global Biodiversity Information Facility), and EUNIS (European Nature Information System) etc., in which the European Commission and the Member States have invested heavily over the past decade;

• to design and provide an open and interoperable geospatial platform hub on the cloud based on existing software components derived from research results and available solutions in the market (mostly open-source). These include: • the integration of external agriculture production and food market data using the principles of Open Linked Data, • the creation of an open and flexible lightweight Application Programming Interface (API) that allows private and public stakeholders in the agricultural and environmental area to publish their own datasets (e.g., datasets provided by local sensor networks deployed in situ in farms, and knowledge from farm communities and agricultural services companies, etc.) and make them available via the platform hub as open linked data (enabling them to be subject to further processing), • the creation of specific and high-value applications and services to support the planning and decision-making processes of different stakeholder groups, • the provision of security mechanisms to prevent the unauthorised access and use of the platform users' personal information as well as the data published by them, • the establishment of a marketplace where data can be discovered and exchanged but where external companies can also publish their own agricultural applications based on the data, services and applications provided by FOODIE.

The FOODIE platform offers two levels of functionality as defined in its business and exploitation model:

• open data relevant for (precision) farming in the most advanced exchangeable form possible; • added value services built on the top of open data to provide advice to the end users (such as farmers, consultant companies, environmentalists, policy makers, researchers, or citizens).

The first level functionality also includes a catalogue inventorying all available datasets and services to discover whether a FOODIE platform contains the desired data/services or not. The discovery concept originates from the INSPIRE domain [START_REF] Reznik | Normalized evaluation of the performance, capacity and availability of catalogue services: a pilot study based on INfrastruture for SPatial InfoRmation in Europe[END_REF], including the structure as well as the exchange format of metadata. Searching for data/services in the FOODIE catalogue is provided free of charge for all kinds of users. The FOODIE Catalogue respects the standards designed to publish and access digital metadata for geospatial data, services, and related (semantic) resource information as defined by [START_REF]Information and documentation --The Dublin Core metadata element set --Part 1: Core elements. International Organization for Standardization 12. ISO 19115:2003 Geographic information --Metadata[END_REF],

[12], [13], [14], [START_REF] Nebert | OpenGIS Catalogue Services Specification -version 2[END_REF] and [START_REF]DCAT application profile for data portals in Europe[END_REF]. The same also applies to the downloading of data, unless the particular owner of the data has imposed some restriction or condition on data sharing. The first level functionality is intended for users who are searching for European spatial data related to In concert with its five star rating, the FOODIE platform offers relevant data in one place at the highest possible level of data openness (see [Chyba! Nenalezen zdroj odkazů.]). For example, the Open Transport Network, which also includes unpaved rural roads, is being offered in the RDF through the SPARQL endpoint; meanwhile, satellite data from the Copernicus programme are in a machine readable georeferenced (TIFF) format.

Meanwhile, the second level functionality brings added value services derived from open (and sometimes also proprietary) data. For instance, an 8-year series of satellite images combined with other data allows the computation of yield potential, see Fig. 1. The yield potential concept of the FOODIE platform aims at establishing a general model for predicting yield potential zones for almost any kind of crop. Such added value services are being offered on the basis of payment through standardised Web interfaces, e.g. Open Geospatial Consortium's Web Processing Service.

Licenses are commercial for the second level functionality; individually set according to the purpose(s) of use, number of end users, included/excluded maintenance etc.

The functionality of added value services is described in the following sub-sections.The FOODIE architecture follows the so-called Service-Oriented Architecture, which enables orchestration between and beyond the FOODIE platform through standardized services. Open interfaces and formats, as defined by the Open Geospatial Consortium [Chyba! Nenalezen zdroj odkazů.], [Chyba! Nenalezen zdroj odkazů.], [START_REF]OpenGIS Web Processing Service Implementation Specification[END_REF] as well as [START_REF]OpenGIS Catalogue Service Specification -ISO Metadata Application Profile[END_REF] and/or World Wide Web Consortium [START_REF]RDF -Resource Description Format[END_REF] as well as [START_REF]SPARQL Query Language for RDF[END_REF] enable connections to various (external) systems (services) as well as to other layers of the FOODIE platform.

Yield potential

Yield potential zones are areas with the same yield level within fields. Yield is the integrator of landscape and climatic variability and, as such, it provides useful information for identifying management zones as defined by [START_REF] Evans | Yield Potential: Its Definition, Measurement, and Significance[END_REF] and [START_REF] Kleinjan | Productivity zones from multiple years of yield monitor data[END_REF]. This represents the basic delineation of management zones for site-specific crop management, which is usually based on yield maps for the past few years. The presence of complete series of yield maps for all fields is rare; thus, remotely sensed data are analysed to determine the field variability of crops through vegetation indices.

The yield potential concept of the FOODIE platform aims at establishing a general model for yield potential zones for almost any kind of crop. However, such universality comes at a price. The model is capable of expressing significant spatial variations for a given crop yield on a plot by distinguishing three kinds of values: below average, average, and above average. However, the model depicts spatial variations within a plot, and therefore it may be misleading when trying to compare yield zones between plots. Altogether, we may conclude that some areas in a plot have significantly lower productivity than others and take such information into the decision making process. However, we cannot determine that it is better to produce a crop on plot A or plot B.

So far, the ESPA (United States Geological Survey's Earth Resources Observation and Science Center Science Processing Architecture repository) of LANDSAT satellite images [START_REF]USGS Ups Ease of Use for Landsat Data[END_REF] is being used as the main data source, which offers surface reflectance products, main vegetation indices (NDVI, EVI; for details see [START_REF]Measuring vegetation[END_REF]), and cloud identification by the CFmask algorithm. A selection of scenes from the past eight years was made for a particular farm area in order to collect cloud-free data related to the second half of the vegetation period. Yield potential was calculated for separate scenes as the relation of each pixel to the mean value of the whole field. In the last step, all scenes were combined and the median value of yield potential was calculated. After the full operation of Sentinel 2A/B satellites, the calculation of yield potential will be enhanced by these vegetation products.

The concept of yield potential was successfully validated. It was proven that the whole evaluated farm, Tršická zemědělská in the Czech Republic, has the spatial variation of a yield potential equal to 80% when comparing yield results with estimations of the yield potential. The evaluated farm has acreage about 1,284 hectares. Ongoing research follows two main directions. The first one aims at optimising the algorithm to increase the probability of yield prediction up to 90%. Another direction of the current research focuses on the implementation of yield potential calculation as an open Web service, namely as an OGC Web Processing Service [START_REF]OpenGIS Web Processing Service Implementation Specification[END_REF].

2.2

Sensor monitoring

It goes without saying that the most precise data will always be the data gained through observations and measurements performed directly on the farm. This is partly true in the contemporary practices of precision agriculture. Sensor networks for atmospheric and meteorological conditions such as aerial and ground thermometers, anemometers, hygrometers etc. are available on farms [START_REF] Kubicek | Prototyping the visualization of geographic and sensor data for agriculture[END_REF]. Similar sensor networks for collecting information on soil conditions [START_REF] Feiden | Best Practice Network GS SOIL Promoting Access to European, Interoperable and INSPIRE Compliant Soil Information[END_REF] or ground water levels can also be established directly on farms. However, information on the application of treatments in certain places and at certain times may often be of significantly lower quality (see section 2.3 for details). The best data source in this respect is the tractor and its application machine. Issues related to the manual and aerial application of treatments are, however, beyond the scope of this paper. Sensor data collected on farms by different sensor networks are stored and managed by the SensLog application.

SensLog is a complex component of the FOODIE platform for collecting, storing, processing, analysing and publishing sensor data. SensLog receives observations and measurements from individual gateways deployed in farm fields by means of a system of Web services to the repositories of the FOODIE platform. The internet connections for deployed gateways can be realized by a number of methods; therefore, SensLog provides for variable usage. SensLog is capable of storing the observations and positions of mobile sensors in same way as for static sensors. Additional data sets can be provided by storing data in the database in different schemas. SensLog provides processing procedures and analytical functions to pre-process raw collected data or to detect alert events in operating sensor networks. Additional data sources can be involved in these analytical functions (e.g. the geometries of plots from LPIS, hydrography geometries, statistical data, zone pricing etc.). Such additional data sources are stored in the FOODIE platform and/or in external repositories.

The database schema of SensLog follows the ISO 19156 Observations and Measurements concept [START_REF]Geographic information --Observations and measurements[END_REF]. Extended functionality was implemented in the database model to fulfil all farmer requirements. Data are stored in a PostgreSQL (open source) database in version 9.3.6 together with its spatial extension PostGIS in version 2.1.0. In addition, the developed database schema has been replicated in the Cloud (Infrastructure as a Service) provided by the Poznań Supercomputing and Networking Center (in Poland) using OpenStack as an Open Source Cloud Computing Software.

Machinery fleet monitoring

Machinery fleet monitoring, abbreviated as MapLogAgri, is an extension of the SensLog component intended for collecting, storing, processing, analysing and publishing (near) real-time measurements of tractors and their application machines like spreaders or sprayers. Especially collecting, processing and analysing capabilities differ the most from the SensLog solution due to amount of data measured within one time frame.

As depicted in Fig. 3, a tractor contains a monitoring unit that is the centralised point from which it is possible to configure which data will be collected and how. A monitoring unit is connected to a GPS receiver to obtain the position of the tractor over the whole course of an agricultural intervention. The position of the application machine is computed from the position of the tractor and the size of the application machine. Communication between the tractor and the application machine is achieved through RFID (Radio Frequency Identification). The RFID interface enables the whole solution to be set as a modular one. It is then easy to combine any tractor with any application machine as far as they follow the same standards. The same applies to the ECU CAN/BUS (Electronic Control Unit Controlled Area Network) interface as a mediator between the monitoring unit and the software of the tractor.

Fig. 3. Communication scheme between a tractor and its application machine

To summarize, the whole solution consists in a set of hardware (e.g. the monitoring unit, GPS receiver) and software (e.g. ECU CAN/BUS and RFID interfaces as well as the user application). MapLogAgri may be understood as a hardware and software solution offering data for an OpenFMIS. The FOODIE system as a whole is then an example of an OpenFMIS.

Standardised communication exists also on the level of machinery sensor monitoring. ECU/CAN (Electronic Control Unit/Controlled Area Network) BUS represents a robust vehicle bus used in car industry, no matter whether it is a personal car or a bus [START_REF]CAN bus[END_REF]. On the contrary, so called ISO BUS is a specific definition of a universal protocol for electronic communication between tractors and computers originating from ISO 11783 standard -"Tractors and machinery for agriculture and forestry -Serial control and communications data network" [36]. So far (June 2017), ISO BUS is understood as a part of the Internet of Things concept [START_REF] Tervonen | Cognitive Internet-of-Things solutions enabled by wireless sensor and actuator networks[END_REF], however beyond the Industrial Internet Consortium (IIC [START_REF]Industrial Internet Consortium[END_REF] proven the need for a robust cloud-based geospatial solution since, in this case, ten megabytes of data were generated each day, i.e. when operating on a real commercial farm with almost 1,300 hectares. Geospatial data revealed significant differences between economic (e.g. fuel consumption or time needed to perform the same operation) and ecological characteristics (e.g. the number of fertilizer or pesticide applications as a result of an inappropriate trajectory); see also Fig. 4. The discovered differences are the subject of ongoing analyses.

Conclusions

The three presented modules, i.e. yield potential, sensor measurement, and machinery fleet monitoring, were developed to minimize the environmental burden arising from agricultural activities. All the modules aim to reduce the amount of fertilizer or pesticide applied during agricultural production, and thus to ensure that lower amounts of nutrients or chemical residues such as nitrogen appear in soil and/or (ground) water. That is, they should help to reduce the eutrophication of natural water sources. Therefore, the integration of these modules was adopted as part of the GEOSS AIP-8 (Global Earth Observation System of Systems' Architecture Implementation Pilot 8) targeting agricultural and water pollution.

The presented geospatial technologies focus on the environment during the agricultural planning phase, i.e. via yield potential monitoring, as well as during the application phase, where near real-time monitoring is supported by means of meteorological and hydrological sensors as well as by the machinery fleet monitoring module. The machinery fleet monitoring module was developed as a crowdsourcing extension of the sensor network concept (SensLog). In addition, an alerting service with an open (REST, Representation State Transfer) API was developed in order to forward notifications to environmental information systems and/or to iOS and Android based mobile devices.

The first discovered bottleneck lies in the general lack of farms producing yield results in the form of maps with sufficient detail (i.e. details of management zones within a plot). So far, only two such farms out of a possible thousand have been identified. Without such maps, spatial correlation between the theoretically computed yield potential on the one hand and yield results on the other is not feasible.

The second discovered bottleneck lies in the technological and licencing limitations relating to machinery fleet monitoring. Technological limitations arise from the various implementations of vague ISO/CAN bus standards by different machine manufacturers and from the need for tractors to have on-board computers. Licensing agreements prohibit farmers from buying machines. As a result, all data measured remain the property of the agricultural ma-chine producer.

The third discovered bottleneck lies in Big Data processing. For instance, yield potential was computed for the country of Luxembourg (an area of about 2'500 km2, i.e. 1'000 sq mi, com-prising some 92'000 plots) in order to verify the concept of transferability. The computation of yield potential through the Empirical Bayesian Kriging interpolation of Landsat 8, Sentinel 2, and MODIS (Moderate Resolution Imaging Spectroradiometer) satellite data, together with smoothing to a spatial resolution of 5 meters, took two weeks at the Poznań Supercomputing and Networking Center (64 computer nodes in the cloud, each node with two E5 2670 v2 / 2697 v3 @ 2.6GHz processors, an operational memory of 256GB, and a storage capacity of 40TB, connected via Fibre Channel, 50 TB Ceph via 10Gbit ethernet). PostgreSQL XL (Structured Query Language, eXtra Large), i.e. a version for cloud-based solutions, was found to be insufficient for the storage and processing of computed yield potential zones.

Ongoing research of the DataBio project focuses on the development of more efficient storage and processing capabilities in order to increase the performance of the provided yield potential-, sensor-, and machinery monitoring-related open Web services for environmental information systems. The improvement of yield potential computation is also a subject of further research.

Fig. 1 .

 1 Fig. 1. Yield potential map for one farm as a reference for ecologically and economically sound decisions

  agriculture and would like to process data themselves. Licenses are open for the first level functionality; Creative Commons Attribution Share Alike 4.0 [Chyba! Nenalezen zdroj odkazů.] for data components like data models and Open Data Commons Open Database License (ODbL) for databases [Chyba! Nenalezen zdroj odkazů.]. Searching and previewing capabilities are also available free of charge. Licenses are explicitly mentioned at each product (e.g. component, database) description typically at GitHub repository [Chyba! Nenalezen zdroj odkazů.] like [Chyba! Nenalezen zdroj odkazů.].

Fig. 2 .

 2 Fig. 2. Overview diagram of SensLog application and communication interfaces A system of Web services in several forms was developed to provide a variety of methods of data publishing. RESTful services publishing data in JSON format are used for operational usage and communication between FOODIE platform components. Services based on OGC Sensor Observation Service 1.0.0 core methods are used for the standardised publishing of data. An overview diagram of the SensLog application is shown in Fig. 2 above.

  ) activities. ISO BUS and ECU/CAN BUS are used for communication on the sensor level. Note that the latest versions of ISO BUS do not offer straightforward open communication as their predecessors did. It is an open question whether this is a consequence of a changing policy on the part of agricultural machine producers. Some of them have recently introduced a new business model where the farmer only rents agricultural machines. The license agreement prohibits the farmer from buying the machine. As a result, all the data measured remain the property of the agricultural machine producer. We have identified this change as a threat to the openness of machinery sensor monitoring.

Fig. 4 .

 4 Fig. 4. Environmental, economic and geospatial results of machinery sensor monitoringIn total, 9 tractors and 23 machines were monitored second by second on the "Tršice" farm in the Czech Republic from March 2015 till the end of 2016. Such monitoring has proven the need for a robust cloud-based geospatial solution since, in this case, ten megabytes of data were generated each day, i.e. when operating on a real commercial farm with almost 1,300 hectares. Geospatial data revealed significant differences between economic (e.g. fuel consumption or time needed to perform the same operation) and ecological characteristics (e.g. the number of fertilizer or pesticide applications as a result of an inappropriate trajectory); see also Fig.4. The discovered differences are the subject of ongoing analyses.

Acknowledgement

This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 732064 called "Data-Driven Bioeconomy" (DataBio), from the European Union's Seventh Framework Programme for research, technological development and demonstration under grant agreement No. 621074 titled "Farm-Oriented Open Data in Europe" (FOODIE); from the Horizon 2020 research and innovation programme under grant agreement No. 633945 designated "Farming Tools for external nutrient Inputs and water Management" (FATIMa); and from Grant No. MUNI/A/1419/2016, the "Integrated research of environmental changes in Earth's sphere II", awarded by Masaryk University, the Czech Republic.


G Veres

B Arbab-Zavar

J Lorenzo

T Habib

A Haugommard

F Martin

J.-M Zigna

G Weller

Z A Sabeur

G Correndo

EO Big Data Connectors and Analytics for Understanding the Effects of Climate Change on Migratory Trends of Marine Wildlife

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

Introduction

EO4wildlife brings large number of multidisciplinary scientists such as marine biologists, ecologists and ornithologists around the world to collaborate closely together while using European Sentinel Copernicus Earth Observations more efficiently.

In order to reach such important capability, an open service platform and interoperable toolbox is being designed and implemented. It offers data processing services that can be accessed by scientists to perform their respective research. The platform front end will be easy to use, access and it offers dedicated services that will enable scientists' process their geospatial environmental stimulations using Sentinel Earth Observation data and other observation sources. Specifically, the EO4wildlife platform will enable the integration of Sentinel data, ARGOS archive databases and real time thematic databank portals, including Wildlifetracking.org, Seabirdtracking.org, and other Earth Observation and MetOcean databases; locally or remotely, but simultaneously. EO4wildlife research specialises in the intelligent big data processing, advanced analytics and a Knowledge Base for wildlife migratory behaviour and trends forecasting. The research is leading to the development of web-enabled open services using OGC standards for sensor Observation and Measurements and data processing of heterogeneous geospatial observation data with estimated uncertainties. EO4wildlife designs, implements and validates various scenarios based on real operational use case requirements in the field of marine wildlife migrations, habitats and behaviour.

Global Architecture Overview

The EO4wildlife system is hosted in a SparkInData platform, which offers a set of core services for data discovery, data ingestion, process integration and execution. The SparkInData Platform, also known as Smart Elastic Enriched Earth Data (SEEED), is a generic platform which provides an EO data dedicated Cloud platform, infrastructure and services. Furthermore, the platform is organized under three functional zones, as shown in Figure 1 below.

Knowledge Base and Big Data Analytics

The Knowledge Base services are being developed in support of the overall EO4wildlife platform architecture. They are integrated with it for the support of the deployment of the big data analytics services to the Platform. The overall aim of the Knowledge Base services is to enhance the meta-data support provided by OGC standards in order to employ data semantics and interoperability at the data access service level. The ontologies developed within this module aim at covering the gap between data producers (e.g. Argos, Copernicus or the animal tracks data owners) and the data consumers (e.g. the scientists which will develop the workflows).

This is achieved through the provision of a common overarching representation of the heterogeneous entities that access the Big EO data sources and analytics. The Knowledge Base architecture is made of various services functionalities which are exposed to the platform as REST services. The services are deployed as a separate Docker container and it is supported by the Virtuoso triple store instance which is included in the SEEED platform.

Big Data Analytics

In order to provide proofs of concept of the EO4wildlife platform, a number of workflows based on specific domain studies of marine animal tracks are being developed. The more mature studies are presented in the following Sections.

Atlantic Bluefin Tuna Application Scenario

Atlantic Bluefin tuna (ABFT henceforth) is a highly migratory species which tolerates wide ranges of environmental conditions [START_REF] Arrizabalaga | Global habitat preferences of commercially valuable tuna[END_REF] in the Atlantic Ocean and Mediterranean Sea. In this section, we present initial attempts to correlate ABFT tracking data and environmental variables to identify different pattern of ABFT behaviour using Ecological Niche Modelling. The methodological steps undertaken to identify ABFT habitat preferences during different types of behaviour are inspired by [START_REF] Druon | Habitat suitability of the Atlantic bluefin tuna by size class: An ecological niche approach[END_REF] and depicted in Fig. 3.

Fig. 2. Workflow of Atlantic Bluefin tuna application

For animal tracks pre-processing the following services are offered: animal tracks reconstruction, discarding the location on the land and redundancy filtering which removes duplications in the tracks and any relocation points on the same day separated by less than 2.3 km. EO (Earth Observation) data pre-processing includes bringing all environmental variables to the same spatial and temporal resolutions, smoothing filters to recover spatial missing data, calculating 3-7 days composites for variables with temporally missing data and performing additional operations on data such as gradients calculations.

Specifying habitat of ABFT. Two patterns of behaviour can be observed for ABFT: spawning and feeding [START_REF] Arrizabalaga | Global habitat preferences of commercially valuable tuna[END_REF]. In the Mediterranean Sea, according to the literature spawning takes place between middle of May and middle of July months, while feeding is between mid-July and mid-September months, in the Mediterranean Sea or the North Atlantic Ocean. The following environmental variables were identified as relevant to influencing habitat utilization [START_REF] Druon | Habitat suitability of the Atlantic bluefin tuna by size class: An ecological niche approach[END_REF]: Daily sea surface temperatures (SST) and chlorophyll concentration (CHL) which can be used to calculate respective gradients and fronts; bathymetry; CO2 net Primary Production (PP); daily sea surface height anomaly (SSHa), ocean currents (eddies) and wind speed at sea surface level. several previous research papers [START_REF] Druon | Habitat suitability of the Atlantic bluefin tuna by size class: An ecological niche approach[END_REF] reported the specific environmental conditions which are favoured by ABFT for spawning and feeding activities. For spawning habitat, Bluefin tuna prefers warm waters of the Mediterranean Sea (SST in the range 20 to 25.5 o C) with increasing SST over several weeks, relatively low levels of CHL, intermediate levels of Eddy Kinetic Energy (EKE) and preferable range for SSHa. While for feeding habitat, ABFT prefer to locate in the vicinity of chlorophyll frontal features and higher levels of concentrations, wide range of SST and immediate levels of PP. These observations and analyses show that it should be possible to distinguish between feeding and spawning behaviors of ABTF when environmental variables are added to modelling. Environmental analysis. Our environmental analyses started with investigating visual correlation between ABFT tracks and environmental variables. It could be visually observed that some mean values of environmental variables have different ranges for spawning and feeding such mean SST (Fig. 4) and CHL (Fig. 5). Additionally, environmental variables with different ranges for spawning and feeding are SSHa, CO2 Net PP and Eddy Kinetic Energy (not shown due to space limitation). Note that though tracks for feeding (Adriatic Sea) and spawning (the Mediterranean Sea) do not cover exactly the same area, the difference in ranges between different behaviors are consistent with other findings in the Mediterranean Sea, i.e. This is due to different behavior of ABFT (spawning and feeding) to a large extent rather than due to different areas. However, further investigation will include more tracks from the Mediterranean Sea for both spawning and feeding to confirm these early findings. Further, the link between environmental variables and ABFT presence data will be analysed using a cluster analysis [START_REF] Rees | Conservation related insights into the behaviour of the olive ridley sea turtle Lepidochelys olivacea nesting in Oman[END_REF] and/or histogram approach. The cluster analysis is suitable for separating different behaviors that occur in distinct environments, for example feeding and spawning, or suitable and unsuitable habitats. K-means clustering can be explored for identifying the relevant thresholds for ecological variables (the most suitable for spawning), and overall environmental envelopes for feeding. When cluster analysis is used to define the relevant thresholds, the 15 th and 85 th percentile values can be used since they represent relatively extreme environmental boundaries while rejecting the potentially misclassified distribution tails [START_REF] Druon | Habitat suitability of the Atlantic bluefin tuna by size class: An ecological niche approach[END_REF]. Alternatively, a histogram approach may identify thresholds for environment variables with adding some uncertainty in the calculations due to the nature of tracking data. Since tracking devices report only where particular set of fish went, while we do not know the areas with no fish or indeed areas where other untracked fish went. We can overcome this difficulties to some extent by considering a presence/availability paradigm rather than a presence/absence model and generating potential tracks using a Null model movement paths based approach.

Habitat Modelling. Once the threshold values for environmental variables are set, the specific ecological niche of ABFT will be defined for feeding and spawning. An ecological niche model using environmental envelopes can be used to predict the daily suitability of cells within habitat for ABFT feeding and spawning on a given [0, 1] scale. The favorable habitat for each behavior are cells that meet all the suitable ranges of selected variables. This will be the next step of our services development.

Performance evaluation. The performance evaluation can be challenging due to a small number of tracks available and observations covering only presence of fish tracked. However we can compare our potential results with findings reported in the literature and by computing the distance between the presence data and the closest favourable habitat (3-day composite) for available tracks

Marine Turtle Application Scenario

Another exemplar data processing workflow which is being evaluated under the EO4wildlife platform as a proof of concept is the marine turtles application scenario. It is based on the workflow described by Pikesley et al. [START_REF] Pikesley | Modelling the niche for a marine vertebrate: a case study incorporating behavioural plasticity, proximate threats and climate change[END_REF]. 21 female Olive ridley turtles are tracked between 2007 and 2010 in the south-east of the Atlantic ocean near the west-African coast [START_REF] Pikesley | On the front line: integrated habitat mapping for olive ridley sea turtles in the southeast Atlantic[END_REF]. The aim is to describe the observed and potential post-nesting habitat for these species in the region. This will also be important for the fishing industries in the region to become aware of areas with the presence of turtles that could potentially lead to their unnecessary bycatch. A similar approach is taken in [START_REF] Pikesley | Modelling the niche for a marine vertebrate: a case study incorporating behavioural plasticity, proximate threats and climate change[END_REF], where 32 adult loggerhead turtles are tracked in the eastern part of the Atlantic. This work investigated how the predicted habitat may alter following climate change. Fig. 6 depicts the workflow which is implemented within EO4wildlife's sea turtle scenario. It is based on the analysis described by Pikesley et al. in [START_REF] Pikesley | Modelling the niche for a marine vertebrate: a case study incorporating behavioural plasticity, proximate threats and climate change[END_REF].

Fig. 5. Marine Turtle workflow

Other approaches describing the marine turtles' behaviour have also been considered and may be looked upon for further workflows in the marine turtle scenario. These workflows look at different sea turtle behaviors including: nesting activity and clutch frequency [START_REF] Rees | Conservation related insights into the behaviour of the olive ridley sea turtle Lepidochelys olivacea nesting in Oman[END_REF] and post-nesting migration and foraging behavior [START_REF] Chambault | The influence of oceanographic features on the foraging behavior of the olive ridley sea turtle Lepidochelys olivacea along the Guiana coast[END_REF]. Habitat modelling via ecological niche modelling is one of the more systematic ways of analysing species distribution under climatic changes. Other climate change scenarios should be considered to make the causal projections of environmental variables. A Spearman's rank correlation test will then be calculated for each paired environmental variables. These environmental variables are sampled from long-term mean values at the location of track points. Twenty five tracks of adult loggerhead sea turtles are being evaluated during their post-nesting movements near the west coast of Africa. This data includes samples from Aug 2004 to Dec 2009, where in some of the turtles are tracked for a short time and some for longer periods. The considered environmental variables include: 1) Sea Surface Temperature; 2) Bathymetry; 3) Sea surface Height (Absolute Dynamic Topography); 4) Net Primary Production; 5) Current Velocity; and 6) Eddies. These environmental conditions were used and based on their previous reported correlations with marine turtle relocations [START_REF] Pikesley | Modelling the niche for a marine vertebrate: a case study incorporating behavioural plasticity, proximate threats and climate change[END_REF], [START_REF] Pikesley | On the front line: integrated habitat mapping for olive ridley sea turtles in the southeast Atlantic[END_REF], [START_REF] Chambault | The influence of oceanographic features on the foraging behavior of the olive ridley sea turtle Lepidochelys olivacea along the Guiana coast[END_REF]. Fig. 8 shows the long-term mean of some of these variables that are superimposed with the species track points.

Web-Enabled Data Analytics Services

The data analytics based approaches of Section 2.2 are being wrapped as open web services. They have been specifically designed with fundamental capabilities that are exposed as OGC compliant WPS services [START_REF] Mueller | OGC WPS 2.0 Interface Standard[END_REF]. This will also ease their integration in the overall SEEED big data platform architecture and increase their reusability between applications. These services have been implemented as Docker containers [START_REF] Merkel | Docker: Lightweight Linux Containers for Consistent Development and Deployment[END_REF] whose instantiation is managed via the Kubernetes API. The adoption of Docker technologies ensures that the services' implementations are self-contained and their dependencies explicitly declared by means of Docker files. This is for the purpose of their invocation accordingly with respective to given input parameters to the data analytics processing algorithms. The deployment structure of such services in depicted in Fig. 9 The resulting open web processing services are grouped in three main categories: data pre-processing and aggregation, data mining services and high level fusion services. The high level fusion services are those which group all the intelligent post-processing of data analytics, forecasting and reasoning through knowledge modelling.

Data Pre-processing and Aggregation

This category contains the services for the pre-processing, cleaning and aggregation of the data prior to data analytics. The pre-processing of geospatial data sets is an important step when dealing with potentially incorrect information such as non-plausible animal positions. These services allow the recognition and removal of all data elements which are clearly unrealistic given the knowledge of the domain (e.g. the animal is not capable of travelling at such velocities, or producing abrupt changes of directions or; again travelling inland). Moreover the pre-processing services allow the filling of missing data values and accommodation of different data grids using interpolations which are not directly collected and represented in the data sets. The aggregation service allows the reconciliation of data which represented with different spatial or temporal resolutions. It also provides functionalities to sample environmental observations and aggregate them into the required grid resolution for input to the niche modelling algorithms. Under this category, we also included services which process animal tracks to provide grouping of tracks in trips or gridding a number of tracks to compute and analyse species population distributions.

Data Mining Services

These services process animal tracks and satellite marine observations in order to model animals' use of space and correlate it with environmental observations. This is further subdivided in two sub-categories of services: Animal track based services and statistical environmental services. These respectively analyse animal tracks for estimating the species home range and foraging grounds; and the statistical relevance of environmental observations in modelling animals' presence.

High Level Fusion Services

This category contains services that make use of multiple data sources to better estimate animals' position, behaviour and modelling animals' habitats. This category includes the Track & Lock service which enables the estimation of submarine trajectories for animals equipped with pop-up or archival tags, Change-point Analysis and various Habitat modelling techniques.

Fig. 1 .

 1 Fig. 1. Global Big Data Platform Architecture Overview

Fig. 3 .Fig. 4 .

 34 Fig. 3. Mean SST ranges for spawning (right) and feeding (left) tracks

Fig. 6 .

 6 Fig. 6. Superimposed tracks points with environmental variables

Fig. 7 .

 7 Fig. 7. Data analytics services deployment for the EO4wildlife big data platform architecture The data analytics based algorithms which are deployed in the platform primarily include mining, machine learning, data fusion and reasoning methods on marine species behaviour which correlates with geospatial and temporal trends of MetOcean fronts.The resulting open web processing services are grouped in three main categories: data pre-processing and aggregation, data mining services and high level fusion services. The high level fusion services are those which group all the intelligent post-processing of data analytics, forecasting and reasoning through knowledge modelling.

Acknowledgements

This research is partly funded by the European Commission under H2020 Grant Agreement number 687275. We are also grateful to the European Commission for giving us access to Copernicus Satellite observation data in this project. Access to Argos satellite databases through our consortium partnership is also acknowledged.


Gerhard Dünnebeil
email: gerhard.duennebeil@ait.ac.at

Martina Marjanović
email: martina.marjanovic@fer.hr

Ivana Podnar Žarko

Approaches to Fuse Fixed and Mobile Air Quality Sensors

Keywords: air quality monitoring, interpolation, kriging, mobile sensors

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

Introduction

Air pollution represents a serious threat in urban environments with a significant negative impact on human health. Therefore, the European Parliament and the Council of the European Union provided the Air Quality Directive to emphasize the importance of air quality monitoring in urban areas [1]. Also, scientists have proven that exposure to traffic-related air pollution can cause different respiratory problems [START_REF]HEI Panel on the Health Effects of Traffic-Related Air Pollution. Traffic-Related Air Pollution: A Critical Review of the Literature on Emissions, Exposure, and Health Effects[END_REF]. Since heavy industry and vehicles are nowadays major producers of toxic gases, it is necessary to densely monitor air pollution in big cities, both in time and space, in order to identify contaminated areas promptly and devise appropriate actions.

Today Air Quality Monitoring is mostly done with stations that do long term monitoring at fixed location. Although the equipment often is mounted in containers which can be relocated (Figure 1 and Figure 2), there is a need to have undisturbed series of measurements over a long period of time that allow to exclude location based effects from the measurement campaign. The traditional air quality measurement infrastructure can therefore be extended to obtain a higher spatial resolution by using a larger number of mobile wearable sensor nodes for environmental monitoring (Figure 3).

Figure 3. Wearable sensors for air quality monitoring 2

Although there is a significant discrepancy in the accuracy and sensitivity between the new mobile sensors and static meteorological stations, their affordability and simplicity have created the opportunity for wide usage of small and cheap sensor devices. Thus, we investigate how these two can coexist and benefit from each other. One of the major advantages of mobile sensors is the simplicity of taking samples on many locations. In this paper, we will focus on ideas how this wider coverage can be used to estimate the pollution at arbitrary points by exploiting the spatial and temporal coverage of mobile sensors in combination with the accuracy of fixed stations.

The rest of the paper is organized as follows: Section 2 introduces a model based sensor data interpolation with focus on the kriging method. In Section 3 we discuss the proposed model. We further introduce the problem of bogus sensor detection and determination of confidence factors in Section 4. Section 5 provides a brief overview of related work by addressing interpolation methods used in different areas of the environmental science. Finally, Section 6 concludes the paper and gives directions for future work.

Model-based Sensor Interpolation

The mobility of sensors leads to a dynamic sensing coverage of geographical areas, which can potentially result in certain areas being redundantly covered, while other areas may suffer from lack of available sensor measurements. Obviously, it is not possible to cover all geographical points in a certain area of interest by actual sensor readings. Therefore, we need to use a finite number of sensor readings and estimate the actual values in between. Mathematically this requires an interpolation approach.

Interpolation is a method of constructing new data points from a set of previously known values. Basically, it makes some assumptions about the values at locations that have to be estimated by using some kind of a model. Classical interpolation approaches, like polynomial or spline interpolation, completely ignore the fact that sensor readings always come with a certain inaccuracy. Hereafter, we present and discuss other techniques that can be used to estimate missing values.

Interpolation can be done in space or in time or both. In this paper we implicitly restrict ourselves to interpolation in space. Our goal is to get subsequent maps of pollution for discrete points in time that incorporate as much information as possible to get the best accuracy. This includes not only information gained at or near the said points in time but also the knowledge about the involved sensors gained from the earlier maps.

Kriging approach

One well known approach to interpolate sensor readings is kriging (originated by Danie G. Krige in 1951 [START_REF] Krige | A Statistical Approach to Some Basic Mine Valuation Problems on the Witwatersrand[END_REF]). The basic idea of kriging is to estimate a value at a specific location by computing a weighted average of the known values in the neighborhood of that location. In other words, kriging takes into account the nearby sensor readings to eliminate to a certain degree the random errors inherent in every reading. The mathematical meaning of the term nearby is defined by the so called co-variance function v(l ⃗) which defines the significance that a certain reading r has at location l ⃗.

The estimated value at location l ⃗ can be calculated as

𝑍𝑍�𝑙𝑙 ⃗ � = ∑ 𝜆𝜆 𝛼𝛼 𝑛𝑛�𝑙𝑙 ⃗ � ∝=1 𝑍𝑍(𝑙𝑙 𝛼𝛼 ) �����⃗ . (1)
The factors 𝜆𝜆 𝛼𝛼 describe how much a reading is relevant for the interpolated value. This is determined by the co-variance function.

There is a certain degree of freedom in choosing this function. Indeed, this is the model behind the kriging approach.

Usually one chooses a function that will have a value of 1 at the exact location 𝑙𝑙 ⃗ and will monotonically decrease with the distance from 𝑙𝑙 ⃗ . Either this function will be zero at a certain distance from 𝑙𝑙 ⃗ or it will converge to zero with the distance reaching infinity. So the co-variance function typically has the form of a coefficient between 0 and 1 which defines the statistical weight of a reading r at the location . Figure 4 shows some typical curve forms for such function.

Figure 4 Examples of different co-variance functions

This co-variance function gives an individual value for each sensor that is expected at a location𝑙𝑙 ⃗ . All these values usually differ from each other. The interpolated value is now calculated such that the individual errors are minimized (least mean square).

Taking confidence into account

Nowadays, mobile sensors typically have a much larger error than fixed stations. When trying to fuse the readings between fixed stations and mobile sensors we have to take this into account. Even though a mobile sensor takes measurements exactly at a sampling location, usually the readings collected by different sensors at the same location and point in time will not be the same. This will be the case even if both sensors are calibrated.

Since we want to model different confidence levels, we introduce a confidence coefficient cc which lies between 0 (not reliable at all) and 1 (completely reliable). Still we have to determine a method how to gain such confidence coefficients (which we show in the section below), but once they are available they simply attenuate the existing co-variance function v(l ⃗) by defining a new one

𝑣𝑣 1 �𝑙𝑙 ⃗ � = 𝑣𝑣�𝑙𝑙 ⃗ � * 𝑐𝑐𝑐𝑐 . (2)
This will result in a domination of a nearby fixed station in the interpolation process. But if multiple mobile sensors in the vicinity share the same reading, they can eventually dominate a fixed station.

Some Definitions

To keep the other chapters free from complex and repeated mathematics and definitions as much as possible, we introduce a few phrases here. We use the term physical sensor readings 𝑟𝑟 𝑝𝑝ℎ𝑦𝑦𝑦𝑦 which indicates sensor readings without further corrections. We are aware though, that this concept is a bit problematic as this concept is not taking into account that real sensors suffer from cross sensitivity and similar effects. Certain compensations for these effects must still be applied to the raw sensor readings before they can be used in this context.

The most important function is the interpolation function I which gives us the interpolated value. I is a function of the location 𝑙𝑙 ⃗ . An index of "F" will indicate that the interpolation is done only over the fixed stations, while an index of "M" will indicate the same only for mobile stations (i.e. IF and IM).

A function LMS means we use the least mean square fit on the data. The result of an LMS is a set of coefficients. Due to the lack of better models we assume a linear mean square fit throughout this paper so the result is a pair of numbers, amplification a and offset b so that the correction function is

𝑟𝑟 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 = 𝑓𝑓(𝑟𝑟 𝑝𝑝ℎ𝑦𝑦𝑦𝑦 ) = 𝑎𝑎𝑟𝑟 𝑝𝑝ℎ𝑦𝑦𝑦𝑦 + 𝑏𝑏.
(3)

Model discussion

The above described approach has a clear weakness as it assumes that only the distance between different sensors is important. This assumes an ideal situation where diffusion processes are not disturbed by wind or obstacles, neither natural nor artificial.

The assumption does not hold in a typical urban environment where street canyons dominantly influence the spreading of pollutants. Further discussion of street canyon effects, their consequences and possible solutions is out of scope for this paper and it will be taken into account in future work.

Relating mobile sensors to fixed stations

Usually sensors tend to drift. Even though sensors are kept in a very controlled constant concentration of pollutants, the readings will still change over time. A lot of effort is taken to control and compensate the natural drift for fixed stations. The related analyzers are often calibrated and in many cases a so called function control procedure is performed once every 24 or 48 hours. During the function control phase the analyzers are first exposed to gases with known concentrations, then the resulting error is recorded and all subsequent sensor readings are compensated numerically.

However, doing the same for mobile sensors would significantly devalue their advantages in mobility and costs. For that reason, it is necessary to find other ways of compensating the errors of mobile sensors. The first idea, to just compare readings between fixed and mobile sensors when a mobile sensor passes by a fixed station seems obvious but will not work. One reason is that mobile sensors typically measure one to four samples per minute as they have to operate on severely limited energy. If we assume that the sensor is moving with a bicycle or car, this means it will hardly measure at all within a distance close enough to a fixed station. Another reason is that mobile sensors typically measure at heights of 1 to 1.5 meters above ground level while fixed stations have their air inlet at least 4 meters high.

To compensate this errors, we first interpolate using only the fixed stations. This can usually be done easily as all fixed stations give their results for the same time. The result is a map that shows approximately the situation over the area for a given point in time.

The resulting interpolation function 𝐼𝐼 𝐹𝐹 �𝑙𝑙 ⃗ � is then used to calculate the deviation of each sensor reading to the related interpolated value. Of course, doing this for just one reading per sensor is still significantly influenced by different errors, some of them potentially huge. We need to gather enough of these (real reading, interpolated value) pairs to apply an LMS-function and get statistically significant coefficients for gain and offset to correct each sensor.

Relating mobile sensors to each other

The above described approach will only work when the probability of a mobile sensor to pass near a fixed station is high. However, the probability that two mobile sensors meet is much higher considering that only a certain (minimal) number of fixed sensors is in the field.

Doing an interpolation on the mobile sensors themselves and comparing individual sensor readings to the interpolated values can provide individual deviations for each sensor. When having sufficient deviations, a best-fit-line which will compensate individual sensors with respect to their companions can be calculated. When a network of mobile sensors is compensated, it is also possible to calculate compensation factors of certain sensors to the fixed stations. With this approach it is possible to adjust the complete set of sensors to the readings of fixed stations.

For this approach, we calculate the interpolation function for the mobile sensors, 𝐼𝐼 𝑀𝑀 �𝑙𝑙 ⃗ �. Theoretically this is done for all sensor readings at a particular point in time. In praxis, it not possible to have this one point in time, instead we use a short time interval. Subsequently all physical readings are paired with the interpolated readings at the same location. As singular readings are not sufficient to compute LMS statistics, these pairs are stored for later evaluation. A sufficiently large set of these pairs is then used to compute coefficients that correct sensors to be harmonized with the other sensors. This list of pairs must contain enough data to calculate a meaningful statistic. On the other hand, as the sensors tend to age and drift, it must not contain values too long. In practice, we found out that having a list length of a few hours is more than sufficient.

Next, for each fixed station n another pair (𝐼𝐼 𝑀𝑀 �𝑙𝑙 𝑛𝑛 ���⃗ �, station reading) is calculated.

This dataset is subsequently used to compute an LMS.

Results and discussion

To verify the proposed algorithm, we have used a real-world dataset acquired from the air quality measurement campaign "SenseZGAir" performed in the City of Zagreb, Croatia, in early July 2014 as part of the Smart City Zagreb initiative. The "SenseZGAir" dataset contains 151,000 data points, including temperature, humidity, pressure, concentrations of carbon monoxide (CO), and either nitrogen dioxide (NO2) or sulfur dioxide (SO2), obtained at 13,000 unique locations in Zagreb (according to GPS coordinates) in 3 days that the campaign lasted [START_REF] Antonić | Urban crowd sensing demonstrator: Sense the Zagreb Air[END_REF]. To evaluate our model, we have used CO measurements from mobile sensors and official gas concentrations from the Croatian Ministry of Environment and Energy on July 7, 2014.

Figure 5 shows individual paths which 8 of our sensors did during the field trial in the time span from 9:00 to 10:00 a.m, while the "zoom" part shows the sensors "near" one of the fixed monitoring stations in Zagreb (marked as red cross) which we have chosen for our experiments. 3We have visualized individual sensor measurements together with the fixed station concentrations during the chosen time span, as shown on Figure 6. It can be seen that CO values differ a lot between sensors which is obviously not only due to the measurement errors but also to local effects. Also, the figure shows the fixed station measurement value (hourly mean) for the same period. Correlating these two datasets leads to the fact that many substantially different mobile measurements are compared to the same fixed station's measurement. This in return makes it impossible to calculate a least mean square fit.

In another experiment we tried to relate sensors to each other. For that we used the time slot from 9:00 to 9:10 from the same data set mentioned above.

We have visualized the sampling points in Figure 7. It can be seen that there are quite some places where sensors are located close to each other. We have used those sensors to find correlations between them, i.e. to show whether the sensors deviate or not. The interpolation showed the small variations between sensor measurements in the observed area. It also showed that the overall concentration of CO is mostly low, except on the crossing of two big roads with heavy traffic where we observed slightly lower air quality depicted as a red area in Figure 8.This is a well-known hot spot of lower air quality, so the public authorities have already placed the fixed station to continuously monitor the air quality as shown on Figure 5.

We have also compared the difference between the interpolated values and real sensor measurements as shown in Figure 9. The comparison gave an interesting result as it showed very few deviations between sensors and their interpolated values. Most of interpolated values differ less than 500 μg/m 3 from the measured value, while few of them show a difference between 1000 and 1500 µg/m 3 . Those readings from a sensor have the value of zero and are not valid anyway. The few sensors that show real deviations do not allow to make any useful statistic.

Bogus sensor detection and determination of confidence factors

Mobile sensors tend to age and get unreliable over time. Detecting this effect is crucial for the evaluation of individual sensors. The procedures described above determine a best-fit-line for each sensor. Calculating the correlation factor for this best-fit-line provides an estimate of the quality of a sensor response to a given pollutant exposure.

Sensors that occasionally give bad correlations most probably have severely changed their environment during the time window currently in focus, e.g. parts of the measurements are indoor while others are near a road.

A more sophisticated analysis may be able to classify these individual measurements and treat them as separate classes. We simply propose to use this correlation factor as the confidence factor, maybe scaled down with an additional fixed factor that describes the overall confidence in mobile sensor. Sensors that occasionally show a bad fit are not necessarily defective. There can be many reasons for small sets of measurements being "off". Therefore, we propose to keep track of these correlation factors. If they show a long-term degrading trend, the sensor will lose permanently influence to the complete system. A sensor that has less influence is not important anymore and can be removed from the network.

Related Work

There are several papers considering data interpolation in different areas of the environmental science. Gummadi [START_REF] Gummadi | A comparison of various interpolation techniques for modelling and estimation of radon concentrations in Ohio, Theses and Dissertations[END_REF] gives a short overview of conventional interpolation techniques and neural network approaches commonly used for modelling and estimation of radon concentrations in Ohio. Kravchenko et al. [START_REF] Kravchenko | A comparative study of interpolation methods for mapping soil properties[END_REF] evaluate different interpolation principles to determine the optimal method for mapping soil properties, similar as Li et al. [START_REF] Li | A Review of Spatial Interpolation Methods for Environmental Scientists[END_REF] who compare the accuracy of spatial interpolation techniques to identify the best prediction method to illustrate the spatial variability of the studied soil properties.

Spatial interpolation is widely used for creating continuous data where estimation at any unobserved location is within the data boundary and it is spatially dependent [START_REF] Robinson | Testing the Performance of Spatial Interpolation Techniques for Mapping Soil Properties[END_REF][START_REF] Akkala | Interpolation techniques and associated software for environmental data[END_REF]. Vuran et al. have developed the theoretical framework for the spatio-temporal correlation in wireless sensor networks (WSN) and showed that correlation can be exploited to significantly improve the energy-efficiency in WSN [START_REF] Vuran | Spatio-temporal correlation: theory and applications for wireless sensor networks[END_REF]. Further, stochastic interpolation methods are used to predict the values at unmeasured locations based on the data spatial autocorrelation and to estimate the prediction accuracy. In particular, kriging has been used for the spatial analysis of soil bulk density [START_REF] Sajid | Systematic Evaluation of Kriging and Inverse Distance Weighting Methods for Spatial Analysis of Soil Bulk Density[END_REF], temperature mapping [START_REF] Hudson | Mapping temperature using kriging with external drift: theory and an example from Scotland[END_REF], estimation of rainfall [START_REF] Goovaerts | Geostatistical approaches for incorporating elevation into the spatial interpolation of rainfall[END_REF], as well as air pollution [START_REF] Janssen | Spatial interpolation of air pollution measurements using CORINE land cover data[END_REF]. Tyagi et al. [START_REF] Tyagi | Applying Kriging Approach on Pollution Data Using GIS Software[END_REF] use ordinary kriging to estimate the pollution in areas without measurements in Agra (Dayalbagh) region, similar as Shad et al. [START_REF] Shad | Predicting air pollution using fuzzy genetic linear membership kriging in GIS[END_REF] who use fuzzy spatial prediction techniques to determine pollution concentration areas in practical situations where observations are imprecise and vague.

Conclusion

This paper deals with the statistical approaches which can be used to estimate the pollution at arbitrary points by exploiting the spatial and temporal coverage of mobile sensors in combination with the accuracy of fixed stations. In particular, we discuss the model-based interpolation with a focus on the kriging approach. We have proposed an algorithm to fuse fixed and mobile air quality sensors and get harmonized sensor readings. However, due to the variance in the mobile sensor measurements together with the limited availability of fixed station data (note that this data is most often only available as aggregates over several minutes: Swiss -10 minutes, Austria and Germany -30 minutes, Croatia -1 hour time scale), the initial experiments did not provide usable results.

We also experimented with relating mobile sensors to each other. Interestingly this experiment showed that the often asserted inaccuracy of mobile sensors might be less than usually assumed. At least our finding was that we had no need for extensive compensation of the sensors.

We plan to repeat the experiment in a more controlled manner (like having some mobile sensors near the fixed station). Furthermore, we plan to simulate sensor networks combined from real stations and mobile sensors. Moreover, we want to integrate street canyon models into the system.

Figure 1 A

 1 Figure 1 A typical AQ monitoring fixed station 1

Figure 2 A

 2 Figure 2 A set of analyzers as they are typically found in a fixed station

Figure 5

 5 Figure 5 Mobile sensor measurements in the City of Zagreb for July 7, 2014, from 9:00 to 10:00 a.m.3

Figure 6

 6 Figure 6 All sensor measurements between 9:00 and 10:00 a.m. onJuly 7, 2014

Figure 7

 7 Figure 7 Geographical locations of mobile sensors from 9:00 to 9:10 a.m.

Figure 8 Figure 9

 89 Figure 8 Interpolated sensor measurements

4

 4

  The resulting coefficients (𝑎𝑎 𝐹𝐹 , 𝑏𝑏 𝐹𝐹 ) are merged with the individual coefficients for each sensor. 𝑟𝑟 𝑀𝑀,𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 = (𝑎𝑎 𝐹𝐹 * (𝑎𝑎 𝑀𝑀 * 𝑟𝑟 𝑝𝑝ℎ𝑦𝑦𝑦𝑦 + 𝑏𝑏 𝑀𝑀 ) + 𝑏𝑏 𝐹𝐹 = 𝑎𝑎 𝐹𝐹 𝑎𝑎 𝑀𝑀 𝑟𝑟 𝑝𝑝ℎ𝑦𝑦𝑦𝑦 + 𝑎𝑎 𝐹𝐹 𝑏𝑏 𝑀𝑀 + 𝑏𝑏 𝐹𝐹 (4) 1. This can also be formulated as an algorithm: 2. Calculate the interpolation function IM for all mobile sensors. 3. Gather all pairs (𝐼𝐼 𝑀𝑀 �𝑙𝑙 ⃗ �,𝑟𝑟 𝑝𝑝ℎ𝑦𝑦𝑦𝑦 ) for all locations where sensor readings are available and add those to the set of existing pairs for each sensor. 4. Calculate correction factors for each sensor. 5. Calculate the interpolation function IF for all fixed stations. 6. Gather all pairs (𝐼𝐼 𝐹𝐹 �𝑙𝑙 ⃗ �, 𝐼𝐼 𝑀𝑀 �𝑙𝑙 ⃗ �) for all locations of the fixed stations. 7. Calculate an LMS for all pairs and obtain the corrective coefficients 𝑎𝑎 𝐹𝐹 and 𝑏𝑏 𝐹𝐹 . 8. Apply both, individual and global, factors to each sensor reading to obtain harmonized readings.

Wearable sensors and smartphone application for air quality monitoring developed at University of Zagreb, Faculty of Electrical Engineering and Computing, Zagreb, Croatia.

Visualized by the CopyPasteMap tool available at http://www.copypastemap.com/

Acknowledgments

This work is supported in part by the H2020 symbIoTe project, which has received funding from the European Union's Horizon 2020 research and innovation program under grant agreement No 688156. This work has been supported in part by Croatian Science Foundation under the project 8065 (Human-centric Communications in Smart Networks).