Evaluating Technical Feasibility for GPS-Based Route Tracking App

Summiting a 5,000 ft mountain after a two-day hike through the forest is an unforgettable experience that leaves lasting memories in the mind of the traveler. One of the ways to extend that pleasure even more is by recording the achievement digitally, preferably on a mobile application. We were approached by a client to run a technical analysis for a mobile application for that specific functionality.

Framing the Problem

The client approached us with a vision: a mobile application that awards users for hiking achievements. The app would use GPS to verify the uniqueness of each route. This seemingly straightforward concept was shrouded in technical challenges, notably in battery management and the calculation of unique kilometers, which demanded an exhaustive feasibility study.

Setting Up Technical Feasibility Study

After getting down all the project’s requirements, we created a workshop plan for feasibility analysis of the application and focus on solving the two biggest challenges.

We assigned a small, cross-functional team to the project. When choosing people for the task, we focused on three aspects:

• Familiarity with GPS-based applications (completed past projects: Uproad and OnniBus)
• Experience in exploring the problem sphere on a small budget, including the creation of a prototype and checking potential product success (for example by using no-code tools, AI, and user research)
• Knowledge of data protection regulations in the European Union

Evaluating Battery Management for Optimal GPS Settings

Proper battery management is crucial for an app that tracks route achievements. It ensures that each feat is accurately recorded over extended periods, especially when users travel in areas with no access to charging. If the app drains the battery quickly, users may find themselves with a dead device, unable to track their trails, receive achievements, or even navigate.

Android and frequent battery termination issues

Android devices are notorious for terminating applications running in the background. Although it affects many different applications, it’s most noticeable with GPS-using apps.

Researching the problem online, our team found that even well-known applications like Strava also suffer the termination problem. The problem is actually so prevalent that a grading service has been developed by “Don’t kill my app” to list out different Android smartphone manufacturers and their propensity to terminate a GPS-using application running in the background.

Interestingly, this problem doesn’t exist on iOS.

Battery management considerations

Our key requirement when conceptualizing the solution for battery management was the uninterrupted collection of GPS coordinates when the app ran in the background. Official Google developer recommendations advise against the frequent fetching of coordinates (citing battery drain).

We couldn’t find a flawless solution for battery management, but there are passable workarounds:

• Using external devices for GPS tracking: like smartwatches, such as Garmin or Apple Watch.
• Relying on system settings: Many Android device manufacturers create system overlays and optimize battery life in their own way. Turning off the smart application management setting decreases the risk of the app being killed.

Researching Options for the Calculation of Unique Kilometers

Having a feature to track the uniqueness of each kilometer helps enforce the idea that each reward granted is for a distinct effort. By ensuring that rewards are only granted for unique kilometers traveled, the app avoids diluting the value of achievements and maintains the integrity of the reward system.

But there is no single, perfect solution for determining location using GPS. Here are the three most common ones:

• Using external services for the “snap to road” feature
• Designing the app so that it sends coordinates to a server where the "magic" happens
• Calculating the location offline, on the device

Each approach has its pros and cons related to scalability, cost, technical capabilities of the device, ease of updates, portability to other platforms, or the necessity of having an internet connection.

So to pick the most optimal solution, we first asked a question:

Is our solution supposed to take into account existing hiking trails and paths?

In commercial solutions, the “snap to road” algorithm is often used to overlay GPS coordinates onto existing routes or highways, like in Uproad. But we opted not to use “snap to road” here due to the potential density of paths in cities (the app was designed for nationwide use) and the possibility of walking in unmarked areas such as meadows and parks.

Route calculation solution 

Using the “snap to road” services was promising, but we ran into challenges:

• When the user doesn't walk on the predefined path saved in the app, it’ll return an error. We also lose control over the paths (with the “snap to road” there can only be paths that run on the officially recognized paths by the service provider, and hikers often walk on uncharted territory).
• External services meant sending data outside to a third-party provider (risk of violating data privacy regulations).
• Even with "snap to road," we'd still need to somehow manage and remove paths where the user has already been so that they don’t interfere with the “uniqueness” of every kilometer.

