Metro’s route went crazy after recent update
Also another problem is that I created two private places with different names by accident at the same place, but there doesn’t seem to be a way to delete private places?
Hi @dyang886, two separate things here, so let me take them in turn.
The metro route. This is underground-train territory. In 1.3.0 we put real work into improving how underground train lines get recorded (BIG-150), but it depends on the line itself producing at least roughly-usable raw location data underground, and that varies a lot between cities and lines. Yours is actually the first report we’ve had of an underground trip coming out this messy since that 1.3.0 work, so it’s genuinely valuable feedback.
What would help most: how often does this happen for you? Every metro trip, a particular line, or a one-off? The more we know about how reliably it makes this kind of mess, the better we can judge whether there’s something specific to dig into.
Deleting private places. You’re right that there’s no direct delete. Places are meant to clear themselves once they fall out of use, but ones near where you spend time are deliberately kept around for future re-use — so a duplicate at a regular spot tends to stick rather than disappear. The proper fix for your case is place merging, which is planned (BIG-153 — resolving duplicate places by merging them). In the meantime, if you reassign the accidental place’s visits to the correct one, the stray just sits harmlessly and won’t get picked for new visits.
Every metro so far since update, 2 to be exact, before the update it has a straight line, which I’d say should be a safe fallback if your new system can’t process on meaningful data
1 Like
I have seen this jaggedness occasionally in the new update, but not often, and nowhere as bad as what you have experienced.
It decided to turn east around 86 St. The old Arc Timeline 3 doesn’t do this. But most of the time this seems okay. I think it’s still better than 1.2.x.
1 Like
@dyang886 @trackerminerfs — thanks both, this is genuinely useful field data.
@dyang886, “every metro since the update” is the key detail — a consistent case is far more useful to us than a one-off. A clean straight-line fallback turns out trickier than it sounds (we can’t reliably separate good underground fixes from noise at recording time), but you’ve flagged a real shortcoming on noisy lines and we’re playing with some ideas that could help. Filed as BIG-607 — no timing yet, but your every-trip Shanghai case is exactly what we’d tune against.
@trackerminerfs, yours actually looks largely right — that one jump near 86 St is the same root, just an isolated blip rather than a whole-route version, and the kind of thing those same ideas would smooth. Good to hear it’s net better than 1.2.x for you. Both reports are on BIG-607.
Thanks @ikuhiromorita — useful sample. This is the same underground-train issue dyang886 and trackerminerfs flagged earlier in this thread: on metro lines where the underground location fixes are basically noise, tracing them faithfully throws the path off badly. It’s tracked as BIG-607, and yours makes it three separate reports now across different cities — which helps confirm it’s about how noisy a given line’s signal is rather than anything city-specific. On the back of these we’ve bumped its priority, so it’s firmly on the near-term list, and samples like yours are exactly what we’ll tune against.
Is there a specific reason why metro (in my case even some train) routes are worse in Arc v4 versus v3?
I feel like this is the one feature that got significantly worse with the app version update while everything else improved by a lot.
@Quartor — fair question, and you’re right that it’s the one area where v4 took a real step in a different direction. Underground stretches are the hard case: there’s often little or no usable GPS, so it comes down to how much you trust the noisy fixes you do get. v4 handles that differently from v3, and dialling in the right balance has been the tricky part — on lines where the underground signal is at least usable it’s now better than v3, but on the noisiest lines the current build leans too far toward tracing the noise, which is the jaggedness you and a few others in this thread are seeing.
It’s tracked as BIG-607, and yours makes it the fourth confirming voice across different cities — which is what pushed its priority up; it’s firmly on the near-term list now. The honest catch is that cleanly telling a good underground fix from a noisy one is genuinely hard, so I won’t promise a specific result yet, but it’s actively being worked, and reports like yours are exactly what we tune against.
To add, one thing I’ve found really odd is that new gps data seems be a lot more realistic looking on the map but totally off from reality.
These are two underground trips this week. The top is what the line actually looks like, and the middle is something the arc made up from the shotty gps signal. (Ignore the bottom line).
It used to just draw a straight line from the start to end of the tunnel where it lost signal, without the ability to split. That worked in this case, but there are many “made up” locations along the middle line and natural curves at places I was nowhere near and I am able to split them as if they were a consistently recorded trip.
@twilldre — good catch, and the splittable part especially: a fabricated stretch that behaves like genuinely-recorded data (you can split it as if it were real) is a genuine cost, not just an aesthetic one.
I’d gently push back on one thing though — the old straight line looked cleaner, but it usually hid a badly-wrong item underneath. On a ~15-minute underground ride it’d bunch all the samples at the origin station — with no real fixes coming in underground, the recorded position just sits there — then snap them to the destination once you surfaced and GPS/wifi returned, leaving a “train trip” of maybe 2–3 minutes at an impossible top speed, samples clustered in all the wrong places. Clean line, badly wrong data. The current approach, when the underground fixes are at least somewhat usable, gets the substance closer — a trip that starts about the right time, with sensible-ish duration and speed — at the cost of the path sometimes being partly invented. So it’s a real trade, not just a regression.
The honest why: underground, there’s often little or no true GPS, so it comes down to the handful of fixes that do arrive — and those vary wildly in trustworthiness from line to line. Some underground lines hand back genuinely usable fixes (even with alarming-looking accuracy figures); others return basically noise. The catch is the app can’t reliably tell which is which from the signal alone — so it’s a balancing act: filter hard enough to ignore the noise, but not so hard you throw away the lines where the data’s actually good. We’re tuning toward the least-bad middle — it’ll never be perfectly Just Right, but the aim is to be wrong less often.
It’s tracked as BIG-607, and a tuning pass on exactly this already shipped in 1.4.0 — not “done,” more that we’re watching how it lands across lines and will keep iterating; samples like yours are exactly what we tune against. Which raises the one useful question: are you on 1.4.0 yet? Your screenshots are from this week, so they could sit either side of that update — knowing which tells us whether you’re seeing the latest tuning or the previous behaviour.
If distinguishing whether data is useful to use is hard, I’d suggest to add it as a toggle, to toggle whether to use the smart detection or not. So the old straight line behavior is still there, which I’d prefer for now (the new update has basically the same messy behavior)
Thanks @shamam — no need to apologise, reports on this one are still genuinely useful. Yours is the same underground-train issue being tracked as BIG-607: on metro lines where the underground location signal is mostly noise, the current tuning traces the noise rather than ignoring it, and Tokyo makes yet another city confirming the pattern.
One quick check that would help: which version of Arc are you on? (Settings → version number at the bottom.) A tuning pass for this shipped in 1.4.0, so it tells us whether your trip was recorded on the latest tuning or the older behaviour.
And actually, one thing that would help even more: a debug log covering one of these metro trips. Settings → Debug Logs → tap the session covering the trip → Export log (the share icon), then email it to matt@bigpaua.com rather than posting it here (logs can include place names). 1.4.0 records extra underground diagnostics, so if you’re on it, your logs are exactly the data we need to tune this against — noisy Tokyo lines are precisely the hard case.
Currently 1.4.0 (72) but the date on that photo was June 26th, in case you have released an update in the last 10 days. Debug logs coming at you.
Thanks @shamam — the logs were genuinely useful, more than you might expect. They cover the exact day of your screenshot, so we now have a clear picture of what those lines were doing underground: your metro stretches were getting a location fix only about once a minute (sometimes less), which is exactly the starved-signal case we’ve been tuning for.
And your photo-date catch was spot on: that June 26 trip was recorded on 1.3.3, which predates a tuning pass that shipped in 1.4.0. Since you’re on 1.4.0 now — have your metro trips since updating looked any different? Better, worse, or same-mess? That’s genuinely the data point we’re missing, and another tuning pass is already lined up for the next release, so your answer helps aim it.
Thanks @shamam — that before/after comparison is exactly what we needed, and your logs have genuinely shaped the next round of fixes. The remaining artifacts in that July 5 shape match mechanisms we’ve already got fixes lined up for in the next release (including one where iOS re-delivers old location fixes and Arc was accepting them as new — the likely cause of those long spikes out to a single point and back). Tokyo’s noisier lines are our hardest test case, so if you’re willing, another before/after look once the next update ships would be gold.
Happy to help! Do you need screenshots and logs if the problem doesn’t appear? I’ve got auto-updates enabled on my phone so I may not notice if I receive a new version.. Please feel free to ping me here or email.
1 Like
@shamam Happy to hear it! We’ll ping you right here in this thread when the update is out, so no need to keep an eye on version numbers.
And yes, reports are valuable either way. “It looks normal now” is exactly what we’re hoping to hear, and screenshots of the same metro trips would give us a clean before/after comparison. If things still look wrong, screenshots plus a fresh log would be the most helpful.
One thing worth knowing: the changes in this update should help, but underground metro is the hardest case we deal with, so we’re expecting improvement rather than perfection. Your reports will tell us how much further we still have to go.