Explorer Tile Calculation Updates

The way that completed Explorer tiles are calculated has remained pretty static since its inception in March 2015 which included some, less than precise code to try to get around some of its known limitations (detailed below). I’ve now refined that code to improve the accuracy and also speed up the processing quite considerably and also introduced a method to get a definitive list of tiles for an Activity.  This improved accuracy will of course result in a number of tiles that were previously marked as ticked now showing up as unticked (and potentially affecting your max square size) but only tiles that you never actually visited in the first place 🙂

Related posts: VeloViewer Explorer Score and Max SquareVeloViewer Chrome Extension for Strava Website

Important things to understand

  • By default, the Explorer tiles are calculated using the summary map line for each activity which is the line you see in the map on your Activities List page. This is a simplified version of the route taken and can miss out some of the detail of your activity and occasionally fail to cross a tile boundary which you actually did cross, equally it can cross one that you didn’t!
  • An Activity’s summary map can contain a portion that you didn’t actually travel which should not be included in tile ticking. This usually happens for one of two reasons:
    1. The user pauses their GPS device for a cafe stop and forgets to restart it. Half an hour later they notice their mistake and restart it and a line straight between those two points is created mid-activity.
    2. A user starts recording their GPS device before a signal has been fully established from the satellites. This can result in a line coming from the last location the GPS was used to the current location once the GPS works out where it is.
  • Some summary map portions can be very long (especially for people riding on very long, straight roads) and from a data perspective can’t be differentiated from one of these GPS error lines so a max distance of line to consider for ticking tiles has to be implemented to try and limit the number of error lines being taken into consideration.
  • If the definitive set of tiles has been created for the activity (see below) then this list is then used for this activity on the Summary and Activities List pages rather than creating the set of tiles from its summary line.

Previous inaccuracies

  • Each portion of the summary map was populated with dummy data points every 100m and these, along with the end points, were used to create a list of completed tiles.
  • For each of these data points, a 100m buffer was allowed to cater for the gaps between each point.
  • There was no way to overwrite any incorrectly marked tiles (either false positive or false negative).
  • The max line distance for any single portion of the summary map was set to 10km. Any portion shorter than this would used to tick off tiles (resulting in some false positives where people have forgotten to restart their GPS) but also some activities that take in a straight road for longer than 10km would not get all of their correct tiles ticked.

The updates

Definitive tiles for an activity

The tackling of that final point above has been the spark that has ignited these other updates.  Now, when you open an Activity’s Details page (by clicking on its name in the list or on its line in the map on the Activities List), in the background it will work out and store a definitive list of the Explorer tiles completed for this activity using every single data point recorded. No need for the code to fill in gaps as the data should be recorded for every single second of the activity (people shouldn’t be using Smart recording these days!) so only those tiles actually visited will be ticked. i.e. no more false positives or false negatives for that Activity on the Summary and Activities List pages.

Note: you will need to head back to/refresh your Summary page in order to get any changes in your tiles included in the datafile for the Chrome Extension and also to update the leaderboards.

Removal of 100m buffer

Now that you can get that definitive list of tiles populated for a given Activity, that opened the door to remove the 100m buffer in the old calculation. I ran this idea past the community on Facebook and the “Ride Every Tile” Strava group and got 100% positive feedback to remove the buffer… so I did!

This will inevitably result in you loosing a few previously ticked tiles where you didn’t originally enter them fully, so time to plan some new outings.

Update to algorithm

I’ve also moved from the original method of adding additional points every 100m along each portion of a summary map to a purely algebraic approach which is far more accurate and also far faster to run. Remember, this will only be used for Activities that haven’t had their definitive set of tiles already calculated.

Max line length change

As I mentioned earlier, a hard coded 10km limit was applied to each portion of a summary map, if it was above this then the tiles covered along its length were ignored, if less then they were ticked off.  There still needs to be some limit in place but seeing as the summary map lines get more simplified (i.e. longer lines) the longer the distance of the Activity, I’ve changed that 10km limit to now be the [Activity distance]/10.  I’m sure this will still result in a few tiles being included when they shouldn’t and vice versa but in each of those cases just open the associated Activity Details page and the correct set of tiles will be set for that Activity from that point forwards.

Tiles calculated column/filter on Activities List

New column on the Activities List page called “Tiles calculated” that allows you to filter to show just those that have already had their definitive list of tiles calculated, or vice versa.

Inaccessible tiles

