Panasonic LX100 at an effective 24mm — ¹/125 sec, f/13, ISO 200 — map & image data — nearby photos
My Hotel
is not quite in this league
Maître Island, Nouméa, New Caledonia
ニューカレドニア、ヌーメア市,メトル島

Desktop-Background Versions
1280×800  ·  1680×1050  ·  1920×1200  ·  2560×1600  ·  2880×1800

Sadly, we're at the Hilton on the mainland, with the worst in-room WiFi I've seen since.... well, since I last stayed at a major American hotel chain.

Panasonic LX100 at an effective 25mm — ¹/80 sec, f/1.8, ISO 250 — map & image data — nearby photos
Meeting Up
in northern Kyoto

Just a quick writeup with some pictures of a nice group ride that I did two weeks ago with some of the stronger riders from Cycling Kyoto!. I was by far the newest, weakest, slowest, least experienced among them, but they're a nice fun group so they made me feel welcome.

今回の写真は二週間前のサイクリングの事です。

Panasonic LX100 at an effective 24mm — ¹/125 sec, f/2, ISO 200 — map & image data — nearby photos
A Serious Group

Panasonic LX100 at an effective 25mm — ¹/125 sec, f/2.5, ISO 200 — map & image data — nearby photos
Tomas
fastest guy in the group
( tied with 20 other folks for nicest guy in the group )

Panasonic LX100 at an effective 30mm — ¹/125 sec, f/2.2, ISO 320 — map & image data — nearby photos
Vincent
wearing a ridiculously high-viz yellow jacket that totally overpowers the camera sensor
(This is the same Vincent recently seen doing my bike fitting)

Panasonic LX100 at an effective 30mm — ¹/125 sec, f/2.2, ISO 200 — map & image data — nearby photos
taken while cycling at 32 kph (20 mph)

Panasonic LX100 at an effective 24mm — ¹/125 sec, f/1.7, ISO 320 — map & image data — nearby photos
Joshua and Vincent
power past an old house; taken while cycling at 12 kph (7 mph)

Panasonic LX100 at an effective 25mm — ¹/125 sec, f/1.8, ISO 800 — map & image data — nearby photos
This Time With Autumn Colors

Panasonic LX100 at an effective 25mm — ¹/125 sec, f/1.8, ISO 800 — map & image data — nearby photos
This Time Out of Focus
so I did some “artsy” processing to see what I could recover from it

Panasonic LX100 at an effective 24mm — ¹/125 sec, f/1.8, ISO 200 — map & image data — nearby photos
Andy and Christoph
taken while cycling at 34 kph (21 mph)

Panasonic LX100 at an effective 44mm — ¹/125 sec, f/2.6, ISO 500 — map & image data — nearby photos
The Gang's All Here
taken while cycling at 39 kph (24 mph)

Panasonic LX100 at an effective 24mm — ¹/125 sec, f/3.5, ISO 200 — map & image data — nearby photos
I Guess You Had To Be There
it was really quite pretty in real life
taken while cycling at 29 kph (18 mph)

Panasonic LX100 at an effective 24mm — ¹/125 sec, f/2.5, ISO 200 — map & image data — nearby photos
Tomas and Andy
taken while cycling at 35 kph (22 mph)

Panasonic LX100 at an effective 24mm — ¹/125 sec, f/2.5, ISO 200 — map & image data — nearby photos
I'm Not Sure What's Happening Here
photo by Joshua Levine

Panasonic LX100 at an effective 24mm — ¹/125 sec, f/3.5, ISO 200 — map & image data — nearby photos
All Smiles

Panasonic LX100 at an effective 24mm — ¹/125 sec, f/1.7, ISO 500 — map & image data — nearby photos
All Serious

Panasonic LX100 at an effective 24mm — ¹/125 sec, f/1.7, ISO 320 — map & image data — nearby photos
Gutsy
Tomas trying Andy's Insanely Steep climb

It was wet from a recent rain, so quite slippery. Discretion is the better part of valor, so Tomas aborted the attempt. I didn't even try. But as Rick H had suggested, I did measure the slope with the Compass Tool in my iPhone:

Panasonic LX100 at an effective 24mm — ¹/60 sec, f/1.7, ISO 250 — map & image data — nearby photos
Not So Bad!
Oh Yes It Is “So Bad!”

