0

I'm making an android function that saves the route path that my client travels in while he is logged-in to my app. Kind of like how Uber tracks the ride path.

This works fine most of the time, Like many before me have stated, the GoogleLocationclient API sometimes returns "BAD" locations in its "onLocationChanged" function.

Let me define "BAD" location :- these are location updates that are fetched while the LocationRequest.setPriority = LocationRequest.PRIORITY_HIGH_ACCURACY and the returned Location has a Location.getAccuracy() < 50, but is more than 1000 meters off the actual current location.

So to deal with this issue, I've setup a 3 point queue which caches 3 consecutive location updates and compares them to each other and saves the middle location only if its distance to 1st and 3rd location is lesser than the location between the 1st and 3rd points.

This approach works fine when only one error point pops up between 2 accurate points.

MY PROBLEM

When more then 2 "BAD" locations received consecutively, this logic fails to filter out the incorrect location and no future points get validated. :(

Can anyone suggest :- a) algorithm for optimizing the filtering of location updates

                     or

b) algorithm to filter out "BAD" locations after collecting all the location points for the trip.

Any help is much appreciated. If this is a duplicate question, kindly forgive my oversight and link me to the original :).

TIA.

Community
  • 1
  • 1
Prince Champappilly
  • 303
  • 1
  • 7
  • 29

1 Answers1

1

I would try the following:

1) Save a timestamp with every location point. 
2) Now calculate the movement speed between your actual point and your last point based on the timestamp and the location points
3) If the movement speed is higher than what is possible -> throw this point away / else keep him and move on
IIIIIIIIIIIIIIIIIIIIII
  • 3,958
  • 5
  • 45
  • 70
  • I need to track them while they walk and while they go by car ... So I don't know how much this will help ... But i guess I'll try an implementation that blocks anything over 120kmph and see where it gets me ... Tnx I'll let you know how it goes – Prince Champappilly Dec 14 '16 at 18:53
  • yea I think this would work since the time deference between location updates is pretty low. -> So if 1 point is suddenly 1000m away you will get a absolutely unrealistic speed value I think. But let me know I am very very interested in your results – IIIIIIIIIIIIIIIIIIIIII Dec 14 '16 at 19:02
  • MarkB :- I tried this and found some improvement . . . along with some other issues as well, I'm trying out an idea my brother suggested. I'll post my findings by tomorrow. – Prince Champappilly Dec 16 '16 at 05:21