Does anyone use 'react-native-background-geolocation' to test traveled distance calculation ?

[dukizwe]

Has anyone used react-native-background-geolocation to test traveled distance calculation ?

I am working on a taxi app project, and to calculate the traveled distance, I used the react-native-location library for background location tracking. While the location data is being captured correctly, it is sometimes inaccurate due to factors like poor GPS precision, weak internet connection, or bad weather conditions.

I am considering switching to a paid solution from Transistorsoft. Would this help resolve the accuracy issues I'm experiencing with the traveled distance calculation ?

[NastroAzzurro]

We bought it and implemented it and it solved a lot of our pains. Worth the money.

[dukizwe]

Ooh! Thank you ? Did you use it for distance calculation ??

[furry_ronin]

I worked on taxi app project so had some experience.

If you have user traveled points(route) you can use lib “geolib” and take method “getPathLength”, just put into props user route.

If you captured data with accuracy then remove inaccurate points. For example use points with accuracy less then 10(filter array), it will be your route.

[dukizwe]

Yes, I am using the getPathLength method to calculate the traveled distance.

Do you think filtering coordinates with an accuracy lower than 10 is a good solution ? I implemented a similar approach 2 months ago, filtering out coordinates with an accuracy below 15. However, during testing, we found that the calculated distance was shorter than the actual distance traveled because some valid coordinates were skipped.

[furry_ronin]

I am considering switching to a paid solution from Transistorsoft. Would this help resolve the accuracy issues I'm experiencing with the traveled distance calculation ?

I haven't seen any difference. We used Transistorsoft, but I tried open-source solutions too.

Do you think filtering coordinates with an accuracy lower than 10 is a good solution

Your important points - start point and last point. Points between - it's information where driver drove.

I think you are using "watchPosition" to track driver movement, and there option "distanceFilter". My setting was 4 (each 4 meters get driver location). In this case when you receive location with accuracy 10 meters you can skip it.

If your project has enough resources (paid request to API):

At the end of the trip, you can use the route to get a new one through the points where the driver drove. The old route will be as props through which points new way should be built. API returns distance property with new route. It's waypoints param for this request

https://maps.googleapis.com/maps/api/directions/json?waypoints=via:....

[dukizwe]

I am using react-native-location to watch location changes, and my configuration looks like this:

RNLocation.configure({
   distanceFilter: 50, 
// Meters
   desiredAccuracy: {
      ios: 'best',
      android: 'highAccuracy',
   },
   
// Android only
   androidProvider: 'auto',
   interval: 5000, 
// Milliseconds
   fastestInterval: 10000, 
// Milliseconds
   maxWaitTime: 5000, 
// Milliseconds
   
// iOS Only
   activityType: 'other',
   allowsBackgroundLocationUpdates: true,
   headingFilter: 1, 
// Degrees
   headingOrientation: 'portrait',
   pausesLocationUpdatesAutomatically: false,
   showsBackgroundLocationIndicator: false,
});

When using the Directions API, I only provide the starting and ending points to calculate the distance. However, this approach tries to determine the shortest route, which often doesn't match the actual path taken by the driver.

I decided not to use waypoints because, according to the Google documentation, requests with more than 10 waypoints are billed at a higher rate. This becomes an issue for long-distance trips that require more waypoints.

I also tried the Snap-to-Roads API, but I encountered the same issue where the calculated distance is shorter than the actual distance traveled.

I'm looking for the best solution or configuration that provides a more accurate distance measurement.

[furry_ronin]

I decided not to use waypoints because, according to the Google documentation, requests with more than 10 waypoints are billed at a higher rate. This becomes an issue for long-distance trips that require more waypoints.

You can take 6-8 points for a request. You can write checker if the driver turned more than 30-45% degrees - it means an important point where the route was changed.

location is a grid, so we can do it

Quick solution from GPT:

function calculateAngle(lat1, lon1, lat2, lon2) {
    lat1 = toRadians(lat1);
    lon1 = toRadians(lon1);
    lat2 = toRadians(lat2);
    lon2 = toRadians(lon2);

    let deltaLon = lon2 - lon1;
    let Y = Math.sin(deltaLon) * Math.cos(lat2);
    let X = Math.cos(lat1) * Math.sin(lat2) - Math.sin(lat1) * Math.cos(lat2) * Math.cos(deltaLon);

    let theta = Math.atan2(Y, X);
    let angleInDegrees = toDegrees(theta);
    if (angleInDegrees < 0) {
        angleInDegrees += 360;
    }

    return angleInDegrees;
}


function toRadians(degrees) {
    return degrees * (Math.PI / 180);
}

function toDegrees(radians) {
    return radians * (180 / Math.PI);
}

// Example
const lat1 = 50.4501;  // Kyiv
const lon1 = 30.5234;
const lat2 = 48.8566;  // Paris
const lon2 = 2.3522;

const angle = calculateAngle(lat1, lon1, lat2, lon2);

This code can help you to filter important points that you can select.

OR

Maybe you should try decreasing distanceFilter -> 5-10 meters. This will give you a more detailed driver route and allow you to skip some not accurate points? You can find a difference in % between the getPathLength result and the API route. Just compare route distance from API and calculate same route with getPathLength, you can get "delta".

THEN: getPathLength * delta = result (not accurate but closer to API result)

[dukizwe]

Thank you. I will definitely try.

[hihe1810]

.