UPDATE: I originally wrote that it looked much steeper than the 21% “Nasty” hill, but that it actually measured less, and postulated that the discrepancy came from perhaps the perspective of being able to stand to its side and view it edge on. However Keven points out that I mixed up 20 degrees (the angle measured) with 20 percent (how slopes are rated). It turns out that an angle of 20 degrees is the same as a slope of 36 percent, which indeed is much more difficult than the 21% slope I used as a reference. What a sloppy mistake on my part, and what a hill! The iPhone compass tool doesn't display slope percent. There are many apps out there that would, but I just made a simple web-based slope tool that'll get the job done next time I want to measure.

Panasonic LX100 at an effective 25mm — ¹/125 sec, f/2, ISO 200 — map & image data — nearby photos
Colorful Christoph
taken while cycling at 34 kph (21 mph)

Panasonic LX100 at an effective 25mm — ¹/125 sec, f/2.5, ISO 200 — map & image data — nearby photos
Less Color
but more smile

Panasonic LX100 at an effective 25mm — ¹/125 sec, f/3.2, ISO 200 — map & image data — nearby photos
Three Muskateers
Antti seems to have regained his former stature

Panasonic LX100 at an effective 34mm — ¹/125 sec, f/2.3, ISO 320 — map & image data — nearby photos
Friendly Chat

Panasonic LX100 at an effective 75mm — ¹/125 sec, f/2.8, ISO 250 — map & image data — nearby photos
Approaching the Top
Hanase Pass (花背峠)

Panasonic LX100 at an effective 75mm — ¹/125 sec, f/2.8, ISO 320 — map & image data — nearby photos
Fake “Game Face” Competition

Panasonic LX100 at an effective 75mm — ¹/125 sec, f/2.8, ISO 400 — map & image data — nearby photos
Too Fast to Focus

Vincent and I live in the same general part of the city, so after the 80km ride we headed home together. We stopped by Radio Bagel for hot coffee and tasty carbohydrates. Yum.

I've discovered an issue with how an iPhone give location information to apps, an issue that can have a dramatic impact on the accuracy of location data. The impact is either really good or really bad, depending on what the app (and you) want to use the location information for.

The issue is that the iPhone can get into a mode where instead of providing apps with your location directly from its normal location-tracking methods (GPS/GLONASS, WiFi and cell-tower signal strength), it “snaps” the location to the center of the nearest road it knows about. I call this “snap to road”; internally at Apple, I hear it's called “map matching”.

I can imagine that this feature is really useful for apps providing turn-by-turn driving directions.

It's not so wonderful for how I use location-aware apps: for tracking my cycling activity, and for geoencoding photos, both of which are harmed by this road-snap effect.

Unfortunately, an app developer (and hence an app user) can not control which kind of data the app gets. I've submitted the bug to Apple (“CoreLocation: location snap-to-road can't be controlled by the developer”).

If you are a user of apps, or a developer, you can do some things to mitigate the issue, so that's what this blog post is about.

First, here's an illustration of the effect in action: the two colors of the track in the image below are parts of the same continuous track. The part colored red is the first half, an upside-down “L” loop, done without the road-snap effect. You can see that it more or less tracks the outside edge of the road for the whole loop.

Tale of One Tracklog
colored into two halves, the red without road snapping, the blue with

Then, I did something on the phone that turned on the road-snapping effect, and drove the exact same loop again. This part of the track is colored blue. The blue line perfectly matches the centers of the roads, and though you can't tell from looking, it's actually the same loop with both “out” and “back” segments.... they just overwrite each other on their perfectly-straight road-center lines.

If I were using this track to geoencode photos, I would certainly want to differentiate photos taken on one side of the road from the other, but this “snap to road” feature destroys the true data, and I lose that ability.

Here's another example, from this cycling trip. Here, the location track reported to the app is shown in blue. I added the red line to indicate where I actually rode the bicycle:

I Wasn't Zig-Zagging

The elevation between a road-side path and the road can be quite different, so besides giving the incorrect history, it can contribute to incorrect ride-climb data.

This road-snapping feature can also create artificial speed and distance numbers, which contributes to inflated distance and speed calculations for fitness apps. In the image above, as the road curves away from my actual path, the distance it's saying I'm covering is longer than the straight-line path I'm actually taking. Longer distance covered in the same amount of time means that both the speed and distance are reported incorrectly.

As a cyclist, the only thing worse than mistakes that shortchange my achievements are mistakes that inflate them.

