Architecture

This page describes the OMI platform components.

See also infrastructure and devops for deployment info.

Overview

Services

UI

The UI (user interface) is a static frontend application that displays the computed indicators on a map. It is accessible by the end-users (visitors) at https://app.openmobilityindicators.org/ (it is hosted by netlify).

The UI queries the API to get metadata about indicators and the indicator data itself (cf. data model), and queries the tile server (cf. below).

It is developed by the OMI project team, see source code.

File server

The file server allows the visitors to browse and download the files computed by the indicators during the execution of the compute pipeline. It is accessible at https://files.openmobilityindicators.org/.

It is implemented as a static file server using Nginx.

Tile server

The tile server allows the UI to load tile data. It is accessible at https://tile.openmobilityindicators.org/.

It reads tile data (.mbtiles files) from a local directory, in which the compute pipeline writes to.

It can be reloaded on demand by the API (requires authentication by token).

It is implemented using mbtileserver, a simple Go-based software.

API

The API is a backend application that serves metadata about indicators and indicator data (cf data model) over HTTP, responding JSON documents. It is accessible at https://api.openmobilityindicators.org/.

It is the central component of the architecture: it gathers information from different sources, and exposes them in a consistent way to the other services.

It also provides commands to reload the tile server, re-index data or delete data. Those commands require authentication via a token.

It is developed by the OMI project team, see source code.

Compute pipeline

The compute pipeline runs indicators and writes the output files.

It runs on the OMI infrastructure which provides currently a relatively standard dedicated server.

It is not intended to be used by the visitors. It is targeted at the indicator authors (aka "power users") to run their indicator, or at the editors to compute a specific geographical area of an existing indicator, for example.

It produces indicator data, metadata about the computation, and tiles (if the output data are geojson files), then reloads the services to make new data available.

It is developed by the OMI project team: see source code.

Data storage

In this architecture, two services are designed to read and write data from directories:

• indicator data: contains data about indicators and metadata about computations
• mbtiles: contains .mbtiles files

Those directories are written to by the compute pipeline, and are read by the API, which can also delete data.