OpenStreetMap self-hosten met Docker

NAS, nederland
openstreetmap tile server bart
OpenStreetMap self-hosten met Docker: een nationale tileserver op een Synology NAS

In een eerder bericht Aan de slag met OpenStreetMap beschreef ik hoe OpenStreetMap (OSM) kan worden gebruikt als open en flexibel alternatief voor commerciële kaartdiensten. In dit vervolgartikel ga ik een stap verder: het zelf hosten van een OpenStreetMap tileserver, inclusief automatische updates, caching en beheer; zelfs op een Synology NAS.

Dit artikel beschrijft de gekozen architectuur, de Docker-configuratie, het renderen en beheren van de kaart-tegels (tiles) maar ook de overwegingen bij de keuzes die ik heb gemaakt bij de instellingen.

Architectuurkeuze: Docker-based tileserver

Voor deze installatie is gekozen voor de open source Docker image:

overv/openstreetmap-tile-server

Deze image combineert:

  • PostgreSQL + PostGIS
  • osm2pgsql
  • mod_tile + renderd
  • automatische replicatie via OSM diff-bestanden

De image wordt actief onderhouden en is gebaseerd op de best practices zoals gedocumenteerd in de OpenStreetMap-community.

Broncode en documentatie zijn beschikbaar op GitHub

Importeren van de kaart

Voordat de tileserver volledig operationeel is, moet de basiskaart van Nederland worden geïmporteerd. Hiervoor wordt een aparte container gebruikt die specifiek bedoeld is voor de import van de OSM-data. Deze container downloadt de meest recente PBF-file van Geofabrik en importeert deze in de PostGIS-database. De Docker Compose configuratie voor import is hieronder weergegeven:

services:
  osm-import-nl:
    container_name: osm-import-nl
    hostname: osm-import-nl
    environment:
      - OSM2PGSQL_EXTRA_ARGS=-C 16384 # cache value in MB
      - REPLICATION_URL=https://planet.openstreetmap.org/replication/minute/
      - TZ=Europe/Amsterdam
      - UPDATES=enabled
      - MAX_INTERVAL_SECONDS=60
      - THREADS=4
      - DOWNLOAD_PBF=https://download.geofabrik.de/europe/netherlands-latest.osm.pbf
      - DOWNLOAD_POLY=https://download.geofabrik.de/europe/netherlands.poly
      - PGPASSWORD=68ku26vDkihoY2ohJiMG
    restart: on-failure:5
    mem_limit: 20g
    cpu_shares: 2048
    shm_size: 20g
    volumes:
      - osm-data-nl:/data/database/
      - osm-tiles-nl:/data/tiles/
      - /dev/shm:/dev/shm 
    image: overv/openstreetmap-tile-server
    command: import
Toelichting:

  • DOWNLOAD_PBF en DOWNLOAD_POLY: deze bestanden bevatten respectievelijk de volledige kaartdata van Nederland en de bijbehorende polygoon die het te importeren gebied afbakent.

  • OSM2PGSQL_EXTRA_ARGS=-C 8192: hiermee wordt de cache ingesteld op 8 GB voor de import, zodat het proces efficiënt kan werken zonder dat de NAS overbelast raakt.

  • UPDATES=enabled en REPLICATION_URL zorgen ervoor dat de database later automatisch up-to-date blijft via minute-diffs van OpenStreetMap.

  • volumes koppelen de database en tiles naar de externe Docker-volumes, zodat de data persistent blijft en kan worden gebruikt door de rendering-container.

  • command: import start het importproces in plaats van de rendering. Dit proces kan enkele uren duren, afhankelijk van de snelheid van de NAS en de omvang van het gebied.

Na succesvolle import kan de osm-tileserver-nl container starten met rendering en expiry van tiles. Het is aan te raden om dit proces éénmalig zorgvuldig te monitoren, omdat een incomplete import kan leiden tot ontbrekende of foutieve tiles in het zichtbare kaartgebied.

Tileserver: rendering en beheer van tegels

De osm-tileserver-nl container is verantwoordelijk voor het renderen en serveren van de individuele kaarttegels die uiteindelijk in een webapplicatie of GIS-tool kunnen worden weergegeven. Deze container maakt gebruik van Mapnik en renderd om de tegels op basis van de geïmporteerde OSM-data te genereren.

services:
  osm-tileserver-nl:
    mem_limit: 20g
    cpu_shares: 2048
    ports:
      - 8050:80
    container_name: osm-tileserver-nl
    hostname: osm-tileserver-nl
    restart: on-failure:5
    environment:
      - OSM2PGSQL_EXTRA_ARGS=-C 16384
      - REPLICATION_URL=https://planet.openstreetmap.org/replication/minute/
      - TZ=Europe/Amsterdam
      - MAX_INTERVAL_SECONDS=60
      - THREADS=4
      - ALLOW_CORS=enabled
      - UPDATES=enabled
      - EXPIRY_MINZOOM=8
      - EXPIRY_TOUCHFROM=10
      - EXPIRY_DELETEFROM=15
      - EXPIRY_MAXZOOM=20
      - PGPASSWORD=********
    volumes:
      - osm-data-nl:/data/database/
      - osm-tiles-nl:/data/tiles/
    image: overv/openstreetmap-tile-server
    command: run
    healthcheck:
      test: wget --no-verbose --tries=1 --spider http://localhost

