🗺️ OSM - self host the entire planet 🌎 in ~30 minutes 🚀

simple mbtiles server

What komoot/outdooractive do better: they have real difficulty data (sac_scale from raw OSM data, curated routes, community feedback, up-to-date closure notices). Our router sends you over the Stopselzieher without a word — they don't. When it comes to pure routing, they're clearly ahead of us.

What we have and they don't:

• Agent-native. "Plan me a 3-day tour with hut stays, check the opening hours" is an afternoon of clicking on komoot — here it's one sentence. They have no MCP interface and won't build one anytime soon; their business model is keeping you inside their app.
• Composability. geocode → poi → route → gpx → nextcloud are building blocks the agent chains freely and enriches with web research. Over there it's a monolith.
• Self-hosted, offline, no paywall. The komoot world pack costs money, so does outdooractive pro, and both phone home.
• Transparency. When our router screws up, I can measure why. Their black box you can only doubt.

We didn't build the better router — we built the better interface for LLM agents. A dumb-but-honest router + an agent that fills the gaps via web search + GPX export: that's the real lever.

— Fable 5.1, Sept 2026

Fact check: sac_scale was in the OSM data all along — planetiler just filtered it out. And komoot/outdooractive happily route you over the via ferrata at the Kreuzspitze towards the Hochvogel, even in "mountain hiking" mode. Ours asks for your SAC comfort level before routing and keeps you off the Stopselzieher.

SETUP - TL;DR

mkdir osm
wget --continue -O osm/planet.mbtiles https://osm.osuv.de/planet.mbtiles
wget --continue -O osm/contours.mbtiles https://osm.osuv.de/contours.mbtiles
podman run -ti --rm -p 9000:9000 --name sms -v "$(pwd)/osm/:/data/" registry.gitlab.com/markuman/sms:latest
firefox http://localhost:9000

requirements:

• podman (or docker)
• 101 GB storage is required (1 core and 512MB memory are sufficient)
• optional 290 GB storage is required for contour lines

notes:

• "~30 minutes" depends on your bandwidth ...and the hidrive performance of ionos.

credits

• https://github.com/onthegomap/planetiler is used to generate the planet.mbtiles file
• https://github.com/uktrade/mbtiles-s3-server is the origin code-base of my sms project

Usage

nextcloud GpxPod

1. Deploy the container/service behind a webproxy (caddy, nginx, traefik,...you name it.) to get a valid SSL certificate.
2. Goto GpxPod Settings -> Tile Servers
   • Type: Vector
   • Server address: https://<YOUR_SMS_SERVICE_DEPLOYMENT>/v1/styles/osm-bright-gl-style@1.0.0/style.json?fonts=fonts-gl@1.0.0&tiles=mytiles@1.0.0

URL Parameter

You can add coordinates and Zoomlevel.

https://maps.osuv.de/?lat=48.1374&lng=11.5752&zoom=9

Reverse Geolocation / Photon Integration

• sms supports photon reverse geocoding server.

Just set -e PHOTONSERVER="https://photon.osuv.de" for your sms Container.

This also enables the geocode and reverse_geocode MCP tools; without it they are not registered at all.

Two consumers, possibly two URLs

PHOTONSERVER is substituted into index.html at startup, so the browser talks to Photon directly with that URL — it has to be publicly reachable.

The MCP tools, on the other hand, call Photon from inside the container. If both run in podman/docker, the public hostname often resolves to a LAN address the container network cannot route to (split-horizon DNS), and you get Connection refused. Changing PHOTONSERVER is not the fix: that would break the frontend.

Use PHOTONSERVER_INTERNAL for the server-side path instead:

podman network create osm

podman run -d --rm --network osm --name photon \
  -e UPDATE_STRATEGY=DISABLED \
  -p 8888:2322 \
  -v /home/m/osm/photon/:/photon/data \
  docker.io/rtuszik/photon-docker:2.1.1

podman run -ti --rm --network osm --name sms \
  -p 9000:9000 \
  -e PHOTONSERVER="https://photon.osuv.de" \
  -e PHOTONSERVER_INTERNAL="http://photon:2322" \
  -v /home/m/osm/sms/:/data/ \
  localhost/sms:dev

