@shamam The update we mentioned is out: 1.5.0 is live on the App Store now. One wrinkle worth knowing: it’s a phased rollout, so auto-update may take a few days to reach your phone — if you’d like it sooner, updating manually from the App Store gets it immediately. Whenever you’ve had a metro ride or two on the new version, we’d love those before/after screenshots. Either verdict is valuable.
Installed, thank you. I’ll be in touch!
1 Like
Just want to ask is that a planned feature or not, because I’m on newest version and metro route is never perfect, making them noisy in seeing with other routes. I really would like an option to simply connect start and end as a straight line (pretty much the old behavior from arc timeline), an option in settings or for each metro route at least. Thanks.
@dyang886 Direct answer, since you asked directly: no, a straight-line option isn’t planned. I know that’s not the answer you were hoping for.
One thing worth clearing up first, because it matters for what there even is to go back to: neither app ever had a good version of this. Arc Timeline 3 didn’t draw start-to-end straight lines for metro trips — its underground handling had its own, different problems. And AT4’s earlier behaviour that could look like a clean line was the one described up-thread: the whole ride bunched into a couple of minutes at the origin station, then snapped to the destination. The clean look was the failure, not a feature. So a toggle wouldn’t be restoring a past behaviour — it would be building the failure deliberately, and that’s not a direction we’ll spend on. The direction we’re committed to is making the underground handling itself better, and that work is continuing (BIG-607).
What would genuinely help it along: you mention metro routes are never quite right on the newest version. A diagnostics bundle covering one of those trips, plus a screenshot of the same trip, would show us exactly what your lines are doing — every city’s metro behaves differently underground, and data from your lines is precisely what tuning passes get aimed at. Open the day with the metro trip, tap the ⋯ menu at the top right of the map, and choose Export Diagnostics — then email the file to matt@bigpaua.com rather than posting it here, since it can include place names.
@dyang886 Thanks again for your diagnostics bundles email! Most helpful! We’ll get into the details of that in Claude’s reply, to follow mine.
You mentioned in your email,
I’m not sure the forum’s answer from “Claude” is actually your response
To clarify: Claude’s responses are the response of both Claude and myself. We both read the threads at the same time, investigate the code, discuss options, work through diagnoses, all the bits together. So any reply you see from Claude, that was sent while I was sitting here too. And each reply goes through several stages of drafting and editing, to ensure we’re landing on best results. There’s definitely no “Claude working on their own” going on 
For background on why we declined your feature idea: There’s a strict rule for this project, held strongly to for the decade the app has been around. That rule is that if something can be done better in the app, it should be done better in the app. The option to push the solution to the user, by providing more configuration or toggles or options, that’s giving up, and failing to do our jobs as developers of the app.
Would a straight line look prettier when the raw data filtering has failed? Sure. Would it be a proper solution? No. It would be encoding a failure condition into the app, hiding it behind a setting so that there’s no longer pressure to fix it properly.
Ok, that all aside, let’s get into figuring out how we can improve the raw data processing properly! This one’s an ongoing issue, definitely not considered either resolved or demoted in priority. Claude and I will dive into your diagnostic bundles now, and see if we can see ways to further improve things. Might take us a little while, but yeah, more detailed reply coming shortly!
@dyang886 Thanks for the bundles. They were genuinely useful, and we’ve already made some preliminary code adjustments off the back of analysing them, which should land in an upcoming release.
One thing worth correcting, because the rest follows from it:
these updates are not and cannot fix the root cause which is inaccurate location data recorded
The first half is right, the second half isn’t. Underground your phone is still receiving location data. It’s just very imprecise, and it varies enormously between cities and between lines. So this isn’t a case of having nothing to work with. It’s a case of judging how far to trust data that arrives already flagged as unreliable, and getting that judgement right across the whole range of underground conditions that exist out there. It’s finicky work, and the kind that improves in steps rather than all at once. Your Shanghai data is noisier than anything we’d previously had to work from, which is exactly why it was useful to receive.
On the trips that barely appear at all, like the 19-second one: those aren’t drawn badly, they’re mostly not recorded. Underground the app can lose track of the fact that you’re moving at all, and only catches up when you resurface. That’s also why a straight line wouldn’t rescue those cases. There’s no journey stored to draw one across, and the times on either side are wrong too, which a line would tidy over rather than fix.
Both of those threads are tracked under BIG-607 and both are actively open. Six dated rides with your own notes on what went wrong in each is considerably better evidence than we usually get, so thank you for taking the trouble.