Everyone is familiar with Google Maps, but for various reasons (cost, quality, expressability), many mapping applications use map data from OpenStreetMap (“OSM”) instead. It's free to use and anyone can add/edit/update it pretty much in real time... it's like Wikipedia, but for maps.

I have particular interest in it because lots of cycling-stuff uses OpenStreetMap data...

• I use the maps on my phone when riding, via the Galileo Offline Maps app (name changed Feb 2019 to Guru Maps), and sometimes with the Maps.me app.

• I plan my cycling routes with OpenStreetMap data, via GraphHopper. The Strava route builder also uses OpenStreetMap data.

• I upload the routes my cycling computer (a Garmin Edge 820), which itself uses OpenStreetMap data for its maps, that I load from here.

• Then of course we have Strava, which uses OpenStreetMap data for most of their maps, such as seen above.

Like Wikipedia, the quality of the data varies widely depending on where you look. Here in Japan, large cities tend to have very good data, probably both because the original data the map was seeded with long ago (often from Yahoo! and Microsoft Bing maps) was good within cities, and also because more people are interested in cities and so maps for these areas tend to be viewed and updated by more people more often.

But even within cities the data can be spotty at times, and out in rural areas it can be pretty bad. But the beauty of it is that when we come across data that's obviously wrong, we can just fix it. Like with Wikipedia, everyone enjoys the fruits of everyone's updates.

Of course, now that I want to talk about bad data and show an example, I can't find any really bad areas that I haven't already fixed, but just poking around the countryside I came across this:

This is the view in the default OpenStreetMap map editor, with the mapped roads presented over some satellite imagery. It's clear from the imagery that some roads have not been mapped, some have not been mapped well, and some non-existent roads have been added (such as the one shown with a red border in the screenshot above).

You have to be a bit careful about blindly trusting the satellite images, since they can be old or misaligned, but if you trust them, you can just go ahead and start fixing the map to match the imagery. The editor is pretty easy to use once you get the hang of it.

Being a geek, I go a step further than trusting the satellite images. I use road data from the Japanese government, via its Geospatial Information Authority of Japan web site, to build something I can overlay within the OpenStreetMap editor to show me the surveyed location of roads:

The data from the Japanese government can also be suspect (old, misaligned, or for proposed roads that don't yet exist), but it's a good sign when this data matches the satellite photo perfectly. So, I start fixing things...

It takes only a moment to fix the little area seen in the screenshots above, but it's sort of addicting. You're fixing a road that connects to another road that's just as bad, so you start correcting it, and so on. Luckily, Japan is an island nation, so in theory there's a limit to how far it can take me. I tend to get caught in a “just one more fix” loop until I can force myself to stop and leave areas of the map untouched and incorrect. This is difficult for a data geek like me to do.

Here's another example showing poorly-mapped roads not far from the spot above:

Before   -   Middle   -   After

mouseover a button to see that image

The difference between “Middle” and “After” is not that the road mapping was moved, but that within the map editor, I switched to a different satellite-imagery layer. There are various layers, and the quality of each varies considerably as you move around. In this case, the first's images were offset to the southeast by about the width of a road, and the second's images weren't. (It could be that neither are correct, but in this case I could compare with the government survey data, and so knew the second one to be correct.)

In writing this post, I realized that I used the wrong set of images to roughly place the lake that pokes in from the right side of the frame... in the “After” view, the lake is in the wrong spot. I've since returned to fix it.

So, after saving a set of updates, it can take some time for the new data to percolate to all the places that use it...

Update Speed to Web-based Maps

Web sites that use OpenStreetMap data can see updates almost immediately... within a minute. Strava seems to have a slightly longer delay, likely due to intermediate caching in their backend, so updates might take five or ten minutes to appear there. Update: Strava stopped received updates in mid 2017, and from my inquiries, neither Strava nor Mapbox (via which Strava gets OpenStreetMap updates) seem concerned. )-:

Here is another before/after pair of screenshots from Strava, showing tiny part of this epic ride two weeks ago, descending into Osaka on an exceedingly-steep mountain road used by a lot of tourists on foot. It turned out that the OpenStreetMap coverage here was pretty sparse, and I thought to update it because folks on foot would likely appreciate accurate maps when deciding where to trudge up and down.

Before   -   After

mouseover a button to see that image

I updated quite a bit of the surrounding area, but scrolling a bit farther away and you can see sparse areas still in need of some mapping TLC.

Update Speed to Route Building

Other uses of OpenStreetMap data take longer to update. For example, GraphHopper, where I make cycling routes, refreshes their routing data only every few days. The maps update visually right away, but the routes they generate won't reflect updates for up to a few days.

I don't know the update schedule for Strava's route builder, but it doesn't seem to be very often. Changes I made two weeks ago are still not reflected in its routes.

Update Speed for Garmin GPS Units

Garmin apparently sells detailed maps for various areas of the world, but I have no experience with these. Rather, on my Garmin 820 cycling computer I use maps derived from OpenStreetMap data, packaged for English-language Garmin devices by a guy in Osaka. Because these devices can't display Japanese natively, his preparation process converts Japanese text to “English” (to romaji). It's quite convenient.

He makes a new version available about twice a month, each time bringing in the accumulated updates. The web page is all in Japanese, but downloading and installing is simple.

In about the middle of the web page is a grid with a purple background...

