3. Technical architecture

This chapter is targeted at those who want to get familiar with the inner workings of the project. It should provide an understanding of the main flow of the application and contains important guidelines for those that want to contribute adapters. For a detailed overview of the API, please read the API docs.

Application flow

The main flow of the application is as follows:

1. fetch.js runs every 10 minutes
2. it loops over the list of sources found in /sources
3. each source calls an adapter that fetches the data and processes it into the desired format
4. the adapter returns the basic data about the measurement. This is then combined with any default values set in the source.
5. the application saves every measurement to the database. When it does so, it will check for uniqueness on the following combination of fields:

• date
• location
• parameter
  If a measurement is not unique, it will be discarded.

Sources

[...]

In some cases, the values specified in the source JSON can be overwritten by the adapter. This provides flexibility to set a default value in the source, but also overwrite it on a measurement level.

Adapters

One adapter to many sources

What data is stored to the database?

Not every measurement that is passed by an adapter makes it to the database. Before storing anything, the system performs some last checks.

Uniqueness

A measurement needs to be unique. For Open AQ this means that there is no other record with the same combination of:

• date
• location
• parameter

Accepted units

The system accepts values that are reported in µg/m3 and ppm.

./lib/utils.js contains a function that handles conversion between the volumetric concentrations (ppt -> ppm, ppb -> ppm, etc.) and the mass concentrations (mg/m3 -> µg/m3).

Read more about Open AQ's preferred units.

Accepted pollutants

[Add link to list with accepted pollutants]