A map that disappears with the network is not useful in a rangeland where connectivity is intermittent by design.
That was the constraint behind a mapping architecture we built for an Android app used by pastoralists and veterinarians in Northern Kenya and Namibia. The map needed to support navigation in places where a connection might be available now and gone a few minutes later. At the same time, it needed to remain familiar enough that a herder could relate what was on the screen to what they could see around them.
Satellite imagery was the natural fit for the connected experience. It preserves visual details that people can recognize from the ground, so the app shows it by default when connectivity is available. But shipping the same imagery for offline use introduced a different problem: raster tiles consume a great deal of storage.
We chose a hybrid model instead. Satellite imagery provides the richer online view. When connectivity is lost, the app falls back to a compact vector map stored on the device. The visual detail changes, but the ability to orient and navigate remains.
That distinction became the principle behind the design:
Losing the network should reduce fidelity, not capability.
Online · Default
Satellite imagery
Familiar landmarks and richer visual context
Offline · Fallback
Local vector map
Compact coverage that works without signal
When connected, satellite imagery provides familiar landmarks and richer visual context. When connectivity is lost, the map switches to local vector map, which provides compact coverage that works without signal. Navigation continues.
Start with the user task, not the map source
It is easy to frame offline mapping as a question of tile formats and SDKs. Those choices matter, but they come after a more useful question: what must the user still be able to do when the network disappears?
In this case, the task was not to reproduce the complete satellite experience offline. It was to preserve enough geographic context for someone to orient themselves and continue navigating the rangeland.
That distinction gave us room to use two representations of the same environment:
- Online satellite imagery for recognizable visual context when a connection is available.
- Offline vector maps for dependable orientation and navigation when it is not.
The two modes do not need to be visually equivalent. They need to preserve the same essential outcome.
This is a useful boundary in offline-first systems. Not every connected feature needs a perfect offline copy. Sometimes the right offline behavior is a smaller, intentionally reduced representation that protects the core task.
Why satellite imagery stayed online
Satellite maps are raster data: the map is delivered as pre-rendered images for different locations and zoom levels. Those images provide useful detail, but retaining enough of them for offline navigation can quickly consume a large amount of device storage.
For one community-mapped area in this project, the satellite coverage we evaluated was roughly 150 MB. Comparable vector coverage was about 7 MB.
That is one measured project example, not a general raster-to-vector conversion ratio. The result depends on the selected area, zoom levels, source data, encoding, and the amount of detail retained. The useful lesson was not the exact ratio. It was that the difference was large enough to change the architecture.
Keeping satellite imagery online avoided carrying a large raster package on every device. When connected, the map service can deliver the imagery needed for the current viewport and zoom level. When disconnected, the app does not wait for those requests to fail before becoming useful; it has a local vector map ready to take over.
This gave us a clear trade-off:
- Satellite imagery offered the best visual recognition, at the cost of a network dependency.
- Vector data offered a smaller and more dependable offline footprint, at the cost of photographic detail.
The architecture accepts both sides of that trade rather than forcing one map format to satisfy every condition.
Offline coverage should reflect where the work happens
Format was only part of the storage decision. Geographic scope mattered too.
Generic regional downloads often cover large areas simply because they fall inside an administrative boundary or a rectangular tile selection. That is convenient for a mapping platform, but it can be wasteful for a field app. Users should not have to store map data for places where they will never graze their livestock.
Our offline package focused on community-defined rangelands and navigation areas that were not adequately represented in global map data. This made the offline map more relevant to the people using it and avoided treating global coverage as the default measure of completeness.
The product boundary was therefore deliberate: carry the places that matter to the user, rather than every place the mapping system can describe.
The architecture in practice
At a high level, the map has three responsibilities.
First, it observes whether the connected experience is currently viable. When it is, satellite imagery is the default because it gives herders the most familiar view of the landscape.
Second, it keeps the offline vector map available on the device. A loss of connectivity changes the basemap rather than removing the map altogether.
Third, it preserves the navigation experience across that transition. The user may notice a reduction in visual richness, but they do not arrive at a blank canvas at the moment the network becomes unreliable.
We used MapLibre as the map renderer. It gave us the flexibility to render both connected and local map sources without making the application depend on a single hosted basemap.
The offline vector data was packaged using PMTiles, a single-file archive format for tiled map data. A compact archive is well suited to this kind of deployment: it is easier to distribute and manage than a directory containing many individual tile files, while still allowing the renderer to access the portion of the map it needs.
Large map assets still have to reach the device reliably. We used Play Asset Delivery as part of that distribution strategy. The important architectural point is not its exact configuration. It is that offline capability includes the asset lifecycle: packaging, delivery, validation, local availability, and updates all need to be considered alongside rendering.
Rendering a local map in development proves only one part of the system. The feature is not complete until the required map reaches a real device and is ready before the user needs it.
What we chose not to hide
The vector fallback is not a free version of satellite imagery. It carries real trade-offs.
It has less visual detail. It needs a considered style so that roads, boundaries, labels, and other navigation cues remain legible. Its geographic scope has to be selected deliberately. Because the data is packaged for offline use, changes also need an update and distribution path.
The connected experience has its own costs. Satellite imagery depends on bandwidth and can disappear at exactly the point where the user travels beyond coverage. That is acceptable only because the application has already defined what happens next.
The value of the hybrid design is not that it removes these constraints. It puts each constraint in the part of the system best able to carry it:
- The network carries imagery when it is available.
- Device storage carries a compact, essential map.
- Product scope determines which offline areas are worth carrying.
- The transition between them protects the user’s task.
A decision rule for offline maps
Choose offline vectors when continuity and device storage matter more than photographic detail. Keep satellite online when it materially improves orientation, but make sure losing the network reduces fidelity—not capability.
Before adopting the same pattern, evaluate the conditions around it:
- How long can users reasonably remain without connectivity?
- Which visual landmarks make satellite imagery valuable?
- What is the storage budget on the devices in the field?
- Which geographic areas are actually relevant to the user?
- How will offline assets be delivered, verified, and updated?
The answer will not always be a hybrid map. A smaller raster region may be reasonable for one product; downloadable vector regions may suit another. But the decision should begin with the operating environment and the user task, not with the default behavior of a map SDK.
For this project, online satellite imagery and local vector maps were not competing solutions. They were two levels of the same experience. One made the landscape more recognizable when the network allowed it. The other made sure the map remained useful when it did not.
This decision came from an offline-first Android app I led for the arid rangelands of Northern Kenya and Namibia. The wider system—including encrypted local storage, data synchronization, and battery-aware GPS—is covered in the InfoRange case study.