Then in the middle you can see the track suddenly jig to the left. The road it was snapping my location to has now drifted too far away, so it decides to snap me onto a closer road that I'm also not on. That jump sees me suddenly accelerate to 87 kph for the one second required to make the adjustment, then return to the ~30kph speed I was actually traveling at.

Then there's some weirdness that happens as you near intersections... sometimes the road-snapping stuff can't decide which road you're on, and so it throws you around. You can see it near the top of the screenshot with one data point jutting out to the right. I was on the riverside path, down an embankment from the road, but as my location came close to the intersection above, it snapped me momentarily from one road to another, making it seem that I accelerated to ~130kph (80mph) on my bicycle for two seconds then immediately returned to a more human pace.

Another common manifestation of this problem is seen when stopping at a traffic light, as illustrated here:

Stopping at an Intersection
Travel is north to south on the image-right side of the road.
Red line is the actual path traveled.

As I traveled from the north, I had to stop at the intersection (on the north-east side of the intersection; this is Japan, where traffic flows on the left) to wait for the light. While standing still, one expects a location drift from a consumer-grade GPS/GLONASS unit, but the snap-to-road “feature” can turn it into spiky ordered disorder.

Stopping at an Intersection #2
Actual travel is north to south on the image-right side of the road.

Stopping In Front of a Friend's House
The spike in the top half is manufactured by the road-snap “feature”

There's another wrinkle to the road-snapping issue: it seems to happen only when traveling above a certain speed threshold, around 20~30kph (12~19mph) [Update: as reported in this followup post, it turns on at 20kph].

This can be inferred in “Stopping at an Intersection” example above. As I traveled at speed from north to south, the location was snapped to the center of the road until I reached the intersection and had to stop. I didn't accelerate quickly enough from the intersection to suffer the road snapping, so that part of the track shows the actual path traveled.

Yet, how does this explain the craziness while stopped at the intersection, or while stopped in front of a building in the example immediately above? If you're not moving, you should be below the speed threshold. My guess is that the non-precise variability found in consumer-grade GPS/GLONASS units (as illustrated here, and especially when the unit doesn't have a good satellite fix, as illustrated here) creates data points that meander around your actual location, and if one meanders far enough away, it can appear to an unsophisticated algorithm as if the actually-stationary phone has suddenly moved far enough away (which means fast-enough away) to invoke the road-snapping thing, and in its desperate attempt to match that point to the center of some road, we see these spikes that make the “non-precise variability” so much worse.

A cyclist would suffer this problem the most, as it's easy to exceed the threshold. Runners likely won't suffer it directly so much, except for the “non-precise variability” that can strike when paused.

So, what causes this problem to be turned on in the first place?

When an app tells the iPhone that it wants location information, it has four choices to indicate what type of app it is. Apple's developer documentation on this is woefully lacking details on the ramifications of the choice, but one can read something into the four names:

• CLActivityTypeAutomotiveNavigation
• CLActivityTypeFitness
• CLActivityTypeOtherNavigation
• CLActivityTypeOther

It turns out that this “road snap” feature is enabled except when using “Other Navigation”, which the docs say is intended for non-automotive navigation, e.g. planes, trains, boats, snowmobiles, etc.

On the surface this makes no sense, because one would think that road snapping would apply to only “Automotive Navigation”, and certainly explicitly not apply to “Fitness” (predominately walking, running, and cycling) or “Other”, where one can't make any assumptions on the use of location information.

When one digs in, it makes even less sense. It turns out that if any app requests something other than “Other Navigation”, all apps get the road-snapped data.

This means that if you don't want this “road snap” feature, you must run only apps that use “Other Navigation”.

Unfortunately, it seems that fitness tracking apps unsurprisingly tend to use the “Fitness” activity type when registering for location information, so they suffer this problem. I've tested Strava, Wahoo Fitness, and Runmeter (aka Cyclemeter and Walkmeter), and all invoke road snapping. To be fair, some users may consider this a feature, or consider it a feature at times and less desirable other times. It'd be nice if an app gave the user explicit control over this, but none of them do.

The only app I've found that does not invoke road snapping is Galileo Offline Maps (Name changed Feb 2019 to Guru Maps), an app I've been recommending for years for its ability to use high-quality maps while completely offline. In testing this issue over the last month, the developer has made special builds of his app available to me, so I'd like to think him for help in pinning this issue down.

I'm a geek about my data (as made obvious here) so I used to keep tracks of my cycling with multiple apps. I felt I got the best location track from Guru Maps, but Runmeter included temperature data and Wahoo Fitness included bicycle speed and cadence. And on top of that I used GeoTagr as a backup because other apps tended to spontaneously stop recording my track.

