OGC Citizen Science Interoperability Experiment Engineering Report

This experiment was designed to demonstrate how current ICT-based tools can be applied together to allow better citizen participation in CS projects and enable better reuse of the data gathered. Citizen Science is highly transdisciplinary and heterogeneous by nature and current standardization efforts already occur in the OGC (e.g., addressing data model and sharing issues) as well as outside the OGC (primarily addressing project descriptions and dataset metadata). Citizen Science projects might benefit from concrete examples and best practices required to achieve the full benefits of interoperability. OGC is in the ideal position to develop and provide such best practice guidance to the international community. Developed solutions in this IE should be applicable to most Citizen Science projects. Findings from this IE will be generalized as practice examples and might set the basis for additional experimentation in the future.

The FP7 Citizen Observatory Web (COBWEB) project was the first to propose the use of SWE in CS. This work resulted in an OGC public Discussion Paper available on the OGC website (OGC 16-129). The Discussion Paper describes a data model for the standardized exchange of Citizen Science sampling data based on SWE standards. This Discussion Paper was the initial motivation for this IE.

Beyond the work described above, the Citizen Science Association’s International Working Group on Citizen Science Data and Metadata has developed the PPSR-CORE metadata standard and the European Citizen Science Association (ECSA) has a working group that recognizes the value of standardization in the CS activities (supported by a COST Action). However, these activities could benefit from some experimentation that would be able to suggest common best practices while recognizing the particularities and current approaches in different thematic domains, such as biodiversity monitoring. Citizen Science can complement authoritative in-situ observations and fill the information gaps in numerous scientific disciplines that could be essential for informed decision making. In that sense, the way Citizen Science can be integrated into The GEOSS (including GEOSS-Data Core as the pool to promote and share open and free data) is still under investigation.

The Ecosystem of Citizen Observatories (CO) for Environmental Monitoring WeObserve project is a Horizon 2020 funded project focused on improving the coordination between existing COs and related regional, European, and international activities. WeObserve tackles three key challenges that face COs: awareness, acceptability, and sustainability. The WeObserve Community of Practice 3 (CoP3) is about Interoperability of Citizen Science projects. The WeObserve project – via its CoP activities – has represented an opportunity to promote interoperability experimentation in collaboration with the OGC. Such collaboration addresses questions raised in the SWE4CS discussion. In addition, the work offers the possibility to directly feed the results into the relevant OGC standards and promotes their usage within GEOSS (as an important user community of OGC standards).

In anticipation of the 50th Anniversary of Earth Day in 2020, Earth Day Network, the Woodrow Wilson International Center for Scholars, and the U.S. Department of State, through the Eco-Capitals Forum, announce Earth Challenge 2020, a Citizen Science Initiative. This initiative is in collaboration with Connect4Climate – World Bank Group, Conservation X Labs, Hult Prize, National Council for Science and the Environment (NCSE), OGC, Reset, SciStarter, UN Environment, and others to be announced. Earth Challenge 2020 will help engage millions of global citizens in collecting one billion data points in areas including air quality, water quality, biodiversity, pollution, and human health. Earth Change 2020 data will be shared through the GEOSS Portal.

This is the first Citizen Science IE conducted by the OGC. Prior to this activity, there was a Discussion Paper on how to apply the SWE standards in Citizen Science (SWE4CS). This experiment positively tested the proposed route using Sensor Observing Services but also has opened the door to future exploration of the SensorThings API.

Also prior this activity, was a H2020 project with a Authentication Service and after the activity, three H2020 efforts formed a bigger federation demonstrating the route to federating and aggregating Citizen Science projects to contribute to GEO objectives.

This work is relevant to the OGC Citizen Science Domain Working Group.

This OGC IE ended on June 2019, but a second IE is foreseen for the following year.

New possible topics for next IE to be discussed among the members include the following.

The definition of the follow-up IE started upon completion of this IE.

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Initiators

The WeObserve project has received funding from the European Union’s Horizon 2020 Research and Innovation Programme under grant agreement No. 776740.

This presentation reflects only the editor’s views and the EU Agency is not responsible for any use that may be made of the information it contains.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

This report was coordinated and developed with funding from the European Union’s Horizon 2020 research and innovation programme under grant agreements: no 776740 (WeObserve), no 688930 (SCENT), no 689744 (Ground Truth 2.0), no 690199 (GROW Observatory), no 689812 (LandSense) as well as no 730329 (NEXTGEOSS).

The official kick-off meeting for the OGC CitSciIE experiment was held on Friday 14th September 2018 at the OGC TC meeting in Stuttgart, Germany. Activities continued until March 2019.

During the kick-off meeting of the IE, the following subgroups emerged.

For each of the subgroups a chair and the main participants and contributors were identified. Responsible persons were also assigned to each of the working items.

These are the main activities and outcomes of the interoperability experiment detailed by activity.

Data sharing using OGC standards such as O&M and SOS

This activity has been the most active one. During the IE, the following servers have been deployed: MiraMon SOS server, Grow SOS, DLR istSOS SOS, and 52north SOS. Three clients have also been produced: MiraMon SOS browser, Grow SOS data viewer, and 52north Helgoland. In the last meeting at the EGU, the group was able to demonstrate interoperability by connecting the SOS clients to the SOS services and showing the data on clients, sometimes mixing data form different services and datasets in a single view. This is the most significant result of the experiment and is being extensively documented in this Engineering Report in sections 5, 6 and 7.

Data quality

