5 ms·

Trying to predict reflections by processing building geometry sounds very complicated and error-prone. Wouldn't it be easier to query Google Maps & Waze teleme

Trying to predict reflections by processing building geometry sounds very complicated and error-prone. Wouldn't it be easier to query Google Maps & Waze telemetry for impossible position jumps? Then you could make geofences where Google Play Services ignores position jumps and falls back to Wifi-based location and integrating the accelerometer.

skzv 5y ago
We consider and integrate all kinds of solutions, accounting for building geometry is just one of them, and we do thorough validation to ensure it's actually helping. There's always various tradeoffs being made. Ideally, clients will be using our Fused Location Provider API [0] which fuses any (or all) of GNSS, WiFi, accel, gyro, mag... with smoothing + filtering to provide the best location possible at any time while automatically managing power compromises; in effect, using WiFi + accel, as you described, along with more signals and filtering. However, some clients still choose to use pure GPS/GNSS, for various reasons. Part of providing the best location experience possible (while simultaneously minimizing power drain...) is providing high accuracy at every percentile. Some techniques that may improve the average or median percentile error may cause higher errors at the 90% percentile. For example, let's say we check for "impossible" GNSS position jumps, and just ignore those. What if 10% of the time, the position it's jumping to is actually closer to the true position - since suddenly we might have better line of sight - and previously we were stuck at a worse estimate? What might help in one situation might hurt more in another. It's hard to build robust systems to handle every possible scenario and condition (on all sorts of different kinds of hardware from tons of vendors, since anyone can launch an Android device). It's even harder because, as you can image, smartphone grade sensors are magnitudes worse than those you find in survey or military grade hardware. Also, WiFi-based localization can only be as good as the estimate of WiFi access point location, which isn't always great (and it's usually worse so since WiFi signal strength localization isn't that great), so GNSS is generally higher accuracy under good conditions (and hence rectifying GNSS error wherever we can is one of our goals), and the error of accel/gyro based dead-reckoning grows quadratically/cubically (due to double integration errors), so it doesn't get you very far. [0] https://developers.google.com/location-context/fused-location-provider https://developers.google.com/location-context/fused-locatio...
- motoxpro 5y ago
  Great description of why hard problems are hard :) Thanks for the time and hard work!

skzv 5y ago

We consider and integrate all kinds of solutions, accounting for building geometry is just one of them, and we do thorough validation to ensure it's actually helping. There's always various tradeoffs being made. Ideally, clients will be using our Fused Location Provider API [0] which fuses any (or all) of GNSS, WiFi, accel, gyro, mag... with smoothing + filtering to provide the best location possible at any time while automatically managing power compromises; in effect, using WiFi + accel, as you described, along with more signals and filtering. However, some clients still choose to use pure GPS/GNSS, for various reasons. Part of providing the best location experience possible (while simultaneously minimizing power drain...) is providing high accuracy at every percentile. Some techniques that may improve the average or median percentile error may cause higher errors at the 90% percentile. For example, let's say we check for "impossible" GNSS position jumps, and just ignore those. What if 10% of the time, the position it's jumping to is actually closer to the true position - since suddenly we might have better line of sight - and previously we were stuck at a worse estimate? What might help in one situation might hurt more in another. It's hard to build robust systems to handle every possible scenario and condition (on all sorts of different kinds of hardware from tons of vendors, since anyone can launch an Android device). It's even harder because, as you can image, smartphone grade sensors are magnitudes worse than those you find in survey or military grade hardware. Also, WiFi-based localization can only be as good as the estimate of WiFi access point location, which isn't always great (and it's usually worse so since WiFi signal strength localization isn't that great), so GNSS is generally higher accuracy under good conditions (and hence rectifying GNSS error wherever we can is one of our goals), and the error of accel/gyro based dead-reckoning grows quadratically/cubically (due to double integration errors), so it doesn't get you very far. [0] https://developers.google.com/location-context/fused-location-provider https://developers.google.com/location-context/fused-locatio...

motoxpro 5y ago
Great description of why hard problems are hard :) Thanks for the time and hard work!