
TL;DR of the TL;DR: Private, self hosted, GPS enabled, local search and offline routing map engine in under a gigabyte, on a $55 SBC, accessible anywhere.
Ok…I’ve been working on this for a while and it is SO satisfying to see it to completion.
I’m calling it “Pi maps” (because the Pi hosts it) but it’s really MapLibre GL JS, served locally by nginx. The Western Australia basemap is a single PMTiles archive, clipped from the Protomaps daily build to the WA boundary, zoom levels 0-15. The finished stack is about 770 MB.
770MB!
PMTiles is one of the bits I particularly like. Instead of running a tile server and maintaining millions of little tile files or a tile database, nginx just serves one archive with HTTP Range requests. Then MapLibre asks for the byte ranges it needs.
The map-serving path is:
Browser
↓
MapLibre GL JS
↓
PMTiles JS
↓
nginx HTTP Range requests
↓
WA.pmtiles
And the best part is that I needed no PostgreSQL, PostGIS or live calls to Google etc.
But wait…there’s more! Search and routing!
Rather than install something heavy, I put together a small search service using Python, from the OSM extract.
The source data is converted into a SQLite FTS5 database and the current index contains about 300,000 source records, for a whopping…78 MB. The runtime search service uses about 11 MB RAM at idle.
Driving routes are calculated locally using BRouter, which runs as its own container and nginx proxies the route API internally to it.
The routing dataset for turned out to be remarkably small - roughly 20 MB, with a single worker and a 128 MB Java heap.
The browser gets route geometry, distance, ETA and turn instructions without calling an external routing service.
TL;DR: The current stack is basically three containers:
pi-maps- nginx + the MapLibre frontend + PMTilespi-maps-search- Python + SQLite FTS5 local searchpi-maps-brouter- local driving-route engine
After testing, the individual Maps components were around:
nginx/frontend ~7.3 MiB
search service ~11.2 MiB
BRouter ~168 MiB
--------------------------------
total ~187 MiB RAM
The complete thing - map, search database, routing data, local web assets, metadata etc ends up at roughly 770 MB.
So - a Raspberry Pi 4 is locally serving a zoomable map, POI/address search and actual driving routes for comfortably under a gigabyte of application data.
What’s more, I can use it remotely via Tailscale if I want and/or download the tiles directly to my phone and use it with something like GeoLibre or Atlas.
OSM / Protomaps data
↓
Raspberry Pi
↓
┌───────────────┐
│ WA.pmtiles │ → map
│ SQLite FTS5 │ → search
│ BRouter │ → directions
└───────────────┘
↓
Browser / phone / apps
It’s not yet a Google Maps replacement. Yet. Right now the routing profile is driving-focused; there is no live turn-by-turn rerouting, spoken navigation, traffic data, or giant commercial address database. But…I have ideas and too much free time (actually, I think I can solve the 4 of those 5 pretty simply).
Case in point: there was a cool technical problem in that the the POI polygon centroid can be a valid map location but NOT a valid driving destination. That was fun to solve.
The next thing I’m going to try is adding a wikipedia layer - or rather, a self hosted ZIM wikipedia layer - so that POIs actually resolve to clickable entries.
There. For once, I win.
PS: This was much easier to do that the whole “family chat” bullshit. Never work with children or animals.
PPS: Also, I may have broken the family chat IRC server, or at least, misunderstood how IRC uses connection resets. So…XMPP might win after all, much to my chagrin.


This is a great idea.
I’ve been using Comaps on Android, while looking for a desktop alternative to osm.org.
Let us know if you publish this!
Here’s what I’m thinking:
Driving-focused routing; easy. BRouter already supports separate car, bicycle and foot routing modes/profiles, and its server accepts a profile= per request. So that one is universal.
Live turn-by-turn navigation and rerouting - should be easy. GPS position, route geometry, turn hints, destination coordinates and a local routing API are all sorted. The browser would track position against the active route, advance through manoeuvres as you approach them, detect when you move sufficiently off-route, then call BRouter again from current GPS position to the existing destination.
The main work is a navigation state machine…which…I might need to ask GPT or Claude for help tbh.
For guaranteed offline speech you would want an on-device voice installed on the phone, but almost every phone has that (unless you cut TTS out).
I’d be stupid not to use that (though I need to figure out the slice and dice). Obviously, that won’t translate to every place on Earth, but I am coding this for me, so … :)
What I can’t solve is the Traffic. Not really. I mean…sort of. Where I am, Main Roads WA exposes public ArcGIS services with incidents, roadworks, events, road closures, detours and traffic-signal outages, all queryable as JSON, all updated live. In theory, that means a live traffic layer with with road closures, traffic incidents, speed zones etc.
No live traffic congestion / data tho.
Let me sit on it for a bit. I never thought to release this…and these 4 are nagging me…but I really want to move onto the SmartTube project fully. Maybe I’ll just patch the first two or three low hanging fruit. The big issue is field testing it for weeks/months before I can call it properly done.
Honestly, I just wanted my own Google maps. I never thought to apply spit and polish for general release.