Project Details

The Challenge | Surface-to-Air (Quality) Mission

Your challenge is to integrate NASA data, ground-based air quality data, and citizen science data to create an air quality surface that displays the most accurate data for a location and time. Create algorithms that select or weight the best data from several sources for a specific time and location, and display that information.

One Air

OneAir provides both API and global browser-based air pollution map. A flexible API is using Apollo Federation and multiple GraphQL APIs to join multiple sources of data both from NASA satellites and other APIs. Browser map displays this data for users.

Kosminiai Velniai

We have created both an API and browser-based map that displays data from our API. The API is using Apollo Federation gateway to stitch together schemas from multiple GraphQL APIs. There are two GraphQL APIs which are separated by type of measurement they provide. First API provides Aerosol Optical Depth data taken from pre-generated data from NASA satellites Terra and Aqua (MODIS instrument) with possible integration to other satellites. Second API provides Air Quality Index as well as many other pollutant measurements, taken from WAQI API, which is free and open to public use. We have also integrated with 'fake' home sensor to illustrate how data can be gathered from multiple sources that we later map to our resources.

This architecture allows us to achieve couple of things:

  • Apollo Federation allows us to keep adding other APIs with other measurement types without worrying about version control, backwards compatibility, etc. It also allows APIs to extend resources from other APIs , for example to provide additional calculations on those resources.
  • GraphQL allows us to declare resources that our API provides without the need of defining contracts and endpoints, which in our case is a big advantage over other technology such as RestAPIs. It also means that users of our API have the freedom to select any data they need thanks to GQL query language.
  • Splitting APIs by measurement types means that we can easily integrate with more and more data sources of same tyope, be it CSV files, APIs, RSS feeds. We would map these to our defined types and immediately have this data available to our users.
  • In future we are planning to add machine learning API to existing collection, that would based on existing measurements provide predictions of Air Quality Index for near future, as well as provide information on extreme situations, where based on local weather data we could warn users about the changes to extreme situation, such as where air pollutants move with wind, or how soon these pollutants would disappear.


Our browser-based map is based on Google Maps API, and demonstrates what data our API currently provides in an interactive way. It's goal is to be simplistic and user-friendly, and we have future plans to add measurement explanations, air quality predictions as well as extreme situation notifications.


Our proof-of-concept of browser-based map is hosted on Heroku here: http://nasa-air-pollution-app.herokuapp.com/

Our API is also hosted on heroku. Example curl request:


curl -X POST \

http://air-pollution-api.herokuapp.com/ \

-H 'Accept: application/json' \

-H 'Content-Type: application/json' \

-d '{"query":"{ getStations(minLat: 56.065, minLong: 21.182, maxLat: 54.315, maxLong: 25.481) { name, latitude, longitude, aqi } }"}'



API github repository: https://github.com/lnternet/air-pollution-api

Browser-based map repository: https://gitlab.com/nasa-challenge/air-pollution


Resources: pre-generated MODIS data included in challenge example resources, WAQI API, Google Maps API.