A post at the geekier end of the spectrum as a couple of small changes to the VeloViewer Explorer Tile calculations are rolled out to fine tune some of those edge-case scenarios where tiles might have been missed. One key area was addressing the very rare occasions where your GPS device didn’t record a point in the required spot as your route crossed the very corner of a tile – the good news is this should now be sorted.
Most long-time VeloViewer Explorer Tile tickers will at some point come across this scenario where their recording cuts across the edge of a tile but VeloViewer isn’t showing that tile as ticked, even when you open the activity details page. The previous code would only tick a tile if a lat/lng point had been recorded in the tile. Typically GPS device record a point every second but some devices will default to “Smart Recording” where they discard points where nothing has really changed (direction, HR, speed) to allow for use of less storage space and smaller files.
Zooming right the way in on the recorded path in the VeloViewer Activity Details page will show a small, black dot for each recorded GPS point as shown in the above image which, in these rare cases, would show that the tile was just missed.
The updates
Note: these changes are just when opening the Activity Details and so populating the “definitive tiles for an activity” as described in this previous post.
1. Move from 5 decimal places to 6 for latitude and longitude
In the early days VeloViewer was just showing the overview maps on the Activities page using the “summary polyline” provided by Strava’s API. This is provided by Strava in an encoded polyline algorithm format. Basically as a string which is much smaller than representing it as a lat/lng array. These polylines encode the numbers to 5 decimal places. For the majority of what VeloViewer does, 5 decimal places is fine, it is accurate to around 1 metre. It turns out that 1 metre of simplification can actually result in you not ticking a tile!
6 decimal places for lat/lng is accurate to around 10cm. Of course your GPS device isn’t going to be that accurate but as far as VeloViewer is concerned, we want to do the best with the recorded data. Fortunately Strava’s activity data streams API (that provides the recorded lat/lngs) provides the data to 6 decimal places so we have changed our code to use that full level of precision.
The user’s data we’ve been testing out these updates with resulted in a few missed tiles being ticked just from this update as the 6 decimal places lat/lngs now fell the right side of the tile border. But there is equally the chance for a point to move to the wrong side with this increased precision meaning a previously ticked tile would now be not ticked.
2. Ticking those tiles that missed a recorded data point
Moving to 6 decimal places is all good but that won’t fix the occasional tile that still doesn’t have a data point recorded in its bounds. But we can all tell from looking at it that you must have ridden through it as one second you recorded a point one side, and the next second you were on the other side. A bit of simple maths is required to work out the intersection with the tile borders between those two recorded points to tell which tile you passed through and to tick that off.
A couple of restrictions need to be imposed though to do it’s best to not accidentally tick tiles you hadn’t passed through:
- No more than 5 seconds between the two points – Most people’s recordings are every second anyway and hopefully the Smart Recording will not have many gaps greater than 5 seconds. But this restriction is needed to make sure someone pausing their GPS device in one place and restarting it in another doesn’t tick off tiles between those two points.
- No more than 100 metres between the two points – Similar to the 5 second restriction, this is to handle GPS errors where the device gets lost (loses GPS signal in some way) and then finds it again and jumps to that location. We can’t be sure of the route between those two points so no tile is ticked.
The only scenario we’ve seen so far that can result in a tile not being ticked that you did pass through is when you travel through a tunnel that crossed through the corner of a tile. If the time/distance between entering and exiting the tunnel is great than 5 seconds/100 metres then it won’t tick any tiles in the middle. Not much we can do about that one but it really is the edge case of an edge case!