Leader: Baltic Open Solution Center, Latvia
Contact person: RNDr. Karel Charvát, Charvat@ccss.cz
Sensors are important part of common data producers at these days. We are searching for effortless and straightforward utilization of existing sensors that are available via the web during the pilot Open Sensor Network. But reusing of existing sensors run by third-party providers comes with lot of questions. These questions reaching from initial searching of these services via satisfactory description by metadata and coming to filtering of found sensor candidates. Very good comparison is that as same as we are searching suitable repairman company in yellow pages, it can be useful to find some universal “yellow pages” for searching appropriate sensors and sensor data producers.
Currently we are supporting in pilot three types sensors:
- Ground water sensors
- Agrometeorological sensors
- Human as a sensor
The water quality depends on the crop type and the irrigation method, as well the soil types, groundwater levels, soil and water chemistry, nutrient loads, limits on chemicals, the salt tolerance of crops, the 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, even if adequately treated, as a resource or they see the energy costs of treating wastewater to an adequate standard as being prohibitively expensive. One of the aims of the project pilot is to utilise recent innovations to turn wastewater reuse into a profitable, socially beneficiary and environmentally safe business.
Agriculture requires the collection, storage, sharing and analysis of large quantities of spatially referenced data. For this data to be effectively used, it must be transferred between different hardware, software and organisations. These data flows currently present a hurdle to uptake of precision agriculture as the multitude of data models, formats, interfaces and reference systems in use result in incompatibilities. 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. The wireless communications have several benefits, but also pose challenges to the data exchange reliability and power supply. Sensor calibration and deployment as well as maintenance of sensors need resources and technical skills and increase the costs of data acquisition. Both increasing the amount of data and awareness of data quality issues highlight importance that metadata are attached to sensor data.
Human as sensor or so called VGI monitoring is collecting measurement using smartphones.
Pilots have connected three basic groups of users:
- Sensor data producers, that means sensors owners or producers who register their sensors in sensors catalogue, together with all necessary parameters and protocols for accessing of sensors.
- Sensor data consumers, who will have two possibilities to access sensors measurement on the base of their selection through interoperable protocols or use SDI4Apps Apps. This second group will consists of farmers, scientist, service organisations, advisors and public servant.
- Apps developers, who are developing their apps on the base of stored date.
There are two main Enablers supporting scenario
IoT Discovery GE from the FIWARE world as solution. IoT Discovery can be considered as a point for data producers to register the availability of sensors, and for data consumers to discover available sensors. IoT Discovery is using either the OMA NGSI-9 messaging protocol, or the Sense2Web API that supports Linked Open Data. Both interfaces serve as a service discovery mechanism (SDM) for IoT Descriptions. An SDM is analogous to a registry or directory for IoT entities, where information about the IoT entity can be discovered (e.g. what attributes can be queried, or to get metadata about those attributes providing more detailed information.) It also provides information on how to reach the entity. SDM allows users to discover or check what is available and know where actual context sources are, and avoid unnecessary network overload of IoT context providers.
Significant issue comes into consideration together with the idea of Sensor Catalogue. If a lot of sensors from different providers are registered in the catalogue and therefore theirs metadata are accessible from one point. How to make sensor data accessible at the same point? And more complexly, how to access sensor data from different providers that are published using different protocols? It means from the user point of view the problem with different publishing protocols is delegated on the catalogue side. No necessity to have several applications for many of used protocols as the sensor data consumer. A user having an application communicating over one protocol can access wider range of sensors by the catalogue access point. It can be radical benefit on the client side.
SensLog is a software component for receiving, storing, analysing and publishing sensor data in various interfaces. SensLog receives sensor data in form of HTTP GET requests and stores them to PostgreSQL database with PostGIS extension. SensLog publishes data using proprietary RESTful API version 1.0 and using standardized OGC Sensor Observation Service version 1.0.0. SensLog contains also simple GUI with several functions to show data, it is supposed to be used in combination with other clients.
The data model for data storage and access was prepared and agreed with other projects (FOODIE, OTN). The data model was improved especially in the field of large tables. The largest table observations and units_positions are growing in coherence with continuous data collections, they were supplemented with table partitioning mechanism. Partitioned child tables are stored in separate database schema and allow better querying, backuping and maintenance.
Currently, we’ve implement three different apps:
1. Ground water monitoring
2. Agrometeorological monitoring
3. VGI monitoring