% IMPORTANT: The following is UTF-8 encoded. This means that in the presence
% of non-ASCII characters, it will not work with BibTeX 0.99 or older.
% Instead, you should use an up-to-date BibTeX implementation like “bibtex8” or
% “biber”.
@INPROCEEDINGS{Selke:911816,
author = {Selke, Niklas and Leufen, Lukas Hubert and Mozaffari,
Amirpasha and Schröder, Sabine and Schultz, Martin},
title = {{G}eodata enrichment for air quality},
reportid = {FZJ-2022-05064},
year = {2022},
abstract = {During the Tropospheric Ozone Assessment Report (TOAR) [1]
we built an air quality database that contains time series
of measured ozone, ozone precursors, and meteorological data
from surface observation stations. One aspect of the TOAR
database that substantially contributed to its adoption by
the research community, is the augmentation of provider
metadata for these stations with globally consistent
information derived from multiple Earth Observation data
products. This adds additional context to the description of
measurement locations and thereby enriches the analysis
possibilities. For this we developed a workflow called
Geolocation Service that we want to present here.Our
Geolocation Service exposes REST APIs to the user where they
can specify an area of interest in the form of latitude,
longitude, and possibly radius as well as a specific time
where we have data with a time resolution. With the radius
parameter it is possible to extract points (no radius) or
areas. Different REST API endpoints provide different
services, like for example topographic information and
nighttime lights. The advantage of REST APIs is that they
not only make human interaction possible but also machine to
machine communication.After retrieving the requested data
from a performant geodata service (in our case a Rasdaman
service), the service can run different analyses which the
user can specify and will return any results in a
standardized way, namely Geo-JSON. The user can choose
between a range of aggregation methods (mean, min, max,
etc.) or can choose to return the closest value to the given
coordinates. The aggregation method can be specified
directly in the REST APIs which makes it very flexible for
the user.Since this workflow consists of modular components,
it is easy to exchange or expand some of its parts. We are
interested in expanding the available datasets to include
the Copernicus Sentinels (i. e. retrieving data from the
Copernicus Open Access Hub instead of from our Rasdaman
service) to run the existing analyses on those datasets
while still providing the user with the same interface and
responses as they already know.To go even further, it would
also be possible to include landcover detection, flood
mapping, and other spatial analyses via the same geodata
workflow.[1] https://igacproject.org/activities/TOAR},
month = {May},
date = {2022-05-23},
organization = {Living Planet Symposium 2022, Bonn
(Germany), 23 May 2022 - 27 May 2022},
subtyp = {After Call},
cin = {JSC},
cid = {I:(DE-Juel1)JSC-20090406},
pnm = {5111 - Domain-Specific Simulation $\&$ Data Life Cycle Labs
(SDLs) and Research Groups (POF4-511) / IntelliAQ -
Artificial Intelligence for Air Quality (787576) / Earth
System Data Exploration (ESDE)},
pid = {G:(DE-HGF)POF4-5111 / G:(EU-Grant)787576 /
G:(DE-Juel-1)ESDE},
typ = {PUB:(DE-HGF)24},
url = {https://juser.fz-juelich.de/record/911816},
}