For years, I've used Google maps for my personal navigation needs. More recently, I have been hiking more and planning some complex road trips. It has become apparent that Google maps is bad at anything other than navigating to a specific address. Here are some specific problems:
- Level of detail is crude in comparison to Open Street Map (See picture.)
- No way to configure the visible layers
- Contributes to unreliability. For example, you can't be sure that all the stores in a strip mall are being displayed at the current zoom level, or that every park is outlined.
- Cloud based. Limited capacity for offline navigation
- It's useless when you're in a place like West Virginia where the cellular coverage is spotty (i.e., when you really need it)
- No way to save waypoints
- One time, I stopped at a cool rest stop on a road trip and I wanted to jot down the coordinates. I tried to find a button for "Place waypoint here and save to 'My waypoints.'" Google maps couldn't do that, and I wouldn't trust Google to keep track of that information in the long term even if it did.
- Poor support for detailed planning of routes. Google Maps is god awful when you want to take any route other than the default route to your destination.
The appeal of Google Maps is that it is extremely easy to use and it handles many simple use cases well. Fundamentally, my issue is that Google Maps is not advanced enough for my needs. This is not surprising because Google Maps is really an ad platform, not a GIS. In this blog post, I will provide an outline of how to set up an alternative tool chain for your personal geography needs that overcomes these issues.
Figure 1: Google Maps (top) vs. OSM (bottom)
1. Open Street Map (OSM)
Before you can do any kind of geography work without the cloud, you need to have some maps to work with. These can be obtained from sources such as Geofabrik:
https://download.geofabrik.de/north-america.html
My advice at this stage is to be patient and download a larger region than you need. Everything that I will discuss in this blog post will go more smoothly if you have a single .osm.pbf file to work with. It's not worth it to do things like combining .osm.pbf files or otherwise manipulating them to save space.
2. QGIS
QGIS is a complicated program that is geared more towards professional users. It doesn't aim to compete with Google Maps. That said, as a complete geography amateur I still find QGIS useful sometimes. QGIS is what I use when I want to simply view the street map or the topographical map of an area. It is not that hard to learn basic functionality like how to mark things on the map and save them.
3. OSMAnd
OSMAnd is an open source mobile app for navigation and general map viewing.
3.1. Offline maps
Unlike Google Maps, OSMAnd has well-engineered support for offline navigation. This is achieved through the use of a format different from .osm.pbf that is optimized for offline use on mobile platforms. Consequently, you will have to download whatever region you want from the OSMAnd servers, and there is no way to import from an .osm.pbf file that you already have. This isn't a big deal because the OSMAnd CDN is powerful and the download probably won't take longer than 1 day. This infrastructure is a compelling reason why it's worth paying for OSMAnd rather than using the free tier.
3.2. Navigation
Another major feature of OSMAnd is the "turn-by-turn directions" screen intended for use while actively driving or walking. This part of the app is what I will refer to as navigation. It's important to understand that "navigation" is not the same as "route computation" AKA "routing," which is the act of computing the route from a set of waypoints. Navigation is the part that takes a GPX file containing a pre-computed route, and then gives you turn-by-turn directions as you travel along that route.
GPX, by the way, is a widely used file format for storing routes. You can obtain GPX files from a number of sources as well as generate them inside of OSMAnd, although I've found that the in-app route generation capability of OSMAnd has some major limitations. For one, the "snap to roads" feature tends to freeze and crash the app. It's possible to work around this issue if you know how to break your route into smaller chunks so that the algorithm doesn't hang, but this is somewhat painful.
There is a good reason why "Snap to roads" doesn't always work. It's because it is attempting to do a computation that mobile phones cannot comfortably handle. I've found that a more robust method is to create routes using an external tool such as Graphhopper, export to GPX, and then import the resulting GPX into OSMAnd.
4. Routing with Graphhopper
The way that apps like Google maps compute a route to a destination is by solving the Traveling Salesman Problem. This computation is often performed in the cloud because the graph in question is usually several gigabytes large, and mobile devices do not have the storage nor computational power required. Graphhopper is an open source tool for computing routes in this way. It is capable of exporting GPX files, or alternatively OSMAnd can be configured to directly use the free Graphhopper instance provided by GraphHopper GmbH over the internet. Of course, this only works if you have an internet connection.
4.1. Offline routing
I suspect that the free Graphhopper instance provided by Graphhopper GmbH is so convenient that there is not much interest in offline routing. But I was curious just how computationally intensive these routing computations actually are and if it was feasible to perform them offline. What I found is that offline routing is not computationally expensive enough to require supercomputers or special hardware. Given the compiled graph, my laptop can easily handle all of my personal routing. However, getting the compiled graph is another story.
To compile the road graph for the entire USA from a .osm.pbf, I had to rent a powerful server from Digital Ocean with 64GB of RAM. This cost only 1$ an hour and it took less than one day so it wasn't expensive, but it's certainly not a computation that can be performed on a regular computer. Here is a rough outline of the commands needed to build the road graph needed for offline routing. It assumes you have a suitable version of Java, Maven, etc., and a lot of RAM (how much RAM depends on the size of the .osm.pbf file.)
git clone https://github.com/graphhopper/graphhopper.git # Build graphhopper with Maven cd ./graphhopper mvn package # build the road graph and then launch Graphhopper INPUT_OSM_PBF="../us-latest.osm.pbf" java -D"dw.graphhopper.datareader.file=$INPUT_OSM_PBF" -jar ./web/target/graphhopper-web-8.0-SNAPSHOT.jar server ./config-example.yml
The compiled road graph is stored in graphhopper/graph-cache. If you run this on a rented machine like I did, these are the files that you'll need to download for offline routing.