How to Smooth Your Location Data & Snap to the Nearest Road

The application is also available at https://pubnub-roads-api-demo.netlify.app/ | Source Code.

Please note the front-end is always drawn with Google Maps, only the back end logic will switch between Google and Mapbox when you select the appropriate radio button.

For an explanation of how this application works, jump to the ‘Snap to the Nearest Road’ section.

Is this real data, or faked? The GPS coordinates are real, I recorded them myself from my Android phone whilst riding in an Uber. The corrected location is generated live everytime you run the demo by either Google or Mapbox, it is not predefined - feel free to check the code :)

Where to Start?

A naive Google search for “How to smooth GPS data” will return mostly mathematical answers and can potentially mislead developers. You are quickly led down the path of signal filtering and creating a Kalman filter to smooth your GPS track, and it is very easy to lose sight of the end goal.

Using a Kalman Filter

Many blogs that discuss the problem of noisy location data will make a sweeping statement such as “create a GPS point smoothing function, such as a simple Kalman filter,” and the Wikipedia article even includes an ‘Example application’ section that discusses using a filter to determine the precise location of a truck. Developers going down this route will then probably stumble on this ubiquitous Stack Overflow post or open source projects such as KalmanJS which appear suitable at first glance.

Developers quickly come up against practical issues in their implementation however; for example, the KalmanJS project is a 1D filter and so not ideal for location data, as emphasized by the author in his accompanying blog. The Stack Overflow code example is ideal for assets moving at a constant speed but breaks down as the velocity changes between updates (if you dive into the comments of that post, there is a discussion about why you cannot just naively change the velocity value based on the asset’s current speed)

So, why do all resources about smoothing location talk about using a Kalman Filter? In some situations, a Kalman filter is ideal. Consider a vehicle entering a tunnel or driving down a street with an intermittent line of sight to satellites. Using a combination of dead reckoning based on the last known position, speed, and velocity of the vehicle, along with GPS coordinates, a reliable tracking algorithm can be developed based on Kalman Filtering. A careful reading of the Example application from Wikipedia mentioned earlier shows that this is the exact scenario being discussed, NOT extrapolating the location based purely on GPS readings.

The maths required to create a reliable multi-dimensional filter is beyond the scope of this article and probably overkill for most developers creating a solution to track moving assets.

Location APIs

Developers have a wide choice of location APIs depending on their chosen platform, for example, the HTML5 geolocation API for web, the Android Fused location provider, or Apple’s Core Location Framework.

Location technologies and mobile phones (where most people first encounter location hardware) have been around for a long time. It is important to understand how the technology has evolved, especially since many search results on Stack Overflow are from nearly a decade ago.

Early location APIs only returned data from a single source to your application. For example, you could request data from the GPS chip, but then it was up to you as the developer to decide how best to handle that data.

The most significant enhancement to location accuracy came by amalgamating different location sources, not from smoothing data. For example, on Android, the Fused location provider’ will amalgamate the location data from GPS with other sources such as nearby WiFi, cellular signals, and Bluetooth signals.

Do I need to smooth data from the Location API? No, high-level APIs such as those returned by Android and iOS are already smoothed and processed, so it is not necessary to apply further smoothing. Even ‘raw’ GPS data is subject to smoothing by the chip firmware that reports its data to the higher-level OS, so no benefit will be gained from smoothing it further.

If all location APIs are smoothed, why does my location still jump around?

Moving at a low speed will never give a stable position, no matter how much the data is smoothed owing to technological limitations.

If you are tracking mostly stationary assets, the best way to avoid ‘jittery’ location fixes is to ignore any small changes that the API reports. Some high-level APIs make this especially easy with dedicated methods to set the minimum update distance before a location update is triggered. This will not enhance the accuracy of the location fix but will make it appear more stable.

What if you are tracking a moving asset, and the route traced by the location fixes is not smooth? The most straightforward approach to this problem is a pragmatic one, assuming the asset you are tracking is a vehicle moving along a road, just snap its location to the most likely road they are following.

Snap to the Nearest Road / Map Matching

There are two popular choices for snapping your location to the nearest road:

• Google offers a set of backend Roads APIs that take care of all the difficult road network logic for you. The Snap to Roads API will take a series of points and return the most likely route that the vehicle followed along a road or road segment

• Mapbox offers an entire suite of APIs for all aspects of locationing. Their Map Matching API will snap fuzzy, inaccurate GPS coordinates to the OpenStreetMap road network.