{"id":2651,"date":"2015-12-03T21:58:17","date_gmt":"2015-12-03T12:58:17","guid":{"rendered":"https:\/\/regex.info\/blog\/2015-12-03\/2651"},"modified":"2015-12-03T21:58:17","modified_gmt":"2015-12-03T12:58:17","slug":"the-scourge-or-beauty-of-snap-to-road-with-iphone-location-tracking-apps","status":"publish","type":"post","link":"https:\/\/regex.info\/blog\/2015-12-03\/2651","title":{"rendered":"The Scourge (or Beauty) of “Snap To Road” with iPhone Location-Tracking Apps"},"content":{"rendered":"\n\n

I've discovered an issue with how an iPhone give location information to apps, an issue that can have a\ndramatic<\/span> impact on the accuracy of location data. The impact<\/span> is either really good or really bad,\ndepending on what the app (and you) want to use the location information for.<\/p>\n\n

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

I can imagine that this feature is really useful for apps providing turn-by-turn driving directions.<\/p>\n\n

It's not so wonderful for how I use<\/span> location-aware apps: for tracking my cycling activity<\/a>, and for geoencoding photos, both of which are harmed by this\nroad-snap effect.<\/p>\n\n

Unfortunately, an app developer (and hence an app user) can not control which kind of data the app gets. I've submitted the bug\nto Apple (“<\/span>CoreLocation:\nlocation snap-to-road can't be controlled by the developer<\/i><\/a>”<\/span>).<\/p>\n\n

If you are a user of apps, or a developer,<\/span> you can do some things to mitigate the issue, so that's\nwhat this blog post is about.<\/p>\n\n

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\ncontinuous track. The part colored<\/span> red is the first half, an upside-down “<\/span>L”<\/span> loop, done without the road-snap effect. You can\nsee<\/span> that it more or less tracks the outside edge of the road for the whole loop.<\/p>\n\n

\nTale of One Tracklog<\/span> colored into two halves, the red without road snapping, the blue with\n<\/div>\n\n

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

If I were using this track to geoencode photos, I would<\/span> certainly want to differentiate photos taken\non one side of the road from the other, but this “<\/span>snap to road”<\/span>\nfeature destroys the true data, and I lose<\/span> that ability.<\/p>\n\n

\nI Wasn't<\/span> Zig-Zagging<\/span> <\/div>\n\n

The elevation between a road-side path and the road can be quite different, so besides giving the incorrect history, it can\ncontribute to incorrect ride-climb data.<\/p>\n\n

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

As a cyclist, the only thing worse than mistakes that shortchange my achievements are mistakes that inflate them.<\/p>\n\n

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

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

Another common manifestation of this problem is seen when stopping at a traffic<\/span> light, as illustrated here:<\/p>\n\n

\nStopping at an Intersection<\/span>\nTravel is north to south on the image-right side of the road.\nRed line is the actual path traveled.\n<\/div>\n\n

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

\nStopping at an Intersection #2<\/span>\nActual travel is north to south on the image-right side of the road.\n<\/div>\n\n
\nStopping In Front of a Friend's<\/span> House<\/span>\nThe spike in the top half is manufactured by the road-snap “<\/span>feature”<\/span>\n<\/div>\n\n

There's another wrinkle to the road-snapping issue: it seems to happen only when traveling above a\ncertain<\/span> speed threshold, around 20~30kph (12~19mph)<\/strike>\n[Update:<\/b> as reported in this followup post<\/a>, it\nturns on at 20kph]<\/b>.<\/p>\n\n

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

Yet, how does this explain the craziness while stopped at the intersection, or while stopped in front of a building<\/span> in the\nexample immediately above? If you're not moving, you should be below the speed threshold. My guess<\/span> is that the non-precise variability found in consumer-grade GPS\/GLONASS units (as illustrated here<\/a>, and especially when the unit\ndoesn't have a good<\/span> satellite fix, as illustrated\nhere<\/a>) creates data points that meander around your actual location, and if one meanders far enough away,\nit 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\nroad-snapping thing, and in its desperate attempt to match that point to the center of some road, we see these spikes that\nmake the “<\/span>non-precise variability”<\/span> so much worse.<\/p>\n\n

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

So, what causes this problem to be turned on in the first place?<\/p>\n\n

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

Here's another example, from this cycling\ntrip<\/a>. Here, the location track reported to the app is shown in blue. I added<\/span> the red line to\nindicate where I actually<\/span> rode the bicycle:<\/p>\n\n