What it Takes to Build Accurate GPS Maps
Building something like the new Track Attack may seem simple when it’s being used (and that’s our goal) but there’s a ton of complexity behind the scenes. This is the first in a series of blog posts where we’ll pull the curtain to the side and share a little bit about the various things that make Track Attack tick.
Track maps: Need more than a cartographer to make these happen.
When a datalogger collects GPS data, the position is recorded as a series of three coordinates: latitude, longitude, altitude. When you import a session data file into Track Attack, our system reads that file, regardless of where it came from and store it as the same three coordinates. When you select the session, Track Attack will show the trace outline, of each lap, of where you drove.
Every degree of latitude equals a number of pixels high, and every degree of longitude equals the same number of pixels wide. With these coordinates we get a track map on the screen.
However, it looks very distorted when compared with Google Earth. This is because one degree of longitude at the equator is not the same distance as one degree of longitude at the poles.
To get the outline to look right, we’ll have to dig into map projections
Map projections: slide rules, engaged!
very simple projection is the equirectangular projection. In this projection, the distance between two longitudes gets smaller as we get closer towards the poles by the cosine of the latitude. The calculation for this is straight-forward and makes the distortion much less apparent:
At the time we wrote the drawing code, we didn’t feel like that this was good enough for our users. So we looked into an orthographic projection. The idea behind this projection to show how the map would look if you were very far away from it:
The further you get away from the center point, the more distorted the image gets but right at the center point, everything should look as if you’re flying above it looking down.
So we implemented that fix and it worked pretty well:
But then we were sent this from New Zealand:
The first problem is that the track is rotated wrong, but the more obvious problem is that it is severely distorted. We tried the same data with the different projections and the results looked better. This pointed to a problem with our projection code.
We poured over it, re-wrote it, tried different approaches to the orthographic projection, nothing was working. We were close to scrapping the orthographic projection and going with something like mercator which is what Google uses for Maps. But it didn’t feel right, this projection should definitely work.
We decided to take a look at the inputs into the code instead of the code itself. To calculate the projection for each data point, you pass in the latitude and longitude of the data point you want to project as well as the latitude and longitude for the point at the center of the projection. The data points looked good (hovering around (-37.8652, 175.341)) but the center point had an incorrect longitude: (-37.8646, 90.0)...weird.
Looking through the code that passes the value into the projection code, we found that we had cleaned the inputs a little too aggressively. We made sure that latitude and longitude for the center point was between -90º and 90º, which makes sense for latitude. However, longitude actually ranges between -180º and 180º.
The reason the problem didn’t show up in other parts of the world is because the actual longitude data fell between ±90º. And the reason the problem didn’t show up in the other projections was because they didn’t rely on the center point.
Why does all this stuff matter? We want to help drivers get faster, faster - with quality views into data.
At the end of the day, everything we do is to help drivers and teams get faster and more consistent. The view of a session or a lap from a track position standpoint is one of the most critical views. Knowing where exactly a driver was during a braking, turn-in, or accelerating event is absolutely critical and even more so when you are comparing two different laps (from the same driver or different drivers).
One of the other things the new Track Attack is all about is making the data from different data loggers automatically comparable. While there are not a ton of ways to do geo-location data logging, there are enough of variations and nearly each data logging system uses a different approach. So when we say that an AiM user will be able to automatically compare data from a MoTec user and a RaceLogic user, we need to go down to these levels of understanding and working with the data. We can’t simply take what the loggers give us and simply draw those maps.
Going to these lengths, in just about everything we do, ensures that the data each user sees, is the real data and we give the best and most actionable views into that data.