Location Accuracy Issues and Optimization Strategies in Ride-Hailing Applications

Preface

Harbor, an internet mobility company, embeds positioning deeply in its core business flows. The map team frequently encounters positioning bad cases, which are complex and hard to extract value from. This article revisits the topic of positioning problems in the context of improving user experience for downstream markets.

Problem Overview

No Location

When the app starts without obtaining a location, users are prompted and order creation is blocked. Users must select a start point via POI search or map dragging.

Location Drift

Location drift is the most impactful issue for order fulfillment. It does not block order creation, so the problem surfaces when drivers arrive at the start point and cannot find passengers, leading to poor user experience or order cancellation.

Example: an order was cancelled because the initial GPS point was inaccurate, causing the driver to miss the passenger.

Current Situation

Harbor uses the Gaode (Amap) positioning SDK. Issues are reported via tickets to Gaode, but many bad cases cannot be reproduced due to strong environmental interference, and Gaode provides limited logs. Consequently, many positioning problems are dismissed as “system issues”.

Complexity of Positioning

Understanding the diverse phone positioning mechanisms (Android vs iOS) is the first step. The article outlines the need to clarify causes of inaccuracy, Gaode’s mechanisms, and possible remedies.

Positioning Principles

Phone manufacturers implement their own positioning stacks, which differ across devices. Gaode SDK abstracts these differences on Android. Positioning capabilities include GNSS, dead‑reckoning (DR), map‑matching (MM), visual positioning, and network positioning.

1. Satellite Positioning (GNSS)

GNSS determines device coordinates by measuring signal travel time from multiple satellites. With several satellites, four unknowns (x, y, z, clock bias) are solved. Satellite ephemeris can be obtained directly from satellites (slow, ~30 s) or via A‑GNSS (SUPL) over the internet, enabling rapid fixes.

Sources of error include ionospheric and tropospheric delays, multipath reflections, satellite clock bias, and ephemeris errors. Dual‑frequency GNSS mitigates ionospheric delay, improving accuracy to <5 m (e.g., Xiaomi 8, iPhone 14 Pro).

Device Differences

iOS : Closed positioning stack; only final location is exposed, no raw observations (satellite IDs, signal strength). iOS 12 added BeiDou support, but the source (satellite vs network) cannot be distinguished.

Android : Open APIs provide raw GNSS data (NMEA, GnssStatus, GnssMeasurement, GnssClock, GnssNavigation), allowing richer analysis.

2. Network Positioning

Uses Wi‑Fi and cellular base‑station fingerprints. It complements GNSS, especially indoors or in tunnels. Gaode’s network positioning is available only on Android because iOS does not expose fingerprint data.

Data products:

AP library – MAC address or cell ID mapped to geographic coordinates.

Fingerprint library – statistical or neural‑network features of signal strength distributions.

Issues arise from moving Wi‑Fi (hotspots on vehicles), cloned Wi‑Fi (identical MACs), and relocated Wi‑Fi, leading to inaccurate anchor points.

Key Takeaways

Location results come from satellite or network positioning; each can degrade accuracy.

Gaode’s network positioning benefits Android; iOS relies on system positioning.

iOS starts with coarse base‑station location (hundreds of meters) and refines over time.

Android can retrieve detailed satellite and Wi‑Fi information; iOS cannot.

Enabling Wi‑Fi improves network positioning.

Targeted Solutions

Based on the analysis, a series of optimizations were designed to address “no location” and “location drift”.

Monitoring System

Instrument critical points (first location acquisition, order creation with current location) to quantify the impact of abnormal positioning on orders.

No‑Location Optimization

Prompt users to enable Wi‑Fi and lower the precision threshold when location cannot be obtained, then retry.

Drift Optimization

When the start point is far from the real user location, show UI warnings and require confirmation. Implement noise detection and correction using sensor fusion (IMU + GNSS) and Kalman filtering.

Sensor Fusion Details

• PDR (Pedestrian Dead Reckoning) estimates steps, stride, heading using accelerometer, gyroscope, magnetometer. • Kalman filter combines GNSS observations with IMU predictions to smooth drift. • IMU provides high‑frequency motion data; GNSS provides absolute fixes.

Algorithm Deployment

Three stages: offline data collection to define baseline behavior, online data collection for model training, and online deployment.

Offline: capture standard and abnormal cases, derive baseline parameters. Online: collect GNSS + IMU data after app launch (delay 3 s to avoid startup impact), respect performance constraints, and stop collection after order submission.

Kalman filter flow: prediction step uses previous state and motion model; update step incorporates latest GNSS measurement; matrices (A, Q, R, H, K) are defined accordingly.

Results

Post‑deployment, abnormal positioning cases were retrospectively corrected, reducing drift distance and improving order fulfillment. Visual comparisons show significant reduction of outlier points after correction.

Conclusion

Through data‑driven monitoring and algorithmic improvements, the team mitigated the “two‑eye‑blind” era of positioning, clarified the impact of drift on orders, and achieved measurable gains. Ongoing work is required to further refine models for the remaining complex cases.