But now I can't use any of them because, as mentioned above, the use of any app with road snapping infects even non-snapped apps like Guru Maps. I can't even open up Google Maps, because it too (this time unsurprisingly), gets the road snapping. So to keep a pure tracklog, I can run only Guru and no others.

The bug has been submitted to Apple. The bug number is #23737784, implying that there are 23.7 million other bugs submitted before me, so I don't hold much hope for a response, but it'd be very nice if

1. Apple documented for developers the exact ramifications of the various CoreLocation activity types.
2. Apple made the road-snapping feature something an app could explicitly turn on and off.
3. Apple removed the ability for random other apps to influence the data you get.

I won't hold my breath, but until it's resolved I'll stick with Guru Maps. It's a bummer, but I've removed the Wahoo Fitness cadence/speed unit from my bike because I haven't found an app that can read its data without destroying my cycling track.

UPDATE: I've added some details in "More Details on the Insidious iOS Snap-to-Road “Feature”".

Panasonic LX100 at an effective 24mm — ¹/500 sec, f/5.6, ISO 200 — map & image data — nearby photos
On the Bike Path From Kyoto to Osaka
taken while riding at 20 kph (12 mph)

As I mentioned in “Confused Kyoto Cherry Trees Bloom Five Months Early”, Paul Barr and I rode our bikes down to Osaka from Kyoto. It's about 50km each way, so the round trip was about 100km (62mi) total.

Here's our trip on my cycling heatmap.

I'd made the same trip by myself earlier in the week, and written how windy it was for much of the day, but the wind during the trip down with Paul was by far the strongest sustained winds I'd ever ridden a bicycle in, on par with a medium-sized typhoon. It was just ridiculous. I made a short video trying to illustrate the wind:

It's just as well that we were planning on taking it slowly, because the wind left no other choice. It was Paul's second “real” bike ride, the first having been about 66km (41mi) with lots of mountains during this ride during NORU Kyoto's second social ride (pretty much a repeat of the first ride that I'd written about two weeks ago).

Panasonic LX100 at an effective 29mm — ¹/2500 sec, f/2.1, ISO 200 — map & image data — nearby photos
taken while riding at 23 kph (14 mph)

Panasonic LX100 at an effective 25mm — ¹/800 sec, f/5.6, ISO 200 — map & image data — nearby photos
Navigating the Stupid Gates

I wrote about these stupid gates the first time I rode to Osaka.

Panasonic LX100 at an effective 24mm — ¹/800 sec, f/1.7, ISO 200 — map & image data — nearby photos
Pleasant Mood
and slightly protected from the wind
taken while riding at 36 kph (22 mph)

Panasonic LX100 at an effective 24mm — ¹/16000 sec, f/1.7, ISO 200 — map & image data — nearby photos
Directly Into the Wind
taken while riding at 18 kph (11 mph)

Panasonic LX100 at an effective 75mm — ¹/2000 sec, f/2.8, ISO 200 — map & image data — nearby photos
Approaching Osaka
taken while riding at 18 kph (11 mph)

Panasonic LX100 at an effective 24mm — ¹/400 sec, f/6.3, ISO 200 — map & image data — nearby photos
In the City
taken while riding at 22 kph (13 mph)

Panasonic LX100 at an effective 24mm — ¹/200 sec, f/6.3, ISO 200 — map & image data — nearby photos
Still a Few Fall Colors
taken while riding at 11 kph (7 mph)

Panasonic LX100 at an effective 75mm — ¹/500 sec, f/5.6, ISO 200 — map & image data — nearby photos
Osaka Castle

Panasonic LX100 at an effective 28mm — ¹/125 sec, f/6.3, ISO 200 — map & image data — nearby photos
Made It!

Panasonic LX100 at an effective 25mm — ¹/500 sec, f/5.6, ISO 200 — map & image data — nearby photos
Me
photo by Paul Barr

Panasonic LX100 at an effective 24mm — ¹/320 sec, f/5.6, ISO 200 — map & image data — nearby photos
Circling the Castle
taken while riding at 15 kph (10 mph)

Panasonic LX100 at an effective 24mm — ¹/125 sec, f/5.6, ISO 250 — map & image data — nearby photos
Food Stand
of suspect quality

Panasonic LX100 at an effective 24mm — ¹/125 sec, f/5.6, ISO 1600 — map & image data — nearby photos
Bad Udon
at least it was warm