Some people will inevitably have tiles that they can’t physically get into because those areas are strictly off limits (e.g. Area 51). This is a bit of a pain for people wanting to continue to grow their Max Square but have a square they just can’t tick off.  A debate is ongoing on how this sort of thing should be handled over on this thread on the “Ride Every Tile” Strava club – https://www.strava.com/clubs/279168/posts/582450 (note: you might need to be a member of the club to see that discussion).

Whatever is agreed upon in there, I’m more than happy to implement 😀

0 thoughts on “Explorer Tile Calculation Updates

  • Yay awesome. I had about 5 long straight lines (Central Valley in California) that were bugging me that I didn’t get credit for. Just clicked on those activities, refreshed, and now I get credit for them. Thanks!

    I lost a few tiles too due to the buffer, but I’ll get them back even though some will require some deep hikes into the Sierras.

    Keep up the great work.

  • Man … I was planning on using that 100m buffer trick today! Dropped from 22 max square to 9, we’ll see what I get back to after getting definitive tiles for numerous rides.

  • So if i did ride a long straight road and lost squares because it was misinterpreted as a gps skip, what can i do?

    • Just open the activity up in VeloViewer and it’ll automatically build a list of all the tiles visited using the actual recorded data points. From then on that definitive list of tiles will be used for the totals on your Summary page and in the map on your Activities page.

    • Smart recording was introduced back in the day when storage space on devices was limited to save space. These days that isn’t an issue. The Smart recording basically leaves gaps so you just have to extrapolate the data between those gaps in order to work out averages etc so basically introducing a margin of error to your stats. Maybe not as much of an issue if you are not using any other sensors at all but as soon as you start using cadence and especially power sensors then you definitely want 1s recording to get as much fidelity to your data as possible.

  • I’m guessing that ‘clump’ refers to squares that are surrounded on all 4 sides by traveled squares – is that correct?

    • That’s right. I’m about to write another blog post to describe it all in detail. The vote on the recent Facebook post has resulted in the new name of Explorer Cluster.

  • I think it is correct to just count tiles you were actually in and not just near by.

    The Chrome Extention needs an update too, it shows me tiles as checked although I just crossed by by a few meters. Maybe old calculation?

    • The next time you do an update of any kind and then visit your Summary page the new set of tiles for the Chrome Extension will be created. It only rebuilds it after your core data has changed in some way.

  • Lars Vemund Solerød says:

    Any way to find out what activity caused the max sqaure or max cluster scores? Maybee provide a link to the activity on the score?

    • Lars Vemund Solerød says:

      I see I misunderstood theese scores.

      But maybee provide link to the activity map with this score toogle on? Because this was hard to find…

  • Apologies for silly question. I have previously used the MapsMe app to check that I have crossed into a new tile by downloading the KML file (thanks for putting an easy button to press)
    I was thinking that it was time for me to update the old file to the latest file, so I don’t see some old tiles that I’ve already ridden.
    I’ve tried clicking on the KML button, via my iPhone, which then prompts me to open it in MapsMe but when I then look in MapsMe it just looks like the old map.

    Just wondering if you had any advice? I have tried looking in the blog for the original mention of this app but I haven’t been looking in the right place…

    Cheers!

    • Not a silly question. Happened to me too. Here’s what I figured out: the new KML is, in fact, uploaded to MapsMe, but the old one is still there, and the old one is the default. So you don’t see the new one. Fix it by going into the MapsMe Bookmarks page (bulleted list icon) and deleting the old KML file.

  • Hmm, none of my activities have the definitive tile count computed, and viewing their details doesn’t seem to change anything. Is the feature currently down?

    • I’m not sure why but a few people have mentioned that they’ve experienced the same issue. I don’t remember changing any code in this area!
      I’ve just made an update to try and make it a bit more robust when you open the activity so hopefully it’ll populate the definitive tiles correctly now.
      If you still find that it is missing tiles out then please email me with a link to the activity and a screenshot of the missing tile on the map.

      • Hi Ben,
        the activity in question is
        1567492840
        and there, the tile around 51.313 / 7.306. It’s really not a big deal, but I noticed it during a test-ride for my garmin app and now try to understand what’s going on.

        • Can you email me with a screenshot showing where the tile isn’t ticked (i.e. on the Activities page with the explore tiles turned on). They all appeared to be ticked on that ride when I look at your data.

  • Chris Fearnley says:

    I am trying to get some ‘straight lines’ (where Strava was accidentally paused) removed, following your guidance above, but must be doing something wrong. I have clicked on one of the activities in question (in the VV activities list) but there’s no effect on the straight lines (or the ticked tiles). I have tried an update as well. On the activities listing, there’s an entry for ’tiles calculated’ = ‘yes’ ; other activities don’t have this marked.
    A example is https://veloviewer.com/athletes/1256264/activities/138528226. Strava’s own heat map doesn’t show a straight line here.

    • Hi Chris. When I open the map view on your Activities page the tiles aren’t ticked over Bodmin Moor where the ride was accidentally paused – https://cf.veloviewer.com/blog/BodminMoorExplorer.png
      So it looks to me that the completed tiles have been set correctly for that activity. The line will still be shown on the map as it is just showing the summary line provided by Strava for the activity which is always a continuous line from the start of the recording to the end. The Strava heatmap is based purely on the individual lat/lng data points from all of your recordings so is a very different thing than what I show.

      • Chris Fearnley says:

        Thanks Ben, I understand now. I just tried the method on another ‘old’ Strava ride that had an incorrect straight line where the squares had been ‘ticked’ After reloading, the map sqaures were unticked. I guess I had expected the straight line to have gone as well, but not of course if you use a totally different algorithm to the Strava heatmap.
        It’s a great app. I’ll now continue to cover as many squares in Cornwall as is possible!

  • Elmar Hogenboom says:

    Hi Ben,
    is there a way to know whether there are rides where I’ve not ticked them in reality and vice versa? As in, which activities I need to open in VV so as to get the right tiles ticked in my map? I thought of a few by looking closely at the map, but I’m sure there are more.

    • Hmmm, not really. I guess it would be ones that come close to the edge of another tile without crossing into it but that would probably be the majority of them.

    • Hi Jan, You should just need to the open the Activity Details in veloViewer and it will populate the definitive list of explorer tiles ticked off based on all of the recorded GPS points. See the “Definitive tiles for an activity” in this post for more info.

  • Katja Kircher says:

    Not sure whether this is the right place to ask this – it appears to me that activities marked as “ice skating” do not appear and are not calculated into the max square. Is this true, and is this something that will be addressed in the future? Ice skating on natural ice is a great way to access locations/tiles that are otherwise difficult to access, and it’s definitely a muscle powered activity. Thanks a lot for a great site!

    • Hi Katja. It should use all activity types (excluding Virtual Rides/Runs) towards your explorer tiles. Make sure you are sync’ing iceskating activities to VeloViewer by going to your Update page and expanding the Options section and then selecting the activity types you want to sync.

  • Guilherme Almeida says:

    Hi! Not sure if this was addressed before and if anything can be done to fix it, but I just noticed that tiles have inconsistent size, when comparing them to the map scale.

    It seems to be an effect of Mercator projection distortions, so tiles on locations closer to the Equator cover an larger area than tiles closer to the poles. For instance, tiles from my rides in Germany near 51°N cover roughly 2.25km², while tiles in Brazil at 20°S cover around 5km² and the ones in Argentina at 33°S are measured close to 4km².

    I love this feature, but it seems weird when not all tiles are measured the same. Riders from lower latitudes have to ride twice as further or more to cover the same number of tiles. And it can heavily skew leaderboard results.

    • Hi Guilherme. I mentioned this limitation back in this post from 2016. My sloppy excuse was that the weather is better nearer the equator so riding is more pleasant that riding in the far north or south!
      If the earth was flat then it would be really easy to provide a simple 1km grid over the whole world but unfortunately that isn’t possible which is why we end up having map projections like Mercator.
      As you say, the closer you are to the equator, the larger the tiles but as the tiles get smaller you often end up with more inaccessible tiles which often make trying to build your max square more difficult than if the tiles are larger.
      Whichever way you look at it, it still needs a grid laying over the planet for the concept to work which results in the changing sizes.

      • Guilherme Almeida says:

        Thanks for the reply, Ben! I realize the root of the problem lies at the map API level, maybe OpenStreetMaps eventually follows Google Maps at addressing the distortion, though I guess that not happened at all zoom levels.

        • I use Google Maps API as well as Leaflet and they both use the same Web Mercator projection. Only when you start seeing a globe (e.g. Google Earth or Cesium etc) do you get the proper projection.
          The only way to make the Explorer Tiling fairer (i.e. same sized tiles) is to go for triangles instead and find a geodesic polyhedron which has the right sized triangle to roughly match what we have now. My guess is the maths involved might be a bit more confusing and the idea of a “Max Square” and Clusters would need a big rethink!

  • Kalyan Dhanwantry says:

    Hi Ben,

    I have been using VeloViewer for few months now and pretty impressed.
    Could you confirm if there is Mobile app version too or its only a web version as of now.

  • Brouter doesn’t consider a tile as visited while VV does.
    Opening the activity page (in Strava) didn’t help.
    Would downloading the gpx and upload it again? (after deleting the first one o.c.)

Comments are closed.