Updating Maps for Cycling, Including Japan’s Pseudo One-Way Roads

Note: this article may not appear properly in news readers.

This article contains interactive aspects that are likely removed by most news readers. Please see this particular article directly on Jeffrey's blog for full functionality.

A Map with a Hat

view on Strava

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, 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:

Map Data of Suspect Quality

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:

With Reference Data

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...

Fixed Result

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, but with my road-edge overlay






Better, but the roads seem to be shifted down and to the right a bit






Ah, that's better







span.b696 { padding: 6px; border: gray 1px solid }


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...

p.h2762 { font-size: 120%; margin-top:50px }

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.

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.

span.b778 { padding: 6px; border: gray 1px solid }


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 Galileo Offline 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 Galileo Offline 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...

Lurking Problem

lots of one-way streets.... sort of

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

Typical “One Way” Sign

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

“Except Bicycles”

自転車を除く

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:

Select the street segment

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:

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...

Sea of One-Way Streets

that may or may not have been updated for bicycles

... 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:

“Fat” Streets Need to be Updated

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.