CoMaps: o app de mapas offline que guiou resgates sem sinal na Venezuela
Construído sobre dados do OpenStreetMap e 100% offline, o CoMaps virou ferramenta de campo na resposta ao terremoto na Venezuela. O caso mostra o que a arquitetura offline-first resolve em cenário crítico.

No segundo dia após o terremoto na Venezuela, Anton Wenemoser desceu até o que todos chamavam de "marco zero", a área mais atingida, uma zona sem cobertura de celular. Ele não precisou improvisar: já tinha o app instalado. "CoMaps turned out to be really useful for me because I entered a zone with no coverage and needed it right away", contou ele à Humanitarian OpenStreetMap Team (HOT), que reconstruiu o caso em conversa com os cofundadores do projeto.
O relato virou pauta porque expõe, num cenário real de crise humanitária, o que uma arquitetura offline-first efetivamente entrega quando a infraestrutura de rede simplesmente não existe, e o que ainda está em aberto para quem constrói software com esse tipo de requisito.
O que é o CoMaps e como ele funciona offline
O CoMaps é um app de navegação construído sobre dados do OpenStreetMap, a base cartográfica editada de forma colaborativa que Anton compara ao funcionamento da Wikipédia. É não comercial, totalmente open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → e projetado para operar 100% offline: uma vez baixado o mapa de uma região, o app continua funcionando sem internet e sem cobertura de celular, apoiado apenas no GPS do próprio aparelho. Por design, isso o torna adequado para emergências, quando a rede é justamente o primeiro recurso a cair.
A linhagem técnica ajuda a entender o produto. Como aponta o contribuidor de longa data pietervdvn no thread do Hacker News: "CoMaps is a fork of Organic Maps, which forked long time ago from Maps.me". Ou seja, é o ramo mais recente de uma árvore de apps FOSS de mapas baseados em OSM, ao lado de alternativas como o OsmAnd.
O gargalo que estava resolvido antes de ser preciso
Durante boa parte de seu primeiro ano, o CoMaps carregava uma limitação séria: atualizar os mapas levava dias. Processar os dados brutos do OpenStreetMap em mapas prontos para uso exigia um servidor potente, e cada atualização de mapa dependia de uma atualização do app, sujeita aos processos de revisão das lojas de aplicativos.
Isso mudou meses antes de alguém precisar. CoMaps e HOT já vinham conversando antes do terremoto: em abril, Anton e o cofundador Bastian Greshake Tzovaras apresentaram o projeto ao Geospatial Tech Working Group da HOT. Entre abril e o terremoto, o time desacoplou a atualização dos mapas da atualização do app e, com um servidor mais robusto, reduziu o tempo de processamento de 10 dias para cerca de 3. O resultado: dados de mapa novos liberados toda semana, para o planeta inteiro.
| Antes | Depois | |
|---|---|---|
| Atualização de mapa | Acoplada à atualização do app (revisão das lojas) | Desacoplada, entrega direta |
| Tempo de processamento | ~10 dias | ~3 dias |
| Frequência | Esporádica | Semanal, planeta inteiro |
| Update priorizado em emergência | Não previsto | ~35 horas até mapa novo em campo |
O ponto que interessa a quem projeta sistemas é o motivo da mudança. Segundo Bastian, ela não foi feita sob encomenda para a 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." A decisão de arquitetura, remover o próprio time como gargalo (gatekeeper) na distribuição dos dados, foi o que criou a capacidade de resposta rápida antes de existir a demanda.
Da decisão de design ao campo
Quando Emilio Mariscal, da HOT, procurou o time perguntando se conseguiam mapas atualizados da Venezuela, o CoMaps já estava gerando um. Na primeira fase da resposta, voluntários mapearam e atualizaram dados no Tasking Manager da HOT, e esses dados chegaram ao CoMaps. Os milhares de prédios mapeados por voluntários apareceram nas telas de quem estava respondendo ao desastre no chão.
Em campo, Anton se juntou a uma equipe de resgate vinda de El Salvador, bombeiros, Proteção Civil e várias unidades, operando remotamente sob instruções de um centro de comando no país de origem. A maior parte da equipe não conhecia o CoMaps. Quando o centro pedia para mover o time de um ponto a outro, Anton era quem conseguia localizar o destino, se ele estivesse mapeado. O coordenador de mapas da equipe usava um app de navegação bem mais limitado, sem o detalhe que vem de uma comunidade mapeando o território nem a capacidade de operar totalmente offline em zona sem sinal.
A leitura de Bastian sobre por que isso importa é uma analogia direta: "the best camera is the one you actually have with you, because if the camera just sits at home, you never take any pictures." O melhor app de mapa em campo é o que já está no bolso e que a pessoa já sabe usar, não o que exige treinamento no exato momento em que não sobra tempo para aprender.
O que isso diz para quem constrói software no Brasil
O Brasil tem geografia farta de zonas onde a conectividade é intermitente ou inexistente: interior amazônico, áreas rurais, regiões de encosta em cidades como as afetadas por enchentes e deslizamentos, onde equipes de Defesa Civil e voluntários operam justamente quando a rede caiu. O caso da Venezuela é um argumento concreto a favor de projetar aplicações de campo com offline-first como requisito, não como recurso opcional adicionado depois.
Há dois aprendizados de engenharia que sobrevivem fora do domínio de mapas. O primeiro é o desacoplamento entre dado e aplicação: separar o ciclo de atualização de conteúdo do ciclo de release do app (que passa pela revisão das lojas) foi o que transformou dias em horas na hora de entregar informação fresca. O segundo é remover o time como gatekeeper da distribuição, um princípio que vale para qualquer pipeline de dados em que a latência humana vira o gargalo em uma emergência.
Vale também o alerta de que a qualidade depende da comunidade que mantém o dado. A base é o OpenStreetMap, editável por qualquer um, e no Brasil isso significa que a utilidade em campo cresce na proporção do quanto o território local está mapeado. Como resume pietervdvn no mesmo thread: "If you see errors/missing stuff on OpenStreetMap, fix them." Ferramentas como o StreetComplete e o MapComplete baixam a barreira de contribuição para quem quer melhorar o mapa da própria região.
O que ainda está em aberto
O time do CoMaps trabalha de forma voluntária. Hoje, quando uma emergência acontece, consegue priorizar uma atualização e ter mapas novos prontos para baixar em campo em cerca de 35 horas. A visão declarada vai além: atualizações específicas por região a cada 12 horas, em vez de uma atualização semanal para o planeta inteiro, para que comunidades atingidas por um desastre confiem em mapas que refletem o que acabou de ser mapeado, e não o que foi mapeado uma semana antes. Até lá, a janela entre o mapeamento voluntário e o dado chegando à tela de quem responde no chão continua sendo o ponto crítico a encurtar.
Fontes: Hacker News · Reações no Hacker News
Este artigo foi escrito por Redação iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters e validação técnica de Tiago Baeta. Saiba como produzimos no expediente.








Comentários
Ninguém comentou ainda. Começa a conversa?