Offline Maps: A Shared Problem in Need of a Shared Solution

Julian Simioni
Jul 13, 2016 · 7 min read

What’s the first app you ever used on a smartphone? What’s the one system app you still haven’t hidden deep in a folder? What was the first Javascript heavy web application you ever used? There’s a good chance your answer to at least one of these questions is: a map! Since the dawn of time, humans have created maps to record knowledge of the layout of the world.

One of the most important features of a map is portability: you can take a map with you, and it will help you find your way. In the age of discovery, expeditions to chart the world were heavily funded and the resulting maps treated as national secrets. Until recently, every commercial airplane carried around 35 pounds of paper maps. When airlines switched to tablets, they saved millions of dollars in fuel. So it’s clear that maps are both incredibly useful, and made even more powerful by advances in technology.

Today half the people on earth have a computer in our pocket or on our lap that we use for maps. Making better maps is inherently a cooperative process, and we use the Internet to build and distribute maps that get better every day.

At Offline Camp, maps were at least mentioned as a use case in many of the sessions, and two sessions were dedicated to offline maps: one on the topic in general, and one on the details of how we can build tools for searching maps without an Internet connection.

Everyone is Using Online Maps

One of the first sessions of the first full day of Offline Camp covered the general topic of offline maps. We quickly found, unsurprisingly, that almost every project eventually contains a map as it grows. We also found that the tools and services everyone uses for maps have some support for offline usage, but not enough!

Online Maps are Hard

It only took us a few minutes of discussion to enumerate a huge list of reasons why maps are hard.

They require lots of data: on the order of hundreds of gigabytes for any reasonably detailed world dataset.

The world itself is out to make maps difficult: there are more edge cases than anyone can imagine. Usually when someone searches for “Statue of Liberty”, they mean the one in New York, but did you know there are hundreds of Statues of Liberty all over the globe? Sometimes they actually wanted the one in Des Moines, Iowa.

Maps require global cooperation: from dealing with encrypted coordinates from China to finding data on the most remote places on Earth, building good maps requires people physically located all over the world.

Offline Maps are Even Harder

Most map applications that we use in our web browsers connect to fleets of computers to do expensive calculations and contain data about the entire world. Even the most powerful smartphones today have a fraction of the computing power and storage needed to perform the same tasks. This means offline maps will necessarily require tradeoffs.

The most obvious tradeoff is to load only parts of the world. With current consumer offline maps, you have to remember to save map data for the part of the world you care about beforehand. This is annoying and error prone at best; during a natural disaster or other situation where lack of connectivity is unexpected, it can be a big problem.

An entire session at Offline Camp was dedicated to the problems of managing data stored offline. Features to predict what data users will probably need and remove data they probably won’t can be convenient, or can leave users without control and without the data they expect. While browsers are getting better and better at storing data for offline use, they still are often unpredictable when it comes to removing data to free up space.

Another problem is that geocoding, the process of searching for places like addresses on a map, is often missing completely in offline mode. Even Google Maps, which has an enormous team and budget behind it, can only display maps when offline. If the user wants to do anything other than navigate to an already known point, they are out of luck.

Geocoding is hard enough with a dataset of the whole world. There is no foolproof methodology to solve the problem, so all geocoders essentially search their data and hope to find a result that looks good. Deciding what a good result looks like can be quite sophisticated, but there’s always some margin for error.

When some data is known to be missing because the user is offline, it’s much more difficult to decide what to do. If a user searches for a place, but nothing is found, is it because that place doesn’t exist, or because it’s in the next town over where no data is available? Should a place that is in the available data, but doesn’t match as closely, be returned instead? Whatever is done, how is it messaged to the user?

People are Coming Together to Build Better Tools for Maps, Offline and Online

There’s no sugar coating it: there are a lot of challenges ahead for offline maps, but there’s an unprecedented level of cooperation happening to make things better.

Many offline problems require every app to handle its unique case: only Twitter can do the work to let you view your tweets offline, and Google adding better offline support to Gmail won’t help Yahoo Mail users. With offline maps, we are much more fortunate.

For years now, there have been communities of people working together to build better, shared, tools and data for maps. The most well known of these is OpenStreetMap, basically Wikipedia for maps.

Around and beside it are tools for creating and displaying map data across all the formats and devices one could ever need.

There are just as many projects to collect new map data, either from governments that already have it, for humanitarian response, or to generate a visual record of anywhere a human with a cellphone can go. There are so many data efforts that there are projects just to sort through them all in a meaningful way.

While not everybody is on board, more and more are joining in. Last year, for example, the United States National Park Service announced that they would add their own data to OpenStreetMap. There’s no sense, they said, in anyone else duplicating the work they already did to map out the parks.

What this means is that as offline support starts to trickle in to these open source projects, it will quickly be available in lots of applications, and with data all over the globe.

How You Can Join

All community projects need a little of everyone: organizers, designers, builders. But map projects require someone from everywhere as well. We can map the outlines of roads and buildings from satellite photos, but everything after that requires people on the ground. How else will we know what those roads are called, and what those buildings contain?

Many projects that need contributions of all kinds are linked above, but it’s worth highlighting a few open-source projects that are particularly important for offline maps:

  • Leaflet.js: the near-ubiquitous library to render and display maps in the browser. It has support for almost every format and feature a map needs. There are several projects working on offline support (including one by Offline Camp attendee Calvin Metcalf!)
  • PouchDB, localForage, and Apache Cordova are all useful tools for building offline apps. They will all probably be pushed to their limit in support of offline maps, so any improvements are helpful.
  • Both Mapbox and Mapzen (disclaimer: the writer is an employee) have browser-based 3D map rendering engines using WebGL, but neither have explicit offline support.
  • The OpenStreetMap community has a list of native mobile apps that work with open data, many of which are also open source.
  • Finally, of course, the Offline First community hosts meetups, larger events, and online discussion for all aspects of offline apps, including maps.

Everyone has knowledge of somewhere in the world, so everyone has something valuable to contribute. Gathering this knowledge doesn’t just build databases, it builds connections between people. And with offline support in our maps, we can keep people connected, even when our devices aren’t.

Julian Simioni is a software developer working on the Pelias open source geocoder at Mapzen.

He’d like to thank Teri Chadbourne and Katie Kowalsky for reviewing this article, Jory Burson and Justin Falcone for taking wonderful notes during the sessions, and Calvin Metcalf for ridiculous amounts of technical knowledge shared during Offline Camp and elsewhere. 🌍

Editor’s Note: This article highlights one of many unconference sessions at Offline Camp, where a small group of campers with diverse interests come together to discuss Offline First. We hope to see you at an upcoming event!

If you enjoyed this article, please ♡ it to recommend it to other Medium readers.

Offline Camp

Building the Offline First community, one campfire at a time.

Julian Simioni

Written by

Pilot, retired competitive cyclist, writer of codes

Offline Camp

Building the Offline First community, one campfire at a time.