volumes:
  osm-data-nl:
    external:
      name: osm-data-nl
  osm-tiles-nl:
    external:
      name: osm-tiles-nl
Toelichting:

  • Rendering: renderd verwerkt tile-requests op basis van Mapnik-stijlbestanden en slaat deze op in het osm-tiles-nl volume. Tegels worden gegeneerd op basis van de geïmporteerde database. Bij het eerste renderen kan het genereren van grote gebieden (bijv. heel Nederland) uren tot dagen duren.

  • Prerendering: aanbevolen voor veelgebruikte zoomlevels (bijvoorbeeld 10–16 voor Nederland). Hierdoor zijn tegels direct beschikbaar en wordt de belasting op de NAS beperkt.

  • Expiry en cache: variabelen zoals EXPIRY_MINZOOM, EXPIRY_TOUCHFROM, EXPIRY_DELETEFROM en EXPIRY_MAXZOOM reguleren wanneer tegels ververst of verwijderd worden. Tiles boven EXPIRY_DELETEFROM worden daadwerkelijk verwijderd om schijfruimte te sparen en verouderde data te vermijden.

  • Updates: met UPDATES=enabled en de minute-diffs via REPLICATION_URL blijft de database continu up-to-date. Dit voorkomt dat nieuwe wegen of wijzigingen te laat zichtbaar zijn.

  • Performance: OSM2PGSQL_EXTRA_ARGS=-C 16384 zorgt voor een grotere cache bij rendering. Op een NAS zoals de DS923 is het belangrijk de mem_limit overeen te laten komen met deze cache-instelling om memory errors te voorkomen.

  • Logging: render- en expiry-activiteiten worden gelogd in /var/log/tiles/. Het is verstandig om logrotatie in te stellen zodat de logs beheersbaar blijven.

Hoe werkt tile rendering?

OpenStreetMap tiles worden on demand gerenderd:

  1. Een client (browser, app) vraagt een tile op.
  2. Bestaat de tile al in de cache, dan direct serveren.
  3. Bestaat deze niet, dan genereert renderd de tile via Mapnik.
  4. De tile wordt opgeslagen op disk voor hergebruik.

Dit betekent dat het eerste bezoek aan een gebied traag kan zijn, terwijl vervolgbezoeken snel zijn.

Expiry-strategie

OSM-data verandert continu. Om wijzigingen zichtbaar te maken zonder alles opnieuw te renderen, wordt gewerkt met tile expiry.

De gekozen instellingen zorgen voor:

  • Geen expiry op wereld- en landniveau (zoom < 8)
  • Automatische vernieuwing op straatniveau
  • Verwijderen (en dus opnieuw renderen) van zeer gedetailleerde tiles

Deze strategie voorkomt onnodige belasting en houdt de kaart actueel.

Prerendering

Voor Nederland worden bepaalde zoomniveaus vooraf gerenderd via geplande taken (cron):

  • Dagelijks: zoom 10–12
  • Wekelijks: zoom 13–14
  • Hogere zooms: alleen on-demand

Belangrijk om te benadrukken: het renderen van tiles kost tijd. Voor een volledig land op meerdere zoomniveaus kan dit uren tot dagen duren, afhankelijk van hardware en gekozen detailniveau. Daarom heb ik hier gekozen voor alleen Nederland hoewel ik graag de buurlanden België en Duitsland erbij had gehad.

Logging en logrotatie

De container schrijft diverse logs, onder andere:

  • import- en update-logs
  • expiry-logs
  • osm2pgsql-logs
  • prerender-logs (via eigen scripts)

Om te voorkomen dat logs onbeperkt groeien, wordt gebruikgemaakt van logrotatie op de host. Een eenvoudige configuratie ziet er als volgt uit:

/volume1/docker/logs/osm/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    copytruncate
}

Dit leidt tot een gzip bestand van de bestaande logs en schoont het logbestand zelf op. Hiermee borg ik:

  • beheersbaarheid
  • voorspelbaar schijfgebruik
  • audittrail voor troubleshooting
Waarom OpenStreetMap self-hosten?

Zelfs op een Synology DS923, die hier niet primair voor ontworpen is, biedt self-hosting duidelijke voordelen:

  • Volledige controle over data, stijl en updates
  • Geen afhankelijkheid van commerciële API’s of quota
  • Privacy by design: geen tracking, geen third-party calls
  • Leerwaarde: inzicht in geo-infrastructuur en schaalbaarheid
  • Robuustheid: lokale beschikbaarheid, ook bij netwerkproblemen

Hoewel de DS923 geen GPU heeft en beperkt is in CPU-capaciteit, blijkt hij voor nationale dekking en gematigd gebruik verrassend goed inzetbaar mits de configuratie en bovenal de verwachtingen realistisch zijn.

Tot slot

Het zelf hosten van OpenStreetMap is geen “klik-en-klaar” oplossing. Het vraagt om:

  • begrip van caching en rendering,
  • aandacht voor updates en onderhoud,
  • en acceptatie dat de initiële rendering tijd kost.

Daar staat tegenover dat je beschikt over een volledig autonome kaartinfrastructuur, gebaseerd op open data en open software. Stel dat Google Maps of mijn favoriet opentopomap.org eruit ligt, dan heb ik altijd nog de kaartinformatie zelf bij de hand via mijn eigen server.

Bronnen

Geef een reactie

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *