OpenInfraMap and the pipeline that turns OSM data into map tiles

Infrastructure only, and that is the point

Open Infrastructure Map is a map showing the world's infrastructure from OpenStreetMap, and the live site is at openinframap.org.

The scoping is narrower than it might sound. This is not a general basemap with a different style. It is a view of infrastructure data, which is a category of OSM mapping that includes the things most basemap renderers leave out or de-emphasise: power lines and substations, water and wastewater infrastructure, telecommunications sites, and similar physical plant.

That focus has a practical consequence for anyone building on it. The data underneath is the full OSM database, imported with imposm3, and the repository is tagged with imposm3, postgis, tegola, maplibre-gl-js, gis and openstreetmap, which is essentially the whole stack in one line. The front end draws with MapLibre, the vector tiles come from Tegola, and the spatial database is PostGIS.

The audience is people who need to see infrastructure, and the project is openly interested in contributions of that kind. The README notes the project is aiming to be multilingual, with translations on Weblate, and that anyone can add a new language there, raising an issue once a translation passes 75 percent complete so it can be enabled on the site. The community channels are the usual set, an IRC channel and a Matrix room both under osm-infrastructure, plus a Mastodon account.

The compose file is where the architecture actually is

The README is a dozen lines and points to ./docs/architecture.md for development details, so the docker-compose.yml in the repository root is the real specification.

The stack is four named volumes and three services. The volumes are for the database and for the three imposm working directories:

volumes:
  postgres_data:
  imposm_cache:
  imposm_expiry:
  imposm_diff:

services:
  db:
    image: postgis/postgis:17-3.4-alpine
    shm_size: 128mb
    environment:
      POSTGRES_PASSWORD: postgres
    volumes:
      - postgres_data:/var/lib/postgresql/data

The database service is PostGIS 17 on Alpine, with a 128 megabyte shared memory setting, which is the standard requirement for parallel PostGIS query work. It mounts the schema files into the database's init directory, so the schema is applied on first start rather than by a separate migration step.

The imposm service is built from the imposm directory in the repository and runs the importer with a configuration that points at the three mounted directories and a mapping file:

  imposm:
    build: imposm
    volumes:
      - imposm_cache:/imposm-cache
      - imposm_expiry:/imposm-expiry
      - imposm_diff:/imposm-diff
    command:
      - run
      - -expiretiles-dir
      - /imposm-expiry
      - -cachedir
      - /imposm-cache
      - -diffdir
      - /imposm-diff
      - -mapping
      - /mapping.json

The three directories are the interesting part. The cache directory holds downloaded OSM extracts, the expiry directory holds the tiles whose expiry time has passed, and the diff directory holds incremental updates. Splitting them means an expired tile does not force a re-download of the whole extract, which is the difference between a nightly update that finishes and one that does not.

The third service is the tile server:

  tegola:
    build: tegola
    environment:
      DB_URI: "postgres://osm:osm@db:5432/osm"
    ports:
      - "8080:80"

Tegola reads from the same PostGIS database and publishes on port 80 inside the container, mapped to 8080 on the host. Note what is not in the compose file: no web, web-backend or web-router service. The front end and the API layer exist in the repository, in web/, web-backend/ and web-router/, but the compose file here wires up the data side only.

The mapping file decides what you actually see

The imposm service is given a -mapping argument pointing at /mapping.json, mounted from the imposm build context. That file is the heart of the project.

imposm3 imports OSM data by applying a mapping configuration, and the mapping declares which OSM tags and layers are extracted into which PostGIS tables. Everything the map shows has to be declared there, and everything the map does not show has been left out by that file.

This is the design decision that makes OpenInfraMap different from a general basemap. A full OSM import carries roads, buildings, landuse, places, everything, and the rendering layer decides what to draw. An infrastructure-focused import carries the subset that matters for the subject, which keeps the database smaller, the tile generation faster, and the map legible.

The trade is that anything not in the mapping is not in the database, so extending the map to a new infrastructure type is a schema and configuration change rather than a rendering change. The repository has a schema directory with dev-init.sql and functions.sql, which are the two files mounted into the database init directory, and a functions.sql in particular suggests post-processing in the database itself, which is the usual way to turn raw OSM way and node tables into ready-to-tile geometries.

The mapping file and the schema are the two things to read before deciding whether this project can answer your question, and the README does not summarise either.

Vector tiles and the front end

The stack above the database is a vector tile service and a web client, and the repository layout names the parts: web/ for the front end, web-backend/ for the API layer, web-router/ for routing, tegola/ for the tile service build, imposm/ for the importer build, and docs/ for the architecture documentation.

Tegola is a Go server that turns PostGIS tables into Mapbox vector tiles on request, and it is the component that decides the tile schema, the zoom levels and the layer names the client asks for. The front end then draws with MapLibre, which is the open-source Mapbox GL renderer.

Choosing vector tiles over raster rendering is what makes the map interactive and what allows the client to restyle layers without new server round trips. It also means the tile service is on the hot path of every pan and zoom, which is why the compose file publishes it on a port of its own.

The backend and router exist as separate directories, which suggests the deployment is not a single static site but a service with server-side routing. The README does not describe them, and the compose file does not include them, so how they are deployed in the live environment is not something this repository documents.

What the repository does make clear is the shape of the system: an importer that keeps a spatial database current with OSM extracts, a tile server that reads from that database, and a client that renders the tiles. Anyone joining the project needs to understand which part they are changing.

Licence, contributions and what is undocumented

The licence is BSD-3-Clause, which is permissive and puts no conditions on a deployment that uses the data or the code beyond the notice. For a project whose input is OpenStreetMap data, the interesting question is not the code licence but the data licence, and the README does not address how the OSM attribution and the share-alike terms on the underlying database are handled in the rendered output. A team republishing tiles from this stack should check that themselves rather than assume the BSD licence settles it.

On maintenance, the repository is not archived and the last push was on 2026-10-16, so the work is current. There are no GitHub releases, which for a deployed application is a reasonable choice and means there is no versioned artefact to pin.

Two gaps are worth naming. The first is the schema. There is a dev-init.sql mounted as the first init script and a functions.sql mounted as the second, and the numbering in the compose file, 90-dev-init.sql and 91-functions.sql, shows they are sequenced to run after the PostGIS image's own initialisation. But the README does not describe the tables, so understanding the data model means reading the SQL.

The second is the imposm command. The compose file runs imposm with run and a set of directories and the mapping, but there is no mention of a planet extract, a regional extract or an update interval anywhere in the README, and the imposm directory in the repository root is where that configuration lives. A full planet import is a serious amount of disk and time, and the operational question of what to import and how often is answered somewhere other than the README.

Editorial conclusion

OpenInfraMap is a good fit for a GIS engineer or a data visualisation team that wants infrastructure data rendered from OpenStreetMap without building the import and tiling stack from scratch, because the repository ships the whole pipeline including the PostGIS schema and the imposm configuration. It is a poor fit if you need a general-purpose basemap, since the data is deliberately limited to infrastructure rather than streets and places, and a poor fit if you cannot run PostGIS and a tile server. Before deploying, read docs/architecture.md, since the README defers the development setup to it, and check the imposm mapping file that the compose file mounts, because that is where the choice of which OSM tags become map layers is actually made.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. openinframap/openinframap on GitHub
4. Project website
5. README