The top pair of items are the latest data, the one marked in green is a version that includes contour lines, the one marked in red does not. I use the latter, but a hiker probably wants the former.

Each download zip holds two “*.img” files (“gmapsupp.img” and “gmapsupp_search.img”). After unzipping, just copy the two “*.img” files into your Garmin unit's “Garmin” folder. That's all there is to installing these maps and their updates.

Update Speed for Offline-Map Apps

The two phone apps I mentioned earlier are very convenient because after an initial map download, they don't need an internet connection to work, so you can use them when you're deep in the mountains with no coverage. Both are available on both iOS and Android.

In the case of Guru Maps, the map for all of Japan currently takes about 470 megabytes of storage. With Maps.me, you can load maps by the prefecture level (e.g. state/province). Kyoto Prefecture currently takes 47 megabytes (though the app inexplicably includes “Kyoto Prefecture” under the “Shikoku” region, despite my having reported this bug to them a year ago).

Updates that you (and I and others) make to OpenStreetMap data won't get into these apps very quickly, though. They tend to refresh their maps only once every month or three.

Each app has its strengths. You can record your track with Guru Maps, while Maps.me lets you do turn-by-turn routing (and you can route while offline, too).

Hidden Map Features: One Way(ish) Streets

I've been making updates to OpenStreetMap data like this for a year, and have spent way, way too much time on it. I guess it's my way of trying to give back a bit for all the wonderful stuff I am freely allowed to use. However, there was one part of the updates that was particularly frustrating.

At first the problem may not be apparent...

To understand the problem, let's look at a typical “one way” street sign in Japan:

The devil is in the details.... the vast vast majority of “one way” signs in Japan are paired with another sign:

Bicycles are allowed to go either direction on such streets, which is, as I said, most one-way streets in Japan. It's quite convenient for cyclists.

I would guess that the little “Except Bicycles” sign is the most common street sign in Japan, since it's added to almost all of the “one way” and “do not enter” signs.

So why do we care about this when mapping? If left as is, automatic routing (such as via the Maps.me phone app or the GraphHopper and Strava web sites) won't utilize these hybrid one-way roads to their fullest extent when routing for bicycles, yielding results that are more inconvenient than they should be, but in the worst case completely disallowing routing through an area that should be allowed.

So, the OpenStreetMap editor does have a way to mark such streets as “not one way for bicycles”, but it's not convenient:

1. Select the street segment

2. In the left sidebar, scroll down to the “All tags” list. Each street will have its own mix of tags, but if it displays as a one-way street, it'll have a “oneway” tag with a value of “yes” (or in some cases, “-1” or “1” or “true”, which all mean the same as “yes” for our purposes).

   As illustrations, here are the tag lists from two random one-way streets:

3. Add a “oneway:bicycle” tag with a “no” value...

   1) Click the add-tag “+”
   

   2) Add field “oneway:bicycle”
   

   3) Make its value “no”
   

   4) Voilà, it's now a one-way road for all but bicycles
   

One has to be careful to make sure the updates are appropriate. Sometimes very large streets are encoded with separate “roads” for each direction of travel, and each such “road” is one way in its direction for bicycles as well. If these are given a “oneway:bicycle” tag, the value should be “yes”.

It's very nice that “one way for all but bicycles” is possible, but how it's done is really inconvenient, both because of all the steps one must go through to add the notation, and because there's no way to know whether a one-way road has been so notated without scanning all the tags for “oneway:bicycle”.

So, when you look at something like this...

... you don't know to what extent, if any, the one-way streets have been updated for bicycles. Even if you have the patience of a saint and check/update them all, will you remember the exact extent of your work after a week or a month, or will you have to spot check for “oneway:bicycle” to remind yourself that you've already done this area? But in either case, how do you know you got them all?

I was in the midst of this frustration yesterday when I tickled myself pink by coming up with a solution:

I made it so that streets I need to address stand out visually.

To do this, I downloaded the source code to the OpenStreetMap map editor and made a few changes so that non-highway streets that are noted “oneway”, but that have no “oneway:bicycle” notation of any kind, are displayed with exaggerated thickness.

If it's truly one way even for bicycles, I add “oneway:bicycle” with a value of “yes”. This doesn't have an effect on routing, but it denotes to anyone inspecting the tags that the bicycle aspect has been addressed.

But for the typical one-way street, I add “oneway:bicycle” with a value of “no”.

And to make it easier to apply a “oneway:bicycle” tag, I updated the UI so that it's a simple checkbox that cycles among “no tag”, “no”, and “yes”.

And to make it even easier, I made a keyboard shortcut to cycle through the tag values, so I just click a street, tap the key, click the next street and tap the key again, etc.

Once all the “fat” streets are gone, I'm done with an area. Easy peasy! It takes about 15~20 seconds to take care of an area the size seen in the screenshot above.

I've taken care of most of Kyoto, and much of Osaka, but it's still a slow process to do a large area because I have to pan around looking for “fat” streets. If I zoom out too far, the tool exits editing mode and I can't see anything, so I have to be zoomed up, and just pan around.

Anyway, I'm tickeled that I could update the map editor. It's not the kind of programming I'm good at, and that they can build this kind of thing in a browser just boggles my mind. It garners appreciation that there are people out there much smarter than I, and that they donate their talents so freely.