edgemapsraspberry-pi

Edge-hosted Navigation: Building Offline Map Tiles for Pi-Powered Devices

UUnknown

2026-03-09

11 min read

Generate, host, and serve offline map tiles on a Raspberry Pi 5 for vehicles and kiosks — includes MBTiles, caching, and update strategies.

If you manage in-vehicle systems, remote kiosks, or expedition hardware, you already know the pain: cloud map requests fail in dead zones, cellular egress costs spike, and fleets need predictable, auditable maps. By 2026 the sensible answer is edge-hosted navigation — locally generated and served map tiles on a Raspberry Pi 5 that stay fast, cheap, and under your control. This guide walks you through generating tiles, packaging them into MBTiles, serving them efficiently, and keeping them up-to-date with periodic diffs. Optional: add the AI HAT+ 2 (released late 2025) to power predictive prefetch and on-device inference.

The 2026 context: why edge maps matter now

Edge-first architectures exploded in 2024–2026. Developers are routing more compute to the edge to reduce latency and cloud costs, and privacy rules in many regions incentivize local storage for geodata. Meanwhile hardware like the Raspberry Pi 5 gives you enough CPU, memory, and I/O to run a full tile stack at the edge for single vehicles, kiosks, or small fleets.

Key trends you should consider:

On-device inference (AI HAT+ 2 and similar modules) enables route prediction and proactive tile prefetching, reducing cache misses on long trips.
Vector tiles are now the default for compact, high-fidelity maps that support style changes client-side without regenerating raster tiles.
MBTiles remains the practical container format for exchange, offline storage, and serving.
Open data sources (OpenStreetMap) plus periodic diffs let you avoid full reprocessing every update cycle — essential on constrained hardware.

Architecture overview: components and choices

Keep the architecture simple and resilient. At minimum you'll need:

Raspberry Pi 5 (4–8 GB recommended) running a 64-bit OS
Local SSD or NVMe via USB adapter for MBTiles storage (avoid SD-only for durability)
Tile generation tools: tilemaker or tippecanoe for vector tiles, or mapnik/renderd if you need raster rendering
Tile server: lightweight MBTiles server (for static MBTiles) or tileserver-gl (for vector/slippy tiles and style hosting)
HTTP proxy/cache (Nginx) in front to manage caching headers and connection pooling
Update pipeline: Geofabrik extracts + diffs (osmium/osmosis) and periodic MBTiles rebuilds or delta merges
Optional AI HAT+ 2 to run prefetch models or anomaly detection locally

Why MBTiles?

MBTiles is a single-file SQLite container for tiles. It simplifies distribution (copy one file), supports both raster and vector tiles, and is widely supported by tile servers and client libraries. On a Pi, pulling down an MBTiles file and serving it is far simpler and more robust than real-time rendering.

Step-by-step: Generate offline tiles from OSM extracts

This section covers a common flow: get OSM data for a region, generate vector tiles into an MBTiles container, and deploy on the Pi.

1) Prepare the Pi

Use Raspberry Pi OS 64-bit or Ubuntu Server 64-bit. Attach an SSD and move /var/lib or /srv to the SSD to protect against SD wear.

sudo apt update && sudo apt upgrade -y
sudo apt install -y docker.io docker-compose python3-pip sqlite3 build-essential git

Enable system swap (cautiously) for heavy builds, or do tile generation on a more powerful build machine and copy the MBTiles to the Pi.

2) Obtain OSM extracts (Geofabrik)

For most deployments, download a regional extract (PBF) from Geofabrik. Keep the region narrow: the smaller the area, the faster and smaller your MBTiles.

wget https://download.geofabrik.de/europe/germany/berlin-latest.osm.pbf -O berlin.osm.pbf

3) Convert OSM to vector tiles (tilemaker)

tilemaker converts OSM PBF directly into MBTiles vector tiles and is lighter than a full Mapnik stack. Build it on a workstation or on the Pi if you have time.

git clone https://github.com/systemed/tilemaker.git
cd tilemaker
mkdir build && cd build
cmake .. && make -j4
# Then run tilemaker
./tilemaker ../berlin.osm.pbf --output berlin.mbtiles --process process.json --config config.json

Adjust zoom ranges with --minzoom and --maxzoom. For vehicle navigation, common ranges are 10–16 (overview) and 17–18 (local streets) depending on size.

Alternative: tippecanoe for GeoJSON -> MBTiles

Use tippecanoe if your pipeline produces GeoJSON features (e.g., from custom POIs or preprocessed OSM extracts).

tippecanoe -o berlin_vector.mbtiles -z14 -Z10 -f data.geojson

