CoMaps: the offline mapping app that guided rescuers without a signal in Venezuela

On the second day after the earthquake in Venezuela, Anton Wenemoser went down to what everyone was calling "ground zero," the hardest-hit area, a zone with no cell coverage. He didn't need to improvise: he already had the app installed. "CoMaps turned out to be really useful for me because I entered a zone with no coverage and needed it right away," he told the Humanitarian OpenStreetMap Team (HOT), which reconstructed the case in conversation with the project's co-founders.

The account became a story because it shows, in a real humanitarian crisis scenario, what an offline-first architecture actually delivers when network infrastructure simply doesn't exist, and what remains open for those building software with this kind of requirement.

What CoMaps is and how it works offline

CoMaps is a navigation app built on OpenStreetMap data, the collaboratively edited mapping database that Anton compares to how Wikipedia works. It is non-commercial, fully open source, and designed to operate 100% offline: once a region's map is downloaded, the app keeps working without internet and without cell coverage, relying only on the device's own GPS. By design, this makes it suitable for emergencies, precisely when the network is the first resource to go down.

The technical lineage helps explain the product. As long-time contributor pietervdvn points out in the Hacker News thread: "CoMaps is a fork of Organic Maps, which forked long time ago from Maps.me". In other words, it's the most recent branch of a tree of FOSS mapping apps based on OSM, alongside alternatives like OsmAnd.

The bottleneck that was solved before it was needed

For much of its first year, CoMaps carried a serious limitation: updating maps took days. Processing raw OpenStreetMap data into ready-to-use maps required a powerful server, and every map update depended on an app update, subject to app store review processes.

That changed months before anyone needed it. CoMaps and HOT had already been talking before the earthquake: in April, Anton and co-founder Bastian Greshake Tzovaras presented the project to HOT's Geospatial Tech Working Group. Between April and the earthquake, the team decoupled map updates from app updates and, with a more powerful server, cut processing time from 10 days to about 3. The result: new map data released every week, for the entire planet.

| | Before | After | |---|---|---| | Map update | Coupled to app update (store review) | Decoupled, direct delivery | | Processing time | ~10 days | ~3 days | | Frequency | Sporadic | Weekly, entire planet | | Prioritized update in emergency | Not planned | ~35 hours until new map in the field |

The point that matters to those designing systems is the reason for the change. According to Bastian, it wasn't made to order for HOT: "Many of the things we've already done that turned out useful to HOT are not things we sat down and thought would be useful to HOT (...) We wanted people not to rely on us as the gatekeepers of the maps. And it turns out that's also really useful for deploying maps in the field." The architectural decision, removing the team itself as a bottleneck (gatekeeper) in data distribution, was what created the capacity for rapid response before the demand existed.

From design decision to the field

When Emilio Mariscal, from HOT, reached out to the team asking whether they could get updated maps of Venezuela, CoMaps was already generating one. In the first phase of the response, volunteers mapped and updated data in HOT's Tasking Manager, and that data reached CoMaps. The thousands of buildings mapped by volunteers appeared on the screens of those responding to the disaster on the ground.

In the field, Anton joined a rescue team from El Salvador, firefighters, Civil Protection, and several units, operating remotely under instructions from a command center in their home country. Most of the team didn't know CoMaps. When the center asked to move the team from one point to another, Anton was the one able to locate the destination, if it was mapped. The team's map coordinator used a much more limited navigation app, without the detail that comes from a community mapping the territory or the ability to operate fully offline in a zone without signal.

Bastian's take on why this matters is a direct analogy: "the best camera is the one you actually have with you, because if the camera just sits at home, you never take any pictures." The best mapping app in the field is the one already in your pocket that you already know how to use, not the one that requires training at the exact moment there's no time left to learn.

What this means for those building software in Brazil

Brazil has geography rich in zones where connectivity is intermittent or nonexistent: the Amazon interior, rural areas, hillside regions in cities like those affected by floods and landslides, where Civil Defense teams and volunteers operate precisely when the network goes down. The Venezuela case is a concrete argument in favor of designing field applications with offline-first as a requirement, not as an optional feature added later.

There are two engineering lessons that survive outside the mapping domain. The first is the decoupling between data and application: separating the content update cycle from the app's release cycle (which goes through store review) is what turned days into hours when it came to delivering fresh information. The second is removing the team as a gatekeeper of distribution, a principle that applies to any data pipeline where human latency becomes the bottleneck in an emergency.

There's also a warning worth noting: quality depends on the community maintaining the data. The base is OpenStreetMap, editable by anyone, and in Brazil this means field usefulness grows in proportion to how much local territory has been mapped. As pietervdvn sums it up in the same thread: "If you see errors/missing stuff on OpenStreetMap, fix them." Tools like StreetComplete and MapComplete lower the barrier to contribution for those who want to improve the map of their own region.

What remains open

The CoMaps team works on a volunteer basis. Today, when an emergency happens, it can prioritize an update and have new maps ready to download in the field in about 35 hours. The stated vision goes further: region-specific updates every 12 hours, instead of one weekly update for the entire planet, so that communities hit by a disaster can trust maps that reflect what was just mapped, not what was mapped a week earlier. Until then, the window between volunteer mapping and the data reaching the screen of those responding on the ground remains the critical point to shorten.