CoMaps: How FOSS Offline Maps Work (Privacy-Friendly Navigation Under Your Control)

Imagine you’re halfway up a trail, the cell signal drops to nothing, and your “helpful” navigation app turns into a spinner. That moment is the reason offline maps are so compelling: you want navigation that keeps working when the network doesn’t.

CoMaps is a free and open-source offline navigation app built around OpenStreetMap data. It’s also designed with privacy goals—no user registration, no ads, and an emphasis on avoiding background tracking—backed by a review from Exodus Privacy. (wiki.openstreetmap.org)

But the part that makes CoMaps interesting for a technical reader isn’t only the “no internet” promise. It’s how an offline map system is put together so that search, routing, and map rendering can run locally on your phone.

The offline mapping problem: “How do we navigate with zero network?”

Offline maps sound simple: download a map and keep going. Under the hood, it’s more like building three separate capabilities that normally depend on connectivity:

1. A map display system (turning geographic data into what you see on screen).
2. An offline search system (finding places by name or category without querying a server).
3. An offline routing system (computing directions using road/path graphs locally).

What happens when you lose mobile data in the middle of a hike? In a well-designed offline app, nothing “breaks”—your phone already has the data and indexes needed to keep working. CoMaps explicitly targets that model: most features are intended to operate without a data connection. (wiki.openstreetmap.org)

CoMaps in context: a community fork with a technical mission

CoMaps is a community fork of Organic Maps, which itself traces back to Maps.me. Forks can sound political, but this one also carries a technical emphasis: transparency, performance, and privacy choices that affect the whole architecture—from map delivery to location handling. (github.com)

To understand why that matters, focus on the word offline. Offline isn’t only a UI label; it changes where data lives (on device), how features are implemented (local computation), and how updates are delivered (map downloads and differential updates).

Local map data: why .mwm and updates matter

Offline routing and search don’t work with “raw” OpenStreetMap XML alone. They need compact, queryable, device-friendly formats.

CoMaps stores its map data using the .mwm extension for main map files, and uses .mwmdiff for differential (incremental) updates. (deepwiki.com)

A helpful mental model: .mwm is the “bulk map brain” for a region, while .mwmdiff is the “patch” that brings that brain up to date without downloading everything again.

CoMaps also includes chunk management for large .mwm downloads, which matters for reliability. If a download is interrupted, the app can resume without restarting from scratch—by tracking which chunks were already retrieved. (deepwiki.com)

Here’s the idea in simplified pseudo-code:

required_chunks = plan_for_region(region)
for chunk in required_chunks:
  if not file_exists(chunk):
    download(chunk)
mark_region_ready(region)

That design is directly tied to offline usability: your “download once, navigate anywhere” experience only feels smooth when partial downloads and resumability are handled carefully.

Turning data into maps: MapCSS and the Drape renderer

Now let’s talk about the screen.

A map isn’t just a pile of lines; it’s a styled visualization: roads in different colors, labels at certain zoom levels, icons for amenities, contour lines for hiking, and so on.

CoMaps uses a styling approach based on MapCSS. MapCSS is a stylesheet language for maps (analogous to CSS for websites): it describes “how a feature should look” at different zoom levels. (deepwiki.com)

The system compiles these rules into binary drawing specifications for runtime performance, and then renders using the Drape rendering engine. Drape is a cross-platform C++ renderer that supports multiple graphics APIs such as OpenGL ES and Vulkan. (deepwiki.com)

This is why offline map rendering can be fast. The heavy work—style compilation and rule preparation—happens earlier (as part of map generation), while the phone mainly performs “draw these already-prepared instructions” work.

Offline search: local indexing beats “type and wait”

Offline search usually fails for one of two reasons:
- it’s too slow (no index), or
- it’s too brittle (exact matches only).

CoMaps tackles this with an offline index-based search pipeline. During map generation, it builds search structures so that queries can be matched against place names and categories quickly from loaded regions (again, using .mwm-style map contexts). (deepwiki.com)

Even better, the search process includes query normalization and resilience features—like lowercase handling, diacritic normalization, tokenization, and fuzzy matching behavior—so that “almost right” searches still find relevant results. (deepwiki.com)

That’s the practical meaning of offline search: you’re not dependent on a remote geocoder, and your “search while disconnected” moment becomes realistic instead of theoretical.

Offline routing: pathfinding across regions, plus turn logic

Routing is the hardest part to do offline because it involves algorithmic computation on a graph: intersections and segments become nodes and edges, and the app chooses a path based on a cost model.

In CoMaps’ architecture, the Routing Engine uses pre-built routing indexes stored inside map files, and it can handle routes spanning multiple map regions by connecting cross-border data through a “world” routing graph concept. (deepwiki.com)

For turn-by-turn guidance, CoMaps includes logic for turn notification—deciding when to announce the next maneuver based on current position, speed, and distance. (deepwiki.com)

This part matters for performance and battery life, because routing engines often get tempted into constant recalculation. A well-structured offline engine limits work and uses persisted navigation state so navigation can resume smoothly after interruptions. (deepwiki.com)

Privacy isn’t a slogan: it changes the architecture

The privacy story becomes concrete when you look at location services and map delivery.

CoMaps describes changes that remove dependencies that could raise tracking concerns. One example: instead of using Google’s Fused Location Service by default, CoMaps decided to use microG (an open-source implementation) and disable Google Fused Location Service by default in app settings to avoid potentially collecting location without consent. (comaps.app)

CoMaps also rewrote parts of map delivery. It describes a “meta-server” used to choose content delivery resources, and then implements its own meta-server while reducing logs and removing upstream functions that could enable remote feature toggles or donation-related behaviors. (comaps.app)

Most importantly for technically curious users: CoMaps supports working without the meta-server by letting the Android app point at a custom server address, and it mentions self-hosting the map files as a privacy-forward option. (comaps.app)

That combination—local computation plus deliberate control over what’s sent where—helps explain why offline apps can feel more private than “just download a region” competitors.

Community as infrastructure: OpenStreetMap + contributions

CoMaps isn’t only a product; it’s tied to community mapping.

OpenStreetMap (OSM) is a collaborative map database where contributors add and refine features. CoMaps leverages that ecosystem so that the map data you use offline can improve over time through community edits and feedback. (github.com)

On the software side, CoMaps maintains open source code for both the offline engine and contributions workflow. That matters because offline map quality isn’t just “more tiles”—it’s faster search, better routing behavior, better rendering styles, and fewer crashes.

How it all comes together in practice

CoMaps’ technical design makes offline navigation feel coherent because the same underlying idea repeats everywhere: precompute what can be precomputed, package it into offline-ready formats, and keep feature logic local.

Map data becomes .mwm regions that power search and routing; styling rules compile into binary rendering instructions for fast on-device draw calls; the routing engine uses offline indexes to compute directions; and the privacy architecture avoids treating a network connection as a prerequisite for “basic navigation.” (deepwiki.com)

The result is that offline navigation stops being a fallback and becomes a primary experience—one that works when cell service fades and when privacy expectations are higher than marketing copy.

Conclusion

CoMaps shows what “offline maps” really means: a full local stack for rendering, search, and routing built on OpenStreetMap data and packaged into device-ready formats. Under the hood, MapCSS and the Drape renderer handle visual output, indexing enables offline search, and the routing engine performs graph-based navigation across regions. Privacy goals then shape the architecture—especially around location services and map delivery—so the app remains usable without constant network contact. (deepwiki.com)