Citymapper has this bizarre flaw (in London at least) where it relies on average times to give you journey times.
So, for example, if your train takes 10 minutes to reach your destination, leaves your local station every 30 minutes and you've just missed one, CityMapper will show an estimated journey time as 25 minutes (avg wait 15 minutes + 10 min journey), instead of the actual 39.
On multi-train journeys like many Londoners have, that error compounds quickly, and it can make choosing the fastest route near-impossible. And I don't know why they do it, because they have all the timetable data (including live timetables).
They also have harder problems to solve when it comes to buses. During the tube strikes, it was incredibly frustrating to have all the route suggestions involve getting the 29 in Camden. Anyone who's attempted to get the 29 from Camden late at night will know what I'm talking about.
Essentially they need to start including knowledge not just about how frequent transport is supposed to be, but the typical number you'll have to miss before you can get on. For the 29 in Camden this number is around 5.
But, as Citymapper becomes more ubiquitous within each city, this becomes a solvable problem. They can use the real-time usage of Citymapper to model congestion, and offer better route suggestions. I'm quite happy to use a journey that's 15 minutes longer if it means I'm warm, rather than standing in the cold for 30 waiting for the 'faster' option.
A huge furnace powering a black box labelled
"Citymapper Development." There's a ramp up to an
opening in the front of the furnace. There are two
grunts with full-body jumpsuits that say "Citymapper
Employee" on them. They are heaving humans into the
furnace.
I'm sure you are a great team, but that was the silly mental image "we need more humans" gave me. ;-)
To be clear for non-Londoners, route 29 has one of the highest crime rates amongst all London bus routes, especially late at night. I'm not sure if it's particularly bad around Camden, although there is probably a higher than average rate of drunken idiots.
Most nightbus experiences start off feeling like fun (yey everyone is in party mood!), become somewhat riddle with a threat of general menace (think A Clockwork Orange) and end up, if you are going far enough, being suicidally depressing because you've sobered up. If you end up falling asleep you will end up in essex, alone and abandoned
Agreed on trains. Train data hasn't been good historically so we only recently have the ability to improve this. Internal debate, but not sure we agree on more frequent options like tubes and buses. We're experimenting with real-time ETA, but its pretty whack, things could jump around, which may be ok for nerds but not normal people. Stay tuned, we're not in any way finished. This is what we work on.
Thank you for your work on CityMapper. However may I respectfully suggest you stop developing for a bit, and go out and actually use it for real, 'in the field'?
Head out the office, pick a spot to get to (say a meeting in another part of town) and see if you can figure out which route is actually quickest. It's seldom the one suggested. Trying to figure out the real trip length for upcoming departures for a number of travel options is a head-wrecker.
I use CityMapper frequently, and I love it. But this 'feature' is infuriating!
> see if you can figure out which route is actually quickest
On this question, there's a balance between possible maximum speed, and reliability. If I want to go to point B, the quickest possible route will often be made by stringing together a serious of improbable connections. For instance, the route could rely on taking three infrequent buses, with little leeway for transfer between one and another, on the assumption that they won't be slowed down by traffic (or just slow customers, stopping more than normal, etc). But if an app sends me along this route, and one of the buses is behind schedule, and I miss the connection, that then becomes a big problem. So there definitely is good sense in prioritizing frequent bus routes to some degree.
But this just means that you should include a margin of error in arrival times when calculating which changes are possible. Doesn't excuse them from using the average time of arrival instead of the actual time of arrival each leg of the journey.
When dealing with (London) tubes and train lines, most of the time it should be possible to indeed work out which route is actually quickest. I agree that buses do complicate things.
I can't even comprehend why you're doing it like that. Do you expect users to write the routes down on a piece of paper?
Even when I know the route, I still (always) check it on my phone the very moment I leave the house, because I expect to get up-to-date information. If I can go to two different bus stops, I don't want to get an average! I just expect you to tell me which bus is coming first — right now.
The only situation when I'm checking a route ahead of time is when I need to know when to leave the house. For this I use Google Maps' "Arrive by" option, so even when I don't take the route immediately, I still expect to see exact times.
You realise that there is some lag in the system, right?
A small lag in data collection and transmission, a small lag in publishing the data via the feed (this is stated as 30s) and TfL cache the data points for 30s. Then you have the ingestion and processing lag that Citymapper introduce before they get it to you and display it on your screen.
You can estimate a lag of greater than 1 minute, pushing 2 minutes if you were unlucky that another CityMapper user nearby potentially requested the same data just before you and you're now seeing TfL's cache.
If you have a bus frequency of 7 minutes we're actually talking a lag of around 28% of the worst case wait time for that bus.
This experience would vary so greatly in different parts of the city (density of CityMapper users), that it would corrode your trust of the info.
Until that lag can be almost eliminated I think they're doing the right thing by choosing values based on average frequency and average wait time. The consistency means that almost everyone is treated to a similar experience, and though it is not highly accurate it is highly consistent. People can, and do, trust a highly consistent experience.
And yes, I live in London and use CityMapper a lot, and I've also played with those TfL feeds and experienced the real world lag in the data for bus/train arrivals, and bike hire data. Those data streams, when you walk out onto the street... they are only an approximation of what you really see outside.
You can cache times as ETA, and even in the worst case when an unexpected change in the schedule needs 2 minutes to propagate, it's still an improvement for all wait times longer than 4 minutes (i.e. all wait times that matter).
I don't see any reason that this lag couldn't be predicted in advance (similarly how NTP is able to synchronize computers' clocks even though there is latency on the network). Or use the last known "most accurate bus arrival time".
As others have said, I would at least like an option for when I do want to take a route immediately. Sometimes I look up routes for later, but usually if I'm using Citymapper it's because I want to go somewhere right now (and am often quite tight for time).
I guess the problem with doing this automatically for queries for journeys starting 'now', is that people will often just look up general journey times with the default options (eg the current time).
Really? Almost everyone I know checks a journey planner app just before setting off. Most of us have a choice of station or stop to set off from, and that's when you need the app most. Also your default search is set to "leaving now".
The thing that's so infuriating is that Tube Deluxe gets this perfectly correct. So I need to keep two apps.
Hey, great job with the app. I use it all the time, but I do have one complaint.
I live, literally, next to the Langdon Park DLR station. Any time I use CM to get directions to the center, it will either send me to the Jubilee line, or to the Central line, which is fine. But, it always sends me to Stratford first, which is in zone 3. Why? I know, it's faster (and cheaper) to either go to Canarry Wharf, and to a 2 minute walk from the DLR station to the tube for the Jubilee line. Or go to Bow Church DLR and walk to Bow Road tube, and then transfer at mile end to central line.
Basically it seems, CM tries to avoid walking as much as possible, even if that means taking a longer&more expensive journey. Can you guys do something about that? If nothing else, an option that let's me specify that I don't mind a bit of walking.
I gave up on Citymapper a while ago. Now I remember why.
Here's how I use Google Maps:
As I am putting on my shoes to go out the door, I look at the event I'm going to in Google Calendar. I click through to the location in Maps, and click directions on the pop-up bubble.
I walk out the door. Five seconds later I'm at the road, and need to know whether to turn left (to the station on the line to Victoria) or right (to the one on the line to London Bridge / Canada Water). I need to know my actual arrival time (barring unexpected problems) for each route, departing NOW.
If I'm doing advance research (when do I need to leave?) I almost always do so using Google Maps on my laptop, not an app on my phone.
If I don't use Google Maps, it's only because I'm using JourneyPlanner.org / PubTran, to deal with those annoying occasions that Google Maps doesn't know about engineering works (e.g., this week: no trains to London Bridge!)
Maybe that's the case but I literally never look at maps except when I'm actually trying to go somewhere. Google maps have the arrive / leave by input that helps with your situation though.
I've also experienced issues where the data provided by Citymapper for a desired journey in London is just plain inefficient when compared with common sense. Often the app will suggest a route which takes an extremely long way round (such as suggesting only one journey at something ridiculous like 85 minutes), seemingly optimising for some unintuitive variable (possibly number of changes or as-the-crow-flies distance? I'm not sure) which makes it unfortunately unusable for me. I was excited to try it out since I find the app well-made and seemingly a more focused version of Google Maps.
However, Google Maps, given the same destination, provides several routes (and allows for explicit choice by the user for their own weighting) where 99% of the time the quickest route is the one that I had thought of beforehand. And this is when selecting Train + Underground in order to compare directly to the equivalent set of results in CM. A shame.
If you represent every edge on the transport graph with a single fixed traversal cost, you can calculate the lowest cost route between two nodes with well known algorithms like (simple) Dijkstra's algorithm or (high performance) Contraction Hierarchies.
When the cost of a route varies with time of day, and the best route changes with time of day, things get quite a bit more complicated.
Not as complicated as you might think. You essentially add time as an extra dimension to your graph, true, but because you're dealing with discrete vehicles instead of a continuously varying function, you can take shortcuts that make that portion of it pretty simple. It's the walk to and from the transit stops, in my experience, that's a PITA to deal with when you're trying to do transit routing.
If you're doing simple Dijkstra and you only want to return a result for a single departure time, you're right that it's not too complicated as you still only have one cost per edge.
If you want to do computations in advance, as you need to for fast algorithms like Contraction Hierarchies, you have a cost-vs-time profile for each edge. Things can get complicated quickly.
I've had really mixed experiences with the time estimates in London. Sometimes it will specifically say that a train/bus will arrive at 17:00, 17:10, 17:20 etc, but sometimes it will just say "every 10 minutes". I haven't worked out the reason for it, I've seen both versions on exactly the same services before.
That's pretty much my only complaint about an otherwise perfect app though, but you're right that those little errors can add up to be quite inconvenient over a long or rushed journey.
So, for example, if your train takes 10 minutes to reach your destination, leaves your local station every 30 minutes and you've just missed one, CityMapper will show an estimated journey time as 25 minutes (avg wait 15 minutes + 10 min journey), instead of the actual 39.
On multi-train journeys like many Londoners have, that error compounds quickly, and it can make choosing the fastest route near-impossible. And I don't know why they do it, because they have all the timetable data (including live timetables).