location provider ping-pong?

[tve]

• App build number: 2.4.12 installed from Google Play (would much prefer F-Droid!)
• Android version: Android 14, degoogled version of AOSP, CalyxOS to be specific
• Device: Pixel 7

I'm having an issue with what I would describe as location provider ping-pong. I have GPS enabled and I believe that in this location the wifi hotspot mapping is inaccurate. The result is that the device seems to jump back and forth between the locations. Here's a trace and notice how it periodically bounces between 32.499,-100.818 (GPS) and 32.50259,-100.81661 (presumably wifi/hotspot location mapping). (Note that I did change the integer part of the location for obfuscation.)

Obviously, the fact that the hotspot location is incorrect isn't owntracks fault, however, this seems like a fairly generic problem and it would be nice for owntracks to filter the updates and not use the less accurate hotspot location when it is getting GPS updates. Maybe this is not possible, I'm not that intimately familiar with the Android API.

Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:58:31 owntracks/tve/pixel7                t=  tid=l7 loc=32.49944,-100.81808 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:58:45 owntracks/tve/pixel7                t=  tid=l7 loc=32.49943,-100.81807 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:58:59 owntracks/tve/pixel7                t=  tid=l7 loc=32.49942,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:10 owntracks/tve/pixel7                t=  tid=l7 loc=32.50259,-100.81661 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:13 owntracks/tve/pixel7                t=  tid=l7 loc=32.49943,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:25 owntracks/tve/pixel7                t=  tid=l7 loc=32.50259,-100.81661 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:27 owntracks/tve/pixel7                t=  tid=l7 loc=32.49943,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:40 owntracks/tve/pixel7                t=  tid=l7 loc=32.50259,-100.81661 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:40 owntracks/tve/pixel7                t=  tid=l7 loc=32.49944,-100.81805 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:54 owntracks/tve/pixel7                t=  tid=l7 loc=32.49945,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:00:08 owntracks/tve/pixel7                t=  tid=l7 loc=32.49945,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:00:22 owntracks/tve/pixel7                t=  tid=l7 loc=32.49947,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:00:36 owntracks/tve/pixel7                t=  tid=l7 loc=32.49947,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:00:50 owntracks/tve/pixel7                t=  tid=l7 loc=32.49948,-100.81803 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:01:04 owntracks/tve/pixel7                t=  tid=l7 loc=32.49947,-100.81803 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:01:18 owntracks/tve/pixel7                t=  tid=l7 loc=32.49945,-100.81804 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:01:32 owntracks/tve/pixel7                t=  tid=l7 loc=32.49946,-100.81805 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:01:40 owntracks/tve/pixel7                t=  tid=l7 loc=32.50259,-100.81661 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:01:46 owntracks/tve/pixel7                t=  tid=l7 loc=32.49947,-100.81805 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:02:00 owntracks/tve/pixel7                t=  tid=l7 loc=32.49945,-100.81808 []  (...)

This is how it looks like on the map:

[growse]

For the non-Google API, the current approach does subscribe to both GPS and non-GPS (network etc.) providers, and those locations arrive independently. Having something that can intelligently filter these is on the TODO list. I'm hoping this is partially fixed in the upcoming v2.5, but there's a number of challenges here that I think can only really be borne out through testing on different devices.

Is your non-GPS location coming with large accuracy value that can be filtered with the ignoreInaccurateLocations setting?

[tve]

Sadly the accuracy is useless for filtering. Here is a summary of the positions reports truncated to three decimals over the past ~24 hrs. The position with lat=30.502 is the inaccurate one:

  count acc,lat,lon
    645 100.000,30.499,-110.818
    551 10.000,30.502,-110.816
    378 48.000,30.499,-110.818
     23 3.000,30.499,-110.818
     10 48.000,30.499,-110.817
      8 4.000,30.499,-110.818
      7 18.000,30.499,-110.818
      7 15.000,30.499,-110.818
      6 24.000,30.499,-110.818
      6 16.000,30.499,-110.818

The location provider stuff comes from micro-g, I've had everything enabled as shown in the screen shot below. I did disabled the Mozilla/hotspot sources and left only the two "remember from GPS" a bunch of hours ago and it seems to make no difference. Reboot coming...

[growse]

Fair enough re: accuracy. That's annoying, I agree. Will work on a better solution for the future, probably will put the received locations through a kalman filter + some other sort of intelligence based on source and recent history.

[Intenos]

I experience the same issue with an Andoid phone.