Open Radar

 
[OpenRadar Note: images submitted with the bug are visible here:  http://regex.info/apple-bug-23737784/ ; Further examples and a discussion of the ramifications is presented here: http://regex.info/blog/2015-12-03/2651 ]

Location data given to apps via CoreLocation services sometimes sees the location "snapped" to the center of a nearby road.

This is a useful feature or horrible bug, depending on the specific use case. A turn-by-turn navigation app probably wants this "snap to road" feature, but a fitness-tracking app, with users running in parks or cycling on river-side paths, probably does not.

There are two facets to this bug:

  1) CoreLocation docs do not indicate how a developer can request the inclusion/exclusion of this feature.

  2) If *any* app triggers the snap-to-road feature, *all* apps get that data.

This feature has a big impact on the quality of the data, so a developer should be able to have control over it. Currently, it does not seem to be possible.

---------- Details follow ------------


This map-matching feature does not seem to be mentioned in the documents at all, but as best as I can tell, setting the ActivityType to any value except CLActivityTypeOtherNavigation triggers the snap-to-road feature. In particular, it seems regrettable that the ActivityType "CLActivityTypeFitness" triggers snap to road, because many jogging paths and cycling trails are near enough major roads to trigger road snapping, but far enough away that it's obviously undesirable to do the snapping.

However, even if CLActivityTypeOtherNavigation is chosen, if *any* other app chooses something else, all apps get the snapped data. It took me a while to figure out why my favorite tracing app continued to get bad data even after the developer switched to CLActivityTypeOtherNavigation, and it turned out that it was because I was also running other location apps at the same time.

One final wrinkle: even when one of the three "snapping can happen" activity types is chosen, the location is not always snapped to the nearest road. In my tests, it seems apparent that it happens only when the speed is above a certain threshold (~25kph). Another theory is that it happens when the GPS/GLONASS confidence is low, but my personal testing does not bear that out.

One side effect of all this is that while stopped at a traffic light, normal drift of the GPS/GLONASS location can make it appear that the user suddenly moved quickly enough to trigger the road snapping, which then can cause even bigger jumps as iOS tries to find a road location to snap to. As a mild example consider the attached image "havoc-while-waiting-at-a-stoplight--red-is-actual-path.png" where I road a bicycle north to south on the image-right side of the road (this is in Japan where we drive on the opposite side from America)....

The track leading to the intersection is snapped to the middle of the road because I was cycling sufficiently fast to trigger the snapping. Then I had to wait at the traffic light, and the track just goes crazy. Then as I pull away from the intersection, it's not snapped to the center of the road because I don't have sufficient speed yet.

Another example of the same thing can be seen in attached "example2.png", where I was stopped for a few minutes in front of a friend's apartment. Apparently three of the data points were outlying enough to be "snapped" to wildly-incorrect roads.  Also notice that the approach from the south and exit to the south are perfectly aligned on the center of the road.... neither GPS nor my cycling are that precise, so it's clear that these were snapped by LocationServices.

"example3.png" illustrates another situation where the road snapping is undesirable, with the red line indicating the riverside path I actually cycled.

"example4.png" illustrates how an unrelated app can influence the data the first app gets. In this example, there is a single continuous track made with one app using CLActivityTypeOtherNavigation. I colored the first half of the track, an upside-down "L" loop, in red. As you can see, it more or less tracks the outside edge of the ~15m-wide road (though it seems that Google's satellite imagery is shifted south a bit). Anyway, without interacting with that tracking app, I started another fitness-tracking app that apparently does not use CLActivityTypeOtherNavigation, then I did the upside-down "L" loop again. That half of the track has been colored blue, and as you can see, it is snapped to the center of the road, both out and back. The sense of movement has been completely lost.

Whether snap-to-road is useful depends entirely on the use case, so the developer should have complete control, and not be subject to having to guess based upon insufficient documentation, nor be subject to the interference from other apps.


Version:
9.1 (13B143)

Notes:
To record tracks for testing, I used Galileo Offline Maps (https://itunes.apple.com/us/app/id321745474) while working with the developer. He provided me, via TestFlight, a version that explicitly uses CLActivityTypeOtherNavigation.

Some apps that suffer the snapping problem (and inflict it onto other apps, including Galileo Offline Maps) include GeoTagr (for geoencoding photos), Wahoo Fitness, Google Maps, and Runmeter. 

Searching the web brings up folks complaining about this since iOS6 (e.g. https://www.openstreetmap.org/user/Kachkaev/diary/20064  and  http://ilquest.com/2012/11/02/ios-6-is-unusable-for-people-relying-on-accurate-gps-tracks/ ), but I personally did not suffer this problem until circa iOS9. Perhaps Kyoto map data didn't get included in this feature until then?


Configuration:
iPhone6+ 

Attachments:
See http://regex.info/apple-bug-23737784/