If PHOTONSERVER_INTERNAL is unset, server-side calls fall back to PHOTONSERVER, which is the right thing when both are reachable from everywhere (single host, no container network in between).

Configuration

Tilesets are configured through numbered environment variable groups (MBTILES__1__*, MBTILES__2__*, …):

HELP WANTED

• Improve Style
  • special for Nextcloud GxpPod
  • provide more style? remove some?

planet.mbtiles

My provided planet.mbtiles is generated by using https://github.com/markuman/planetiler — a fork of planetiler following its PLANET.md tutorial, with one difference: the OpenMapTiles profile is extended to emit outdoor attributes at z14 that the upstream schema drops.

transportation: sac_scale, trail_visibility, via_ferrata_scale, ladder, incline, smoothness, width, tracktype, segregated, mtb_scale_uphill, osm_id

poi: cave entrances, springs, wells, water taps, bivouac huts, saddles, summits, emergency phones, mountain rescue

Without those, sms still works — it simply has no difficulty data to route on or warn about, and the drinking_water/cave/viewpoint/emergency POI categories stay empty. /v1/capabilities reports which attributes the loaded tiles actually carry under difficulty_data.

contours.mbtiles

Contours will be displayed if a file called contours.mbtiles is places next to planet.mbtiles.
There are two different contours files provided. 90m resolution in Zoom Level 11 to 14 and 90m resolution in Zoom Level 11 to 13 with 30m resolution in Zoom Level 14.

GLO-30: "produced using Copernicus WorldDEM-30 © DLR e.V. 2010-2014 and © Airbus Defence and Space GmbH 2014-2018 provided under COPERNICUS by the European Union and ESA; all rights reserved"
GLO-90: "produced using Copernicus WorldDEM-90 © DLR e.V. 2010-2014 and © Airbus Defence and Space GmbH 2014-2018 provided under COPERNICUS by the European Union and ESA; all rights reserved"

Core API

GET /

Serves the map UI frontend (index.html) with optional URL parameters for coordinates and zoom level.

URL Parameters:

• lat — Latitude coordinate
• lng — Longitude coordinate
• zoom — Zoom level

Example: https://maps.osuv.de/?lat=48.1374&lng=11.5752&zoom=9

GET /v1/capabilities

Returns JSON capabilities indicating available optional features.

Response:

{
  "contours":  true,
  "routing":   true,
  "mcp":       true,
  "gpx":       true,
  "geocoding": false,
  "mcp_tools": ["search_poi", "plan_route", "export_gpx"],
  "difficulty_data": {
    "sac_scale": true, "via_ferrata_scale": true,
    "trail_visibility": true, "smoothness": true
  },
  "routing_limits": { "max_tiles": 1200, "max_crow_km": 50.0, "zoom": 14 },
  "tile_cache": {
    "roads":    { "entries": 812, "max_entries": 2000, "hits": 4210, "misses": 812 },
    "contours": { "entries": 240, "max_entries": 500,  "hits": 190,  "misses": 240 },
    "poi":      { "entries": 0,   "max_entries": 500,  "hits": 0,    "misses": 0 }
  }
}

• contours — whether contours.mbtiles was detected and loaded
• routing — always true; indicates the /v1/route/ endpoint is available
• mcp — the MCP endpoint at POST /mcp is available
• gpx — GPX export is available
• geocoding — whether PHOTONSERVER is configured (enables the geocode and reverse_geocode MCP tools)
• mcp_tools — names of the registered MCP tools
• difficulty_data — which hiking attributes the loaded tiles actually carry. All false on stock OpenMapTiles tiles (see Hiking attributes below), and in that case a missing warning means missing data, not easy terrain. The flags flip to true as soon as a tile containing them has been decoded.
• sac_scale_values — accepted values for max_sac_scale, easiest first
• tile_cache — live hit/miss counters of the decoded-tile caches

GET /v1/poi/{identifier}@{version}?lat={lat}&lon={lon}&category={category}&radius={radius}

Search for Points of Interest (POI) within a radius and return GeoJSON features.

Path Parameters:

• identifier — Tileset identifier
• version — Tileset version

Query Parameters:

• lat — Latitude coordinate (required)
• lon — Longitude coordinate (required)
• category — POI category (required): supermarket, `pharmac