Panasonic LX100 at an effective 29mm — ¹/400 sec, f/5.6, ISO 200 — map & image data — nearby photos
Heading Back
amid much calmer winds

Panasonic LX100 at an effective 24mm — ¹/125 sec, f/8, ISO 640 — map & image data — nearby photos
Road Less Taken
the road had apparently diverged earlier in the yellow wood
taken while riding at 9 kph (6 mph)

Back in Kyoto, almost home, we came across a sign on the bicycle path we'd noted earlier:

Panasonic LX100 at an effective 52mm — ¹/640 sec, f/2.8, ISO 200 — map & image data — nearby photos
Inviting Sign
for Cafe Morning Glory

Panasonic LX100 at an effective 37mm — ¹/160 sec, f/5.6, ISO 200 — map & image data — nearby photos
Easy Access
down the slope, park bike at A-frame in lot, then across street to cafe

Panasonic LX100 at an effective 24mm — ¹/40 sec, f/8, ISO 3200 — map & image data — nearby photos
Just Desserts
coffee + choco-bannana crepe

The coffee and crepe were both very good and much more than we expected for the ¥1,000 ($8.15). Map links are under the photos... highly recommended if you're traveling by and want a snack. They just opened last month.

Panasonic LX100 at an effective 41mm — ¹/1250 sec, f/2.5, ISO 200 — map & image data — nearby photos
Long Shadows
taken while riding at 26 kph (16 mph)

We'd left Paul's hotel at about 8:30 in the morning, and returned at about 4:30 in the afternoon, just before sunset (4:46). Not bad for his second real ride.

Nikon D4 + Voigtländer 125mm f/2.5 — ¹/500 sec, f/2.5, ISO 100 — map & image data — nearby photos
Squished Flat And Turning Orange
formerly-plush carpet of leaves now reduced to old tattered rags
two days ago at the Ochiba Shrine in Kyoto Japan
二日前、岩戸落葉神社（京都市）

My timing is getting all mixed up, but two days ago I posted about the Ochiba Shrine, with pictures from two weeks ago when it was in its full carpet-of-leaves splendor. By the time I'd posted it (two days ago) the splendor had passed; this post contains photos from a visit two days ago.

Nikon D4 + Voigtländer 125mm f/2.5 — ¹/400 sec, f/2.5, ISO 180 — map & image data — nearby photos
Paul Barr

Nikon D4 + Voigtländer 125mm f/2.5 — ¹/400 sec, f/2.5, ISO 800 — map & image data — nearby photos

Nikon D4 + Voigtländer 125mm f/2.5 — ¹/400 sec, f/2.5, ISO 280 — map & image data — nearby photos
Slow Drip

Nikon D4 + Voigtländer 125mm f/2.5 — ¹/3200 sec, f/2.5, ISO 100 — map & image data — nearby photos
Not So Bad
when viewed from afar

Nikon D4 + Voigtländer 125mm f/2.5 — ¹/500 sec, f/2.5, ISO 100 — map & image data — nearby photos
Impostor

Nikon D4 + Sigma 35mm F1.4 DG HSM — ¹/1250 sec, f/1.4, ISO 100 — map & image data — nearby photos

Nikon D4 + Sigma 35mm F1.4 DG HSM — ¹/400 sec, f/1.4, ISO 110 — map & image data — nearby photos
Less-Trampled Area

Nikon D4 + Sigma 35mm F1.4 DG HSM — ¹/400 sec, f/2, ISO 250 — map & image data — nearby photos

Nikon D4 + Sigma 35mm F1.4 DG HSM — ¹/400 sec, f/6.3, ISO 1400 — map & image data — nearby photos
Reverse View
not quite as nice as from the outside looking in

On the way home, we stopped by the Yama no Ie Hasegawa restaurant for coffee...

Nikon D4 + Sigma 35mm F1.4 DG HSM — ¹/250 sec, f/1.4, ISO 6400 — map & image data — nearby photos
Hot Coffee
Yama no Ie Hasegawa (山の家はせがわ)

And dinner...

Nikon D4 + Sigma 35mm F1.4 DG HSM — ¹/250 sec, f/1.4, ISO 6400 — map & image data — nearby photos

And dessert...

Nikon D4 + Sigma 35mm F1.4 DG HSM — ¹/320 sec, f/1.4, ISO 6400 — map & image data — nearby photos

A visit here is always a nice way to end an outing.