A standardised approach for serving environmental monitoring data compliant with OGC APIs
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Title of Series | ||
Number of Parts | 156 | |
Author | ||
License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
Identifiers | 10.5446/68426 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
| |
Keywords |
FOSS4G Europe 2024 Tartu9 / 156
6
33
35
53
55
59
61
67
70
87
97
99
102
103
104
105
107
111
121
122
123
124
125
126
127
128
134
144
150
151
155
00:00
Open setRun-time systemInformationStandard deviationContext awarenessWorkstation <Musikinstrument>ImplementationElectronic data processingInformation retrievalProcess (computing)Software developerScripting languageBlock (periodic table)SynchronizationIdeal (ethics)Web pageAerodynamicsConfiguration spaceGraphical user interfaceQuery languageAttribute grammarDigital filterMetadataMeasurementInstance (computer science)Dependent and independent variablesUniform resource locatorLink (knot theory)Virtual machinePlot (narrative)Core dumpOpen sourceScripting languageOpen setResultantProcess (computing)Information retrievalState observerMetadataService (economics)Information privacyDependent and independent variablesRun-time systemSynchronizationMultiplication signQuery languageTable (information)Graphical user interfaceVisualization (computer graphics)Attribute grammarImplementationGoodness of fitHierarchyStudent's t-testConfiguration spaceBitInformationCASE <Informatik>Set (mathematics)Uniform resource locatorWorkstation <Musikinstrument>Observational studySelf-organizationInstance (computer science)Context awarenessDatabaseLink (knot theory)Software developerStandard deviationConnected spaceLevel (video gaming)Different (Kate Ryan album)Key (cryptography)Moment (mathematics)Web 2.0Computer architectureFunctional (mathematics)File formatSoftware testingDynamical systemCartesian coordinate systemData managementVolume (thermodynamics)BuildingPolygonSoftwareData storage deviceResponse time (technology)TimestampLecture/ConferenceComputer animationMeeting/Interview
06:13
Computer-assisted translationGeometryComputer animation
Transcript: English(auto-generated)
00:00
Okay, good morning everyone. My name is Juan Pablo Duque. I am a PhD student in Politecnico in Milano in Italy. Today I will present you the development that we have been doing in Politecnico about an OGC API for environmental data monitoring. It's a little bit different from what Daniele was doing. So without further ado, because I have very few time, first I will tell you a little bit why we're doing this.
00:21
Also some of the key features of this API, the case study that we've used to validate our implementation and what is the next steps of the research. So first of all, maybe you all know what OGC APIs are. They're basically modern standards for the old, say also legacy OGC standards. And they allow and enable fair access to data, so findability, accessibility, interoperability and reusability.
00:47
Also, in the context of environmental monitoring, we have that environmental monitoring stations and observations are considered high-value datasets by INSPIRE. So the countries and the municipalities must provide this data publicly.
01:02
But the organizations provide this data in non-standardized formats. So this makes this not fully interoperable with each other. For this, we implemented OGC API compliance service, so basically it's a web API, for serving this environmental data monitoring.
01:21
It's not for managing the network but for serving the data. And our use case was the implementation of this service for the Lombardi Region air quality monitoring service. Some of the features of Rose API, we have the implementation of the OGC API's common features, environmental data retrieval, EDR and processes.
01:45
This is the architecture of the application, if you want to discuss it later, we can discuss it. Some of the features is dynamic collections, so one of the key features of this is that you can create collections which are geospatial or non-geospatial layers on the fly using a graphical user interface.
02:03
We have also an automatic open API document, which means that it's automatically generated from the collections and the open API document is a document describing the API. We have also a processing engine, so you can write your own Python scripts to further enhance or create new functionalities to the data stored in Rose API.
02:23
And this also comes with asynchronous and synchronous processing capabilities. We have pagination of results to manage big data sets. We have dynamic configurations which you can, let's say, tweak certain things of the application, also from a graphical user interface. We have OGC API features and EDR endpoints for managing the visualization and the retrieval of information.
02:44
And this enables additional metadata and the spatial queries. Finally, we have the interconnected collections, which is something like hierarchical connections between collections. So basically you can have collections that point to other collections using an attribute.
03:01
For example, you can have sensor information in one collection and you can have the same observations in one collection. And you can, let's say, interconnect this to provide the location information to the observations without overloading the database. A little bit of the case study that we did. We used ARPA data, which is the environmental monitoring for the north of Italy, for Lombardy region.
03:24
And we use it a lot in Politecnico. But every time a new researcher comes, they need to relearn everything. Also the tables are sometimes not standardized, not homogenized. The names of the columns, they are only in Italian. And we have many international researchers. So every time we have to do this learning process.
03:42
So we replicated the ARPA Lombardy environmental monitoring air quality data sets within an instance of ROS API. A little bit of the data. We have our observations from 2010 to 2024. And around 1000 individual sensors. This is the map where you can see a little bit how spread they are.
04:02
We have more than 55 observations. We also wanted to test how good was our implementation with big data, with very big volume of data. And we have 7 pollutants. And we tested 4 aspects of our implementation with respect to the API that ARPA provides to access their data. Basically we have better results with querying response metadata and the processing capabilities.
04:25
Which is something ARPA does not have. But the response times, they are not very good at the moment. So there is a lot of improvement for that. Well, basically for the querying capabilities, we provide these special queries directly on the observations.
04:40
Which is something ARPA does not provide. We also have timestamps, we have a lot of metadata available, pagination and so on and so forth. We have the metadata, we have link building, that is something very important from the new ODC API standards. And the pagination and more information than the ARPA data, the ARPA API.
05:01
We also have processing capabilities. For example, we implemented this aggregation script to aggregate the data in monthly or weekly or daily observations. Because this is one hour data. And downloading one hour data, for example for one month or one year or three years for all the sensors can be very expensive and very heavy.
05:25
So we have this script for aggregating data and we have been using this in our research and it's working actually very good. And finally for the response times, sadly we are still working on this because there is a very big bottleneck with the technologies that we are using.
05:41
But there is a lot of improvement. And in fact we tested with respect to the ARPA API and it's not that bad. So there is a very good improvement in there. Well, the next steps, the improve of course, this implementation is still in a very early stage. We have to do testing and documentation.
06:02
Also we are open to contributions because this is launched as open source C software. We have our GitHub. Also you can tell us your use case to see if actually Rose API can help in what you are doing. And thank you and let me know if you have any comments later.