To address these issues, we explored geohashing.

What is geohashing?

Geohashing is a spatial indexing system that divides the world into a grid of tiny squares and assigns a unique code to each square, typically using a combination of letters and numbers. It's a way of encoding geographical coordinates (latitude and longitude) into a short string of characters. This approach offers an efficient way to identify a location with varying resolutions and can be useful for a range of applications, including detecting previously visited locations.

By using geohashing, we used a simple algorithm that detects and records the squares (geohashes) where a user has been. To counteract situations where GPS inaccuracies might mark a slightly off geohash, we checked neighboring geohashes, assuming that if a user appeared in at least two neighboring squares, it's likely a measurement error. We also considered path intersections. This way, we can detect whether a user is retracing their steps on the same path or proceeding in a different direction.

How to prevent the app from giving points for the same route?

One of the solutions we came up with was measuring the speed between GPS measurements — with a proper set of parameters in place, the app could easily recognize if the user was indeed traveling on foot. Implementing the safeguards against cheating (i.e., traveling by car, train, or bike) is a key feature of achievement applications for hikers or runners.

Fast Prototyping with ChatGPT

OpenAI’s ChatGPT is a great addition when building a prototype based on predefined project parameters. So after we narrowed down what we would need the application to do, and all the safeguards and route calculation customizations, we asked ChatGPT to output a few backend functions in Node.js and quickly prototyped the frontend in Flutter.

After creating a build from that code, we confirmed that the application worked within set parameters.

In this way, ChatGPT helps in quick prototyping and can be an important addition to a product owner’s toolset for technical feasibility workshops.

The prototype had everything we needed to check our solutions to battery management and unique kilometer calculation.

Testing the Prototype

With the prototype ready, we ran some internal testing of the application. Here are the results:

Testing the algorithm using externally sourced data

We asked one of our colleagues to share GPX data from his out-and-back run measured using Garmin Forerunner 945.

Result

After inputting the GPS coordinates into our algorithm, we received a value of 8.91 unique kilometers. The specified accuracy met our expectations (a loop in Uraz extended the unique section).

Testing the prototype and comparing the results to Apple Watch:

For the next test, we used iPhone 14 Pro and Apple Watch 8 as a tracking device. We also took an Android smartphone (OnePlus 7 Pro) with the prototype running (the location was fetched no sooner than 40 seconds and over 30 meters.

In both cases, the distance measured using the Apple Watch was about 10% shorter than with the application. The result is due to less frequent location sampling and path approximation. This test made us aware of the need to experiment with different refresh rates and to closely examine the accuracy of the results.

Testing the app’s prototype on two different Android devices

We wanted to compare how two Android smartphones (OnePlus 7 Pro and Huawei P20 Pro) would work with the application. We were curious to check how flagship older devices differ in terms of satellite data fetching.

Here's how the two Android devices fared:

The results are very inaccurate, with a large jump at the beginning of the route extending it by almost 1 km. There are also "teeth" toward the end of the route. The results we got was 5.2 km (with Apple Watch measuring 3.3 km).

The 3.5 km result from OnePlus 7 Pro is much more accurate than that of Huawei P20 Pro and closer to the Apple Watch measurement.

Testing summary:

Feasibility Analysis: Mobile Application and GPS Implementation

In developing our GPS-based route tracking app, we grappled with battery management and calculating trail uniqueness. Through testing and experimentation, we could prove the operational feasibility of the idea and use geohashing as a pivotal solution to address GPS discrepancies. Additionally, using ChatGPT to support rapid application prototyping further underlined the need for adaptability in feasibility studies. With rigorous internal testing and continuous refinement, we were able to validate the proposed project and produce a dependable application.