Two quality vocabularies have been identified: Australian work done by Peter Brenton’s team (https://github.com/tdwg/bdq) and the QualityML vocabulary developed by CREAF in the GeoViQua project. The intent of this IE was to do a comparison of both approaches, but the participants were not able to do so in the timeframe of the first IE. Section 8 describes the current status of the activity. It is foreseen that the second IE will continue what was started here.

Definition server for organizing Citizen Science projects

The objective of this activity was to support the Earth Challenge 2020 research questions. The questions were defined during the first month of the experiment and now it is time to analyze the questions in terms of data needs and thematic vocabularies to be used. Because the analysis has not yet been performed, this activity has not resulted in tangible outputs and will be reintroduced in the second IE. Details of this development are described in section 9.

Connection between LandSense federation and other user systems

Secure Dimensions (Andreas Matheus) was very active in providing demonstrations and information on how the LandSense federation works and how other projects can be included in the federation and use the SSO facility. Unfortunately, no other member of the CoP had the resources to apply the SSO on their services or clients and take advantage of the LandSense offering. The activity resulted in a video demonstration that is publicly available here: https://portal.opengeospatial.org/files/?artifact_id=81550.

Section 11 Details the current status of the activity.

Other

Section 11 summarizes the lessons learned that can be applied to GEOSS.

In addition to these activities, another activity about quality annotating scientific documentation in a standard way was proposed by Lucy Bastin. A video was recorded that summarizes the idea: https://portal.opengeospatial.org/files/?artifact_id=82544.

In the Ground Truth 2.0 project, we have been using the MiraMon implementation of O&M. This implementation assumes a simplified situation that considers that each observation can be represented by a single row in a CSV or in a single record of a database table. Coordinates are represented as a single point. In this situation, we select which column names represent the phonomenonTime, the procedure (that actually is including the user name), and the featureOfInterest (the coordinates). The rest of the columns are considered part of the data record that needs to be provided as the result.

Section 8.2.1 of the [OGC 08-094r1] OGC® SWE Common Data Model Encoding Standard v2.0 describes a way to encode a DataRecord as an array of fields that can numbers, strings, dates, etc. In our simplified assumption, this array is ideal to wrap the properties of the observations that cannot be mapped to any other O&M aspect. This practice is consistent with the section 7.2.8 of the SWE4CS discussion paper.

The following is an example of how a water quality observation is represented following the O&M model and encoded in XML.

The following is an example of how two air quality observations are represented following the O&M model and encoded in JSON.

These examples were produced by SOS requests to this URL: http://www.ogc3.uab.cat/cgi-bin/CitSci/MiraMon.cgi?. A client connecting to this service can be found here: http://www.ogc3.uab.cat/gt20/.

To illustrate the flexibility of the O&M, we have included this air quality report that shows how HackAir data is presented by a 52North SOS implementation. In this case the result presents a single numerical value while the other information is provided as parameters. This approach is consistent with section 7.2.2.5 of the O&M standard.

A service producing this type of results can be seen here: https://nexos.demo.52north.org/52n-sos-hackair-webapp/service.

In the GROW project the SME Hydrologic has developed a SOS service that uses an O&M observation. In this case, a single number is provided as the result of the observation and additional parameters are transported.

So far we have seen 3 servers using 2 different approaches to represent the result. That is not a problem for a web service (that only outputs data), but it is not the best situation to ensure interoperability at the client side where an integrated client will need to react to any possible encoding variation and deliver the best result.

In this architecture ([MiraMonSOSArchit]), the client access directly two different SOS services. It formulates a GetFeatureOfInterest to determine the positions of the individual observations and a GetObservation each time it needs to show a complete description of a single point (the user triggers this event by clicking on an icon) or if it needs to represent different icons as a function of the value of the observation. In this case, interoperability happens directly in the client. Since the SOS requests are communicated to the Internet, this client is exposing requests and response, allowing people to explore the SOS protocol with both the map browser console as well as the browser developer tools.

It is worth mentioning that this architecture is only possible if both services are declaring their willingness to be combined in the header of the responses. By default, programatically reading XML or JSON data coming from a Internet domain different from the client itself is not allowed except if the server states in the header that this is allowed. This is known as Cross-Origin Resource Sharing (CORS). The following headers will allow CORS with anybody.

In the case a SOS server does not allow CORS, our client is still able to force a solution by redirecting the request to our server with an extra parameter ServerToRequest. In this case, our server will cascade the request to the specified server and return the response back to the client as if there was only one server involved in only one domain.

In this architecture ([GrowSOSArchit]), a common server pulls two or more SOS requests into a central tabular datastore. This datastore records only the information from the returned SOS data that is required for the final visualization and removes information that is redundant, creating a data warehouse representing only one version of the data. In this approach, the interoperability happens internally in the datastore and the SOS requests and responses are not exposed to the final client.

In the diagram below ([GRowDataFlow]), data is stored in the data warehouse and Microsoft’s PowerBI does the heavy lifting for the visualization of the combined data sources.

The common server would typically be a cloud server, but for some clients this is not necessary, in the case of PowerBI, a data bridge is created between the data source and the visualization tool before it is published to a web client.

Other visualization tools (such as Tableau) will have their own methods of connecting to the data warehouse and publishing the results to a web based client.

In this architecture, data is only as up-to-date as the latest data pull from the SOS servers; in the case of GROW, this is done nightly, but this could be made more frequent or moved towards real time using a data log pipeline in a kappa architecture.

This architecture was especially optimized to support the development of lightweight Sensor Web applications. This is achieved by avoiding the direct XML encoding/decoding on the client device. Instead, the interactions between the client (in this case the 52°North Helgoland Sensor Web Viewer) and the server components is achieved via a REST and JSON interface (the 52°North Sensor Web API).

This API can be directly exposed by Sensor Web servers such as the 52°North implementation. Alternatively, an available proxy component is also able to encapsulate existing OGC SOS servers behind the lightweight interface of the 52°North Sensor Web API.

The advantage of this approach is a more lightweight communication pattern to be implemented on the client side. In addition, the 52°North Sensor Web API offers further convenience methods as well as functionalities for reducing the transferred data volume (by generalizing observation data) and improving the data visualization (e.g., providing rending hints). A drawback of this approach is a less direct interaction with SOS servers, so that for integrating new SOS servers, a proxy component has to be configured/adjusted.

The 52°North Sensor Web Server comprises several server-side modules which closely interact to provide different kinds data access functionality. In detail, server comprises the following elements.

The URL of the instance used in this IE was: https://nexos.demo.52north.org/52n-sos-hackair-webapp/service.

More information about the initiative can be found here: https://52north.org/software/software-projects/sos/

istSOS (Istituto Scienze della Terra Sensor Observation Service) is an OGC SOS server implementation written in Python. istSOS allows for managing and dispatch observations from monitoring sensors according to the Sensor Observation Service standard.

istSOS evolved over time from being a SOS service provider to complete data management system. But the standard does not account for a number of functionalities that were later included in the software. Some of the extending capabilities are:

The project also provides also a Graphical user Interface that allows for easing the daily operations and a RESTFul Web API for automatizing administration procedures.

The URL of the instance used in this IE was: http://artemis.geogr.uni-jena.de/istsos_ie/soil?service=SOS&request=GetCapabilities&version=1.0.0 More information about the initiative can be found here: http://istsos.org/

52 North and istSOS are both RESTful implementations of OGC SOS standard. We provide a short comparison of these tools, which might help end-users to choose a tool based on their requirements.

52 North and istSOS both provide support for all core operations defined in the OGC SOS specification. 52 North SOS is a Java based implementation whereas istSOS is a Python based implementation. As they are based on different programming languages, their supported hosting application server differs. In order to deploy 52 North SOS, the end-user can either use Tomcat, Jetty, or Glassfish. In order to deploy istSOS, Apache mod_wsgi is required. Both implementations have a restful web interface and support JSON, XML, and plain text for data encoding. 52 North offers bindings like KVP, SOAP, POX, and EXI. istSOS offers bindings like KVP and SOAP. They both run on major OSs like Windows, Mac, and Linux. They both support Postgres/PostGIS as underlying database management system. 52 North implementation also supports database like Oracle, Microsoft SQL Server and MySQL. 52 North implementation provides multilingual support for querying data. istSOS offers automatic notifications via email, Twitter, or other social media. Both SOS implementations provide a user-friendly graphical interface which includes a built-in client, data viewer, and data manager. Both tools come with a detailed documentation with proper examples. They both have a friendly support community which is easily reachable via email and have a supporting emailing list where users can post questions.

MiraMon Server is a stand alone CGI application that runs on Windows operating systems that can be used in combination with a web server such as Internet Information Server or Apache for Windows. It is the ideal solution for people that already uses MiraMon professional on desktop because it uses the same MiraMon formats in the back-end. MiraMon server is based on the same libraries that are used by MiraMon professional and has the same capabilities in terms of CRS support, interpolation algorithms, MMZX compression, etc. One particularity of the software is the internal tiled schema required to serve maps and tiles in a fast an scalable way. MiraMon Server uses OGC web services as a baseline for the interaction to the client. Currently, MiraMon server provides support for the following standards:

The SOS capacity is used in tandem with the Web Feature Service and uses the same MiraMon topologically-structured formats in the back-end. It has been developed in the Ground Truth 2.0 project to serve interoperable data from the Citizen Observatories created during that project. The current implementation is incomplete and only supports GetFeatureOfInterest and GetOBservation operation with limited capabilities. The objective of the minimum capabilities developed was to report the requirements of a viewer client needed to represent a map of the features of interest provided by the service and to allow for a query in a point to get more information about the observations at that point. Each dataset in MiraMon becomes a observedProperty in the SOS service. Each observation is a position in a PNT file that has a DBF record associated that is automatically transformed to a O&M DataRecord. Internally, it is possible to mark field names in the DBF that are associated to concepts in the O&M, such as the phenomenon time and the user name.

Below is the internal format for the small REL5 document necessary to include the extra information that the server requires.

Final representation as XML O&M of the same structure:

The GROW SOS service is tightly integrated into the GROW platform based around Hydrologic’s existing Hydronet 4 platform. The SOS 2.0 service runs concurrently with the GROW standards API in the HydroNET GROW Server.

The service implements two .net packages that disseminate GROW data to the SOS 2.0 standard within the GROW instance of HydroNET 4 Server. A SOS package covers the mapping of SOS 2.0 requests to GROW requests and the mapping of GROW data structures to SOS 2.0 standards. A second package Ogc.Wrapper.Entities contains the SOS 2.0 entity definitions.

The Base URL of the GROW SOS 2.0 service: http://grow-beta-api.hydronet.com/api/service/sos

SOS 2.0 knows four core operations: GetCapabilities, DescribeSensor, GetObservation, and GetFeatureOfInterest.

The GROW client is a demonstrator application showing the how data sources can be combined in a tabular data warehouse and off-the-shelf visualization tools can be used to create rich visualizations. In the case of this demonstrator, Microsoft’s PowerBi was used, although commercial tools such as Tableau or Spotfire can be used. In addition, free tools such as Grafana, Rawgraphs, or Apache Superset can be employed.

The diagram below shows a typical output using PowerBi, showing GROW sensor locations combined with Airhack sensor locations.

In this application, data is pulled from two SOS sources (GROW and AirHack) via a python script, usually overnight. This data is stored in a tabular data warehouse, in this prototype this is just flat files, however a full scale data warehouse such as Microsoft’s Analysis services or a tabular database such as Cassandra could be used.

Data from the warehouse is pulled nightly into Microsoft’s cloud and then published to a web page that makes heavy use of JavaScript to provide an rich exporable interface.

This approach can be extended to mix different types of data into one visualization. In the figure below, gridded data (locations of sensors) is combined with time series data so that the user can explore the data more fully. In this application, when a user click on a sensor, the time series data from that sensor is displayed to the user. In this case, the tool takes the time series data and displays the average, minimum, and maximum of the time series data.

The MiraMon map Browser is a long-term developing effort to create a visualization, analysis, and download tool that runs in modern web browsers. Based on HTML5 and JavaScript, it uses OGC web service protocols to connect to web services and show the information to the user. The objective of the development of this tool is to assign to web browser and the JavaScript engine as much work as possible, limiting interactions to the server to the minimum possible and the transfer of information to a format that is as raw as possible. This approach can be surprising: these days are many application which prefer to perform processing functionalities in the cloud and not by the client machine. Most of the time, the MiraMon map Browser is directly responsible for creating the visualization on-the-fly based on the raw data, allowing the user to change visualization properties, perform analysis, statistics, or build time series in the client side directly. In the Data quality estimations on the client side section, we will show how the same principle can be used to compute overall data set quality can be computed on-the-fly, as well.

Below are the main functionalities and standards used to achieve that functionality.

Several layers of data coming from different servers and using different protocols can be overlaid simultaneously. Some layers represent data from a single dataset while other can be a virtual datasets computed on-the-fly for each zoom and pan and created by combining data from more than one dataset and server.

Both WFS and SOS visualization are currently limited to points that are represented in a HTML5 canvas as icons, circles, and texts and could be easily extended to lines and polygons in the near future. These functionalities were particularly useful to show occasional observations made by citizens in different places. We were able to show together Ground Truth 2.0 observations with HackAir observations using the SOS protocol directly in XML and in JSON. Some of the visualization functionalities were actually improved during the IE, such as the capability to condition the color of a circle by an attribute (or an observed result) of the feature. This way, it was possible to represent the level of concentration of a pollutant as a colored circle using a color code that was represented in the legend.

Representing the positions of the observations will require only the GetFeatureOfInterest operation unless the visualization of the feature should depend on the result of the observation. In the later case, a GetObservation is performed and all the information on the features is loaded in the client, making query by location non-dependent on the server.

The Helgoland Sensor Web Viewer developed by 52°North is an open source visualization tool for different kinds of Sensor Web data. It allows exploration of available observation data sets and visualization of the actual data (e.g., time series) as diagrams.

Figure 1 shows the map view of the Helgoland Sensor Web Viewer. In this case, a sample data set of the hackAIR project is explored. The map view shows the locations at which air quality sensors are located.

After selecting a specific measurement location, the data can be visualized as a diagram (see Figure 2). It is possible to combine data from multiple sensors, multiple observed properties, and even from different providers into a single diagram.

During the IE, a set of Technology Integration Experiments (TIE) were conducted. In the client and server architecture a TIE is a test that combines a server with a client and demonstrates that communication between client and server is possible and the user (operating the client) is able to see or get some data. The following table summarizes the tests conducted and the degree of success achieved.

The SOS protocol and the GetObservation operation enables a client to retrieve all the information about the results of the observations. With this data, the client can perform all sorts of analysis on the observations including application of some quality checks. This section will discuss a pilot that was done in the GroundTruth 2.0 project that demonstrates this capability in some practical cases.

The selected cases and their implementation are based on the QualityML vocabulary. The scenario of rapidly growing geodata catalogues requires tools focused on facilitating for users the choice of products. QualityML is a dictionary that contains hierarchically-structured concepts to precisely define and relate quality levels: from quality classes to quality measurements. These levels are used to encode quality semantics for geospatial data by mapping them to the corresponding metadata schemas. The benefits of having encoded quality semantics, in the case of data producers, are related with improvements in their product discovery and better transmission of their characteristics. In the case of data users, they would better compare quality and uncertainty measures to take the best selection of data as well as to perform dataset intercomparison. Also, encoded quality semantics allow other components (such as visualization, discovery, or comparison tools) to be quality-aware and interoperable. On one hand, QualityML is a profile of the ISO geospatial metadata standards (e.g., ISO 19157), providing a set of rules for precisely documenting quality measure parameters that are structured in 5 levels. On the other hand, QualityML includes semantics and vocabularies for the quality concepts. Whenever possible, QualityML uses statistic expressions from the UncertML dictionary (http://www.uncertml.org) encoding. However, QualityML also extends UncertML to provide a list of alternative metrics that are commonly used to quantify quality beyond the uncertainty concept.

As explained before, the WMS protocol can be used to transport binary arrays instead of pictures. During this IE, we have implemented a comparison functionality that can be used to compare two categorical maps with the same legend. This comparison results in a new map with all combinations of the two maps categories allowing us to discover changes in this maps.

This can be used to compare maps but also to quality control maps if we assume that one map represents the truth.

There are some points the authors of this chapter believe are worthy to develop or explore.

The OGC Definitions Server is a Web-accessible source of information about things ("concepts") the OGC defines or that communities ask the OGC to host on their behalf. It applies FAIR principles (Findable, Accessible, Interoperable, and Reusable) to the key concepts that underpin interoperability in systems using OGC specifications and standards. These concepts can be anything that is important in the course of interoperability around spatial information where the OGC plays a role in facilitating common understanding - either through publishing standards or assisting communities to share related concepts. OGC uses stable web addresses (URIs) to unambiguously identify concepts in its standards. The Definitions Server makes those URIs "work" - i.e., makes the URIs dereference to a definition that can be used.

The OGC Naming Authority manages the Definitions Server to ensure all URIs are stable with transparent governance. These identifiers can thus be safely used in external context. All content is freely available for re-use. Re-use is envisaged largely through the machine-readable versions.

Examples of content in the Definitions Server include the OGC glossary, technical terms from application schemas (for example the HY schema from the https://www.opengis.net/def/appschema/hy_features/hyf/HY_HydroFeature [hydrology domain]), and many others.

Even though only limited search capability is currently provided, the Definitions Server is implemented using Linked Data principles - so the combination of stable URIs allowing references to be made from outside and "follow your nose" navigation via links from one concept to related concepts provides enhanced findability.

The Definitions Server does not make any assumptions about the client software that may be used now or in the future other than the use of HTTP protocols. This enhances accessibility for different environments.

The "Web-friendly" way of using an identifier (i.e., a URL) to get more information is augmented by "content negotiation" - the Definitions Server can deliver both user friendly Web pages and other forms of resource representations, e.g., JSON-LD or Turtle (TTL).

Figure 38 shows different views of a resource HY_Feature. The left panel shows an HTML representation, the middle shows the same information using TTL, and the right using JSON. All three representations have the same content, but differ in its serialization/format. This allows both human users to explore the OGC Definitions Server, as well as machines to process its content.

The interoperability of these resources is a key goal. There are several aspects of this handled using different mechanisms:

The Authorization Server (AS) supports users to login from a variety of login providers including social media, organizations, and academic institutions participating in eduGAIN. Based on the trust in the login providers, registered applications, services, tools and Application Programming Interfaces (APIs) can be used by operating a RFC 6750 compliant Open Authorization 2 (OAuth2) Resource Server that accepts either JSON Web Token (JWT) or Bearer Access Tokens from any LandSense compliant OAuth2/OpenID Authorization Server.

The Authorization Server is extensible to any other login providers as long it is compliant with the federation requirement regarding the participation as a login provider: deployment of a Security Assertion Markup Language v2 (SAML2) compliant Identity Provider. The LandSense Coordination Centre digitally signs and hosts the SAML2 metadata for the LandSense federation by which trust is established between the SAML2 Identity Providers and the Authorization Server.

The LandSense Authorization Server acts as a GDPR compliant broker between the personal information received after a user’s login and registered applications based on user approval. In order to honor GDPR data minimization, the AS requests from the Identity Provider (IdP) at login only that amount of personal information that is required by a registered application. This amount (and which attributes, in detail) is controlled by the registration / login level. The AS provides five levels, of which the first two do not enable an application to obtain personal information: AUTH, CRYPTONAME, SAML, PROFILE, EMAIL, PROFILE+EMAIL. It can be extended to other levels like ADDRESS and PHONE.

In a nutshell, the LandSense Engagement Platform (https://lep.landsense.eu) is to become the marketplace where citizens can participate in the various Land Use and Land Cover (LULC) related campaigns and interested parties can reuse existing services and register new applications.

The first version of the LandSense Engagement Platform was realized based on the existing tools, services, and platforms from LandSense partners as well as new applications built for the Demo Cases.

Scent Harmonisation Platform Visualisation Site (https://scent-harm.iccs.gr/) is a client application tailored for the purposes of inspecting and visualizing traditional in-situ and citizen-generated observations.

The Visualisation site constitutes a custom innovative application that exposes the resources made available from the Scent Harmonisation Platform. The application conforms to OGC SensorThings API standard and it consists of the following main characteristics.

Scent Harmonisation Platform manages a variety of citizen-generated data as well as environmental data that has been collected through in-situ monitoring stations in the Kifisos river basin, Attica, Greece. All the data are being maintained and have been structured according to widely accepted standards, such as those from the OGC, in order to be compliant with open and unified frameworks (such as SensorThings API).

Details regarding the integration of Scent Harmonisation Platform Visualisation Site with LandSense authorization server are provided in Integration between SCENT & LandSense.

Scent Explore is a mobile application that enables citizens to capture environmental related information. It provides a user-friendly interface through which citizens are guided to areas where essential environmental information is needed. There, they may collect images of LC/LU elements along with textual descriptions, measure water level and flow velocity, and report flood related events like the existence of obstacles in the river, flooded locations, etc. Citizens use the app in a playful way, by discovering and collecting little characters hiding in places around them and thus collecting points.

Details regarding the integration of Scent Explore with LandSense authorization server are provided in Integration between SCENT & LandSense.

Scent Measure is a mobile application that works in tandem with a potable smart sensor (Xiaomi International Version Flower Care Smart Monitor) connected to the user’s mobile device aiming to measure soil conditions. Users can simply insert the sensor into the ground and select whether to measure and report soil moisture levels and/or air temperature and receive the measurements directly to the app.

The app constitutes an Android application that has been developed with Java as it enables easy system modeling and has support for many cross-platform software libraries. The Scent Measure application can be easily modified/adapted to support any kind of smart measuring sensors providing they have a Bluetooth connection interface with the portable devices and Bluetooth support for the message exchange from the sensor to the portable device.

Details regarding the integration of Scent Measure with LandSense authorization server are provided in Integration between SCENT & LandSense.

The NiMMBus web portal records geospatial user feedback about existing geospatial resources. The user is able to provide comments, rates, quality reports, and publications related to a geospatial resource. The portal can be used to comment on datasets but also on individual observations. The system allows creation of a citation of an external resource (in an external catalogue or repository) and associate feedback items about it. The system builds upon a service developed in the H2020-funded NextGEOSS project. Registered as an Web Browser-based application with the LandSense Authorization Server, the application can be used to collect user feedback with resources provided by other Resource Servers (APIs) also registered with the LandSense Authorizaiton Server.

The system is based on the NiMMbus, a solution for storing geospatial resources on the MiraMon cloud. The system implements the Geospatial User Feedback (GUF) standard developed in the OGC GUF (and started in the FP7-funded GeoViQua project).

The solution is composed of three elements: the open source code for a JavaScript client, a server that stores the feedback information, and a well-documented API that allows for interacting with the client.

The most straightforward way to connect Citizen Science data sets to GEOSS is the inclusion of the project that collects these data sets at the GEOSS Platform. This process essentially requires the registration of the project in the GEOSS ‘Yellow Pages’ and it can be used to register multiple data sets from one single project (see also Figure 49 below).

The entry of the Yellow Pages requires information (metadata) such as:

Once completed, the information provided by the Citizen Science project is passed on to the GEO DAB team. Members of this team check the entries and run some tests (for example, if the provided endpoint actually serves the intended data, if the endpoint needs to implement the required standards (from the OGC or comparable alternatives) and if the endpoint indeed follows the indicated principles and applies the indicated data policy). This testing might entail a dialogue with the registering Citizen Science project in order to make the project’s offering fits the promises of the entry for the GEOSS Yellow Pages.

SCENT Citizen Observatory successfully undertook the process to offer its citizen-generated data to GEOSS. Following the administrative registration that was described in detail above, the Interoperability Registration and Brokering workflow took place. This registration consisted of the following steps.

Overall, we proved that Citizen Science projects indeed can implement the free and open data policy of the GEOSS Data Core, and that all of the GEOSS Data Management Principles are followed by Scent. Furthermore, through the OGC Citizen Science Domain Working Group (DWG), we offer examples and guidance on how such implementations can be realized with OGC standards. However and realistically speaking, and in order to see concrete progress, it appears more feasible that projects first register what they already support, and at least fulfill the needs to make their data sets discoverable from within the GEOSS Platform using well-documented metadata and include information about data quality. Following the brokering approach of GEOSS, this registration entails that the projects provide a minimum of required information and ideally follow one of the multiple standards that are already supported by the GEOSS platform. If it should not be immediately possible to also provide one of the multiple options to make data accessible or to provide that data in an already recognized encoding, organizations might still consider registering a project and then update the record in the Yellow Pages once the additional functionalities for harmonized data access are put in place by the project.

Although the possibility to register Citizen Science projects of any size in GEOSS exists and has been illustrated in the previous section, we do not recommend that each and every project go ahead and register by itself right away. Potentially, the number of relevant contributions is (at least) in the hundreds: see for example, this project inventory and the related prototype of a project catalogue (Figure 52).

It becomes obvious that a case-by-case registration per project (which each might want to register one data set or more) would create a bottleneck at the GEO DAB and the team that is responsible for evaluation and test of entries in the GEOSS Yellow Pages. As a result of our investigations within this IE, we therefore suggest to elaborate on and develop an intermediate layer that provides the required organizational and technical support to the Citizen Science community so that their data sets become better discoverable, accessible, and potentially more widely used - thereby also amplifying visibility and impact of the individual projects.

We consider such structures particularly important in view of larger mobilization campaigns of Citizen Science projects, as, for example, planned within the context of the Earth Challenge 2020 (EC2020). Again, also here the two/multiple-step approach - where project resources become discoverable first and commonly accessible in a second stage - might be most realistic in order to progress more quickly and to have intermediate results.

In order to move ahead, we identified requirements that we are grouping in different approaches that complement each other.

This IE helps us to identify current possibilities and to shape parts of the way forward. However, the work of the IE has also left a few questions unanswered and raised some new issues. We should develop different scenarios to meet the identified organizational requirements exposed before. From our experiences, we see particular needs to further investigate the following aspects.

While focusing on the connection to GEOSS here, we should also investigate how this work relates to the provision of metadata for ‘flat’ online searches (e.g., Google search) and accessibility of the data to automatic web crawlers. We might want to address both topics in a single go. If we will work towards intermediate organizational structures with the help the Citizen Science community in using OGC standards and the GEOSS Platform for improved data policies and management, can these intermediaries – and the tools and services they provide – also automatically cover these complementary needs?