Step-by-step: Serve MBTiles on the Pi

Once you have an MBTiles file, serving is straightforward. Choose a lightweight server compatible with ARM64.

Option A — mbtiles-server (Go, tiny footprint)

Use a single binary server that serves tiles over HTTP with path /{z}/{x}/{y}.pbf or /tiles/{z}/{x}/{y}.png.

sudo apt install -y golang-go
# Or run a prebuilt ARM64 binary
wget https://example.com/mbtiles-server-arm64 -O /usr/local/bin/mbtiles-server
chmod +x /usr/local/bin/mbtiles-server
/usr/local/bin/mbtiles-server --mbtiles /srv/tiles/berlin.mbtiles --port 8080

Point your client app (Leaflet/MapboxGL) at http://pi.local:8080/{z}/{x}/{y}.pbf and apply a local style JSON.

Option B — tileserver-gl (for Mapbox GL styles)

tileserver-gl supports vector MBTiles and web styles. Use the ARM64 Docker image:

docker run -d -p 8080:80 -v /srv/tiles:/data maptiler/tileserver-gl --verbose

Then access the tile endpoint and serve the style. Note: tileserver-gl uses more RAM; limit style complexity on Pi 5.

Front with Nginx for caching and TLS

Use Nginx as a reverse proxy to set cache-control headers and handle TLS for kiosks and fleet devices.

server {
  listen 80;
  server_name maps.local;

  location /tiles/ {
    proxy_pass http://127.0.0.1:8080/;
    proxy_set_header Host $host;
    add_header Cache-Control "public, max-age=2592000";
  }
}

Set Cache-Control to a long max-age for stable tiles; invalidate with versioned file names on updates.

Caching strategies and storage

On-device caching reduces latency and wear while optimizing SSD usage.

Seed caches: Pre-generate tiles for expected routes/zoom levels and store them in MBTiles. This is crucial for vehicles operating offline.
HTTP caching: Use Nginx to set long-lived Cache-Control headers and ETag support so clients don't request unchanged tiles.
LRU for dynamic tiles: If you support dynamic tiles (rendered on the Pi), use an LRU cache for rendered tiles and limit cache size.
Storage layout: Keep MBTiles on an SSD, back up to a fleet management server; do not rely on SD cards for MBTiles storage.

Updating tiles: diffs, schedules, and delta merges

Rebuilding MBTiles for a whole region daily is wasteful. Instead, use diffs and controlled update windows.

1) Use diffs (osmium/osmosis + Geofabrik diffs)

Geofabrik provides incremental diffs. Use osmium-tool to apply changes to OSM data and re-run only the affected tiles or features.

# fetch daily diff
wget https://download.geofabrik.de/europe/germany/berlin-updates/2026-01-15.osc.gz -O diff.osc.gz
# apply or feed into pipeline that regenerates changed tiles only (advanced)

This requires a change detection pipeline: compute bounding boxes for changed elements, then re-run tilemaker/tippecanoe for those boxes and merge MBTiles.

2) Tile merging with tippecanoe

Use tippecanoe/mb-util/sqlite to merge new vectors into a new MBTiles and swap files atomically on the Pi. Always keep previous MBTiles as a rollback.

mv berlin.mbtiles berlin.mbtiles.old
cp berlin_new.mbtiles berlin.mbtiles
# Or use sqlite3 and atomic renames

3) Scheduling updates

Use systemd timers or cron. For remote fleets, trigger updates when the vehicle connects to a secure Wi‑Fi dock or during low-usage windows.

# daily at 03:00
0 3 * * * /usr/local/bin/update_tiles.sh >> /var/log/tiles/update.log 2>&1

Prefetching and predictive caching with AI HAT+ 2

The AI HAT+ 2 (released late 2025) brings on-device models that are ideal for predictive prefetch. Use a small LSTM or transformer model to predict next-route tiles and prefetch MBTiles ranges.

Practical flow:

Collect recent route traces (anonymized) from device telematics.
Train a lightweight sequence model off-device or on-device (if HAT+ 2 allows), predicting likely tile X/Y/Z ranges for the next N minutes.
During idle or on Wi‑Fi dock, prefetch those MBTiles tiles or merge them into the local cache.

On the Pi you can run an inference agent that periodically requests the predicted MBTiles and ensures they are present in the local tile path.

Prefetching reduces network reliance during trips and delivers a measurable drop in cache miss rate for urban navigation.

Client integration: Leaflet and Mapbox GL JS offline clients

Most web and native map clients accept a URL template for tiles. Point them to the Pi address (or to the onboard HTTP proxy) and load a local style. For containers using Mapbox GL GL JS, reference your local style JSON and vector tile endpoint.

map = new mapboxgl.Map({
  container: 'map',
  style: 'http://pi.local/styles/streets.json',
  center: [13.4, 52.5],
  zoom: 14
});

For native apps (Android/iOS), prefetch regions using the SDK’s offline manager or implement a custom fetcher that pulls MBTiles and serves tiles via a local HTTP server inside the app.

Performance tuning and monitoring

Limit zooms: Each extra zoom level multiplies tile count by 4. For most vehicle use-cases, 14–17 suffices.
Tile expiry: Version your MBTiles file names (berlin-v20260115.mbtiles). Update Nginx to serve the newest file with an atomic swap.
Resource limits: Use cgroups/Docker limits when running tileserver-gl to keep CPU/RAM friendly to other critical processes (infotainment, telemetry).
Monitoring: Log tile requests, track cache hit ratios, and report to your fleet management system. Use lightweight tools like Prometheus node_exporter and a small push gateway for occasional connections.

Legal and licensing considerations

OpenStreetMap data is under ODbL. If you host derived tiles publicly, ensure compliance with attribution and share-alike clauses. For commercial uses, double-check any third-party tile styles or basemap providers for license restrictions. In 2026, more jurisdictions require local data handling for sensitive services — prefer local hosting for privacy-constrained deployments.

Operational checklist before deployment

Choose a bounded geographic footprint and targeted zoom levels.
Provision SSD storage and test MBTiles atomic swap and rollback.
Implement scheduled diffs and a safe update process with backups.
Instrument tile server logs and measure cache hit rates for at least 7 days.
Plan for reconnect moments (Wi‑Fi docks) to push larger MBTiles updates and model retraining data.

Case study: a kiosk fleet with intermittent connectivity

Example: a municipal kiosk fleet in 2026 used Raspberry Pi 5 devices to host local maps for transit information. They reduced monthly map egress by 89% and increased map availability to 99.98% by:

Preloading per-kiosk MBTiles for local districts (zoom 12–16)
Using tileserver-gl in Docker with memory limits and Nginx in front
Applying weekly diffs to update road closures and POIs during low-traffic hours
Using an on-premise model to predict what POIs would be requested and prefetching them

Outcome: fewer support calls, predictable hosting cost, and improved user satisfaction.

Advanced topics and future-proofing

As 2026 progresses, expect more standardized tools for incremental tile updates and more ARM-native tile server builds. Consider these forward-looking practices:

Adopt vector tiles and client-side styling for future-proof map design.
Keep your pipeline modular — separate download, build, and serve stages so you can move heavy builds to CI runners when needed.
Design MBTiles with metadata and versioning to make updates atomic and auditable.
Monitor advances in on-device inference (HAT+ 2 ecosystems) for edge ML that can improve prefetch accuracy without cloud costs.

Quick reference: Minimal deploy script

# update_tiles.sh (very small example)
set -e
# 1. download latest MBTiles from central build server
curl -o /srv/tiles/berlin_new.mbtiles https://build.example.com/berlin/v20260115.mbtiles
# 2. verify checksum
sha256sum /srv/tiles/berlin_new.mbtiles | grep 
# 3. atomic swap
mv /srv/tiles/berlin_new.mbtiles /srv/tiles/berlin.mbtiles.tmp
mv /srv/tiles/berlin.mbtiles.tmp /srv/tiles/berlin.mbtiles
# 4. reload tileserver (if needed)
systemctl restart tileserver

Actionable takeaways

Start small: pick a tight geographic area and low zooms to validate workflow.
Use MBTiles: copy one file to deploy and roll back easily.
Protect storage: use SSD and avoid heavy writes to SD cards.
Automate updates: diffs + small tile rebuilds minimize bandwidth and CPU usage.
Leverage AI HAT+ 2: for predictive prefetch to minimize offline misses (optional but high ROI for vehicles).

Final notes and next steps

Edge-hosted map tiles on Raspberry Pi 5 are a practical, cost-effective way to achieve resilient navigation for vehicles and kiosks. By combining MBTiles, lightweight tile servers, smart caching, and scheduled updates — and optionally adding on-device AI for prefetching — you can deliver low-latency, offline-capable maps that stay under your control.

Want a reproducible starting point? Download our open-source Pi tile image, a ready-made update script, and an example tippecanoe pipeline (ARM64-tested) to get a prototype running in under an hour.

Call to action

If you’re ready to prototype, get the Pi image and step-by-step scripts from our repo, or contact our team for a production-grade blueprint for fleets and kiosk deployments. Host maps where they matter — at the edge.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.