Mini program sorts stores by distance, but user at store entrance sees several kilometers—location drift or distance miscalculation?

Store distance wildly off: first distinguish location drift from an ununified coordinate system

Conclusion first: when a mini program sorts stores by distance and a user standing at the store entrance sees several kilometers, it is usually not phone GPS failure, but an ununified coordinate system or inconsistent distance specifications. Phone system location raw values are closer to WGS84, while domestic map services and mini program map components mostly process by GCJ02. Directly mixing the two commonly causes offsets from tens to hundreds of meters; when store spacing is already only a few hundred meters, sorting easily fails. Following 2026 project delivery habits, first align the four steps—location source, coordinate conversion, distance calculation, and front-end display—to the same coordinate system and unit, then verify on real devices. This is usually more effective than repeatedly changing location APIs.

This kind of feedback often appears after launch: a user opens the mini program downstairs, the nearest store is ranked third, while the first place is another store two kilometers away. Developers test in the developer tool and it works fine, because the simulated coordinates happen to come from the same source as the test data. To quickly identify the nature of the problem, print the latitude and longitude returned by location, stored by the back end, and used in front-end calculation separately, and see which segment has changed.

• Location layer: authorization method and whether high accuracy is enabled affect how much error the coordinates themselves have.
• Coordinate system layer: mixing WGS84, GCJ02, and BD09 appears as an overall shift, not random jitter.
• Calculation layer: distance formula, unit, precision truncation, and cache timing affect how stable the sorting is.

For the same store, why can two codebases calculate two different distances?

Distance is not hard to calculate. The hard part is that front end and back end have no agreement on which coordinate system to use, which type of distance to calculate, and how many decimal places to keep. Three common pitfalls: location coordinates are plugged directly into the formula without conversion; the front end uses straight-line distance while the back end uses route distance, and the two results are mixed in the same list for sorting; distances are rounded to kilometers before sorting, erasing differences of a few hundred meters.

A more convenient 2026 practice is to hard-code the specification in the API documentation: store uniformly in GCJ02, use meters as the distance unit, complete sorting on the front end, and convert on demand for display into “about 300 m” or “1.2 km.” Once the specification is clear, test cases can follow it, making it less likely for developers to say it is correct while operations staff say it is wrong.

Three distance calculation methods: where cost and effectiveness differ

The following comparison is compiled from project delivery experience. All figures are experience ranges and will vary with provider quotas, number of stores, and call frequency; use them only as a reference for trade-offs.

• Straight-line distance only: calculated locally, almost no call cost, with single-call time commonly in the millisecond range; the downside is that it differs from the actual walking path, and can be clearly inaccurate when rivers, elevated roads, or closed campuses are involved.
• Route planning API: closer to the real path to the store, with single-call time commonly in the hundreds of milliseconds; usually billed by call volume or subject to a free quota cap. When there are many stores and frequent refreshes, calculate the quota in advance.
• Precompute and cache distances: when store locations are fixed, calculate in advance and only look up a table at runtime, giving fast responses and saving calls; the cost is that adding, removing, or relocating stores requires rebuilding the cache, and an expired cache can show users outdated distances.

The trade-off logic is roughly: if users only want to see which stores are nearby, straight-line distance is usually enough; if you need to answer how long the walk takes and how to get there, you need routing capability; if the store list is stable and traffic is high, precomputation is more cost-effective. The three are not mutually exclusive; a common combination is to sort by straight-line distance on the list page and provide walking time on the detail page.

A practical troubleshooting sequence: from coordinates to sorting

Sorting problems are not suited to changing the formula right away. Troubleshooting in sequence saves detours and fits scenarios such as in-store pickup, on-site dispatch, and nearby recommendations.

1. Confirm the location source: system location, mini program location component, and manual user-selected point may have different coordinate baselines.
2. Print three sets of coordinates: print the location return value, the stored value, and the value used in calculation once each, and first check whether there is an overall shift.
3. Check coordinate system labels: whether database fields, API documentation, and caches specify the coordinate system; treat anything unlabeled as suspect first.
4. Unify the calculation specification: front end and back end agree on the same formula and unit, and sorting is done only under the same specification to avoid mixing two types of distance.
5. Verify sorting on real devices: use one iOS and one Android device, and check whether sorting is reasonable at the store entrance, across the street, and indoors.

The three layers solve different problems: the location layer addresses accuracy, the coordinate layer addresses bias, and the calculation layer addresses stability. Skipping the coordinate system check and directly adjusting sorting weights easily mistakes a coordinate problem for an algorithm problem.

Which scenarios deserve precision, and which do not need overinvestment

Worth investing in: in-store pickup, on-site dispatch, nearby recommendations, inspection check-in, and delivery range determination. In these scenarios users can directly perceive distance; an offset of a few hundred meters affects choices, so it is suitable to define the coordinate system and calculation specification clearly once and for all.

What does not need overinvestment should also be stated clearly: city-level distribution display, administrative district grouping, or store spacing already measured in kilometers—a few tens of meters of offset does not affect decisions, so there is no need for extensive fine-tuning of coordinate conversion. Indoor, underground garage, and inside-large-mall location signals are weak, and coordinate conversion cannot solve that. More practical approaches are to let users manually select a point, scan a store QR code, or enter an address, then roughly sort by area. The boundary can be remembered as: outdoors, unify the coordinate system before comparing distances; indoors, change the location method before comparing distances.

A troubleshooting case at a delivery site: how store sorting deviation was narrowed down

One delivery had very typical constraints: the mini program was already live, the budget was limited, there was no dedicated back-end developer, there were 60–70 stores, and users reported that the nearest store was not ranked first. We did not directly change the sorting algorithm. Instead, we first added an internal coordinate comparison page that displayed the raw location coordinates, converted coordinates, store coordinates, and calculated distances side by side. Within half a day we identified the root cause: store coordinates had been converted once before being stored, and the coordinates obtained from location were converted again—equivalent to converting twice. Some stores shifted as a whole, and sorting became disordered accordingly.

The approach had three steps: first clean the stored data under a unified specification and label the coordinate system; then consolidate distance calculation into one place; finally add a self-check entry so operations staff can spot-check whether a given store’s distance is reasonable at any time. The result was that metrics returned to an explainable range, outdoor location offset fell back within the typical experience range (roughly teens to tens of meters, varying by device model, weather, and building obstruction), and related feedback dropped noticeably. The cost was real as well: data cleaning plus joint debugging took about two to three days of work, and required an extra round of real-device verification and one version release. But it was more cost-effective than being repeatedly complained about after launch and then going back to fix the data.

Acceptance is recommended based on verifiable criteria, not just approximate appearance:

• Take 3 to 5 consecutive location readings at the same place; sorting remains stable with no back-and-forth jumping.
• Use at least one iOS and one Android real device, testing once inside the store, once at the store entrance, and once across the street.
• Database and API documentation specify the coordinate system, distance units are unified, and conversion is done only at the display layer.
• When users refuse location permission, there is a fallback path for manually selecting a city and manually searching for stores.

Counterexamples should also be known: verifying sorting on only one development machine, testing only with simulated coordinates, and directly using store coordinates of unknown origin in calculations are all high-risk. Only when coordinates are traceable, the distance specification is unique, and real-device records exist will sorting problems be less likely to recur.

FAQ

Is inaccurate store distance due to phone location itself being bad?

Usually not. Phone location has tens of meters of error, but if sorting is off by several kilometers, it is usually due to mixed coordinate systems or inconsistent distance specifications. Check the values first before considering changing devices.

Should distance calculation use straight-line distance or walking distance?

It depends on the use case. If users only need to see which stores are nearby, straight-line distance is enough and low-cost; if you need to provide walking time or navigation guidance, you need route planning, which costs more time and money.

Why is the distance calculated by the back end different from the one measured on a map?

It is commonly because the two sides use different coordinate systems, or one uses meters while the other uses degrees for precision. Unify storage and calculation to GCJ02 and align units, and the difference usually returns to an explainable range.

With few stores, can we skip API calls and hard-code distances?

When store locations are fixed, you can precompute and cache distances to save frequent calls; but stores may be added or removed, and user locations change, so set a good cache update timing and do not let it stay stale for long.

Can overseas stores use the same distance algorithm?

Not necessarily. Domestic use commonly uses GCJ02, while overseas use mostly relies on WGS84; mixing them in one dataset for sorting will cause errors. For cross-border business, it is recommended to calculate by region group, or store raw coordinates uniformly and convert separately.

Action guide: if the mini program is already live and users report that the nearest store is wrong, first troubleshoot in the order of “location source → three sets of coordinates → coordinate system labels → calculation specification → real-device sorting.” Do not rush to rewrite the sorting logic. Applicable boundaries: outdoor store visits, dispatch, and nearby recommendations are worth investing in coordinate calibration; pure display and indoor scenarios should prioritize changing the approach. Following 2026 project delivery habits, writing the coordinate system and distance specification into API documentation and the acceptance checklist can save most rework.