Remember this map?
I used it in the earliest days of this blog, and it's in almost every presentation I do. It's from a tool that allows you to select a location in a city and see blobs (technically isochrones) showing the area you can get to in a fixed amount of time using transit plus walking. This one is for 9:00 am and the three shades of blue represent travel times of 15, 30, or 45 minutes. In essence, the software takes the point you select and runs the equivalent of Google Transit trip planning searches to find a points where the travel time crosses the threshold; these become the boundaries of the blobs. (For details behind this crude summary, see Aaron Antrim's comment on this post.)
I call this a map of your freedom. It's useful for two potentially transformative purposes:
- Helping people and organizations understand the transit consequences of where they choose to locate, and thus to take more responsbility for those consequences. This, over time, can help people who value good transit to locate where transit access is good — something that's very hard to discern from a typical bus map but that becomes very obvious here. You can even assess access to specific things that you value, based on exactly where the blobs are.
- Helping people visualise the benefit of transit — access to your city — as a freedom, and thus to understand more clearly what transit does for them. It broadens the narrow notion of travel time – which is often understood for only one typical trip — into a picture of your possibilities as a transit rider. The percentage of a city's resources (jobs, housing, retail etc) that is in the blobs for a particular location could also form the basis for a meaningful Transit Score that could replace the technologically biased scores now used by WalkScore.com.
The original tool is a beta buried deep in WalkScore's archives. It's basic and very, very slow.
The other main alternative is mapnificent.net, by Stefan Wehrmeyer. Available for many cities, Mapnificent.net looks good …
… except that it contains two fatal assumptions:
- Initial wait time is excluded.
- Some timing of transfers is assumed, based on the author's experiences in Europe. So he uses an average transfer wait time of 1/3 of the headway instead of 1/2 of the headway, which would be appropriate for random transfers.
Here's the problem. Both assumptions mean that Mapnificent's assumptions undervalue frequency and overvalue vehicle speed. Since this conceptual bias is already very, very common (see Chapter 3 of my book), Mapnificent is seriously misleading in a way that can be really unhelpful. For cities that I know, especially area with lower frequency service, Mapnificent wildly overstates the convenience of transit, and fails to show how locating on frequent service will get you better access to the city.
In my network design course we talk about this. When figuring travel times in the course, I insist on using 1/2 of the headway as the intial wait time and the same as the transfer time (unless there's a pulse) so that frequencies weigh heavily into true travel times, as they do in life. This sometimes sounds silly: If a route runs once an hour does that really mean I wait an average of 30 minutes? Or do I just build my life around the schedule? I view the two as the same thing, really. We're not describing literal waiting so much as time when you're in the wrong place. We're describing the difference between when you need to arrive and when you can actually arrive. This could take the form of arriving at work 29 minutes earlier than your shift starts — consistently, every day. Effectively, you end up waiting at your destination.
So there are a range of judgment calls to be made in designing these things, but it's worth getting it right because the potential utility of this tool is so significant. The good news: I'm involved with people who are working on something better. Stay tuned!
You might be interested in looking at the travel planner system we have in Helsinki. First, the route planner can be found here http://www.reittiopas.fi/en/.
The travel time map tool is unfortunately only in Finnish, but I’m sure you can get the gist of it, if you just try it. It calculates the areas that you can reach from a given address in different times.
If you want to play a bit more, the following will help.
Asetukset = settings: here you can set the following things:
Kartalla esitettävä kulkutapa: (The travel mode shown in map)
Joukkoliikenne = public transport
Kävely = walking
Pyöräily = cycling
Kaikkien kolmen vertailu = comparing the three
Asukas- ja työpaikkatiedot: = number of residents / workers
Älä näytä = Don’t show
Näytä asukasluku = Show number of residents
Näytä työntekijämäärä = Show number of workers
Vain vaihdottomat yhteydet = only direct connections
The frequency vs. speed preference is interesting to me, and I think maybe it depends on how far away you are from your destination.
I live in a place with access to heavy rail rapid transit as well as commuter rail, both of which get close to my office in the CBD. The rapid transit is about 45-50 minutes of in-vehicle travel time, but comes at a decent headway, maybe every 10 minutes or so during rush hours. The commuter rail makes the trip in 20-25 minutes. Headways vary by station, and are somewhat irregular (i.e., not clockface), but near me it can be about 30 minutes between trains in rush hours, and hourly for most of the rest of the day.
So I’m a regular rider of the commuter rail, and have no problem planning my work schedule around it. Even if I’m out late in the city and the trains are running hourly, I’ll plan my departure from a destination around the commuter rail schedule rather than spend up to an hour getting home on the rapid transit. Basically, because I’m 12 miles from downtown, speed is much more important to me than frequency. If I were closer, I can see how frequency might be better. But I’m not sure it makes sense to always value one over the other. In an ideal network, you want both high speed options and high frequency options, which is what I have I suppose. The only thing better would be a high frequency/high speed option, but it’s hard to accumulate enough ridership on a limited stop/high speed service to justify the frequency.
There’s one for NYC that works pretty well, but it’s based on MTA subway alone; no bus, PATH, commuter rail, ferry, etc: http://www.triptropnyc.com
It doesn’t change the point you’re making, but the WalkScore tool, then and now, doesn’t include AC Transit, which means much more of the East Bay is accessible than what is actually shown.
@John I imagine that frequency multiplies in importance when you have to make a connection, at least if schedules aren’t coordinated. For example, if I take the bus to work, I have to transfer. The first bus runs every 15 minutes, and the second every 30, but the schedules line up such that there’s a 1 or 2 minute connection time from the one to the other. If it all works out, I can get to work in 35 minutes door to door, which is okay for a trip of about 5 miles. However, there’s a 50% chance that the first bus is late, and I miss the transfer, which means that the trip now takes over an hour. So I have to take the earlier bus, which means that the trip is a consistent 50 minutes (even though only 20 of those minutes are on the bus). And that’s how even with a vehicle top speed of 35 mph and average speed of 15 mph, average trip speed becomes a mere 6.6 mph.
There’s also a great new map for the entire UK made by MySociety.org using the same technique: http://property.mapumental.com/map/AB101AA-a-0900/468bc61d#t23
My bad. I forgot the other link from my comment above.
Here it is: http://mak.hsl.fi/
@ John: I believe Jarrett’s point is not that frequency is more important than speed but that both speed and frequency influence total travel time. So, just as it wouldn’t make sense not to consider speed when deciding where and how you travel, it is a mistake not to consider frequency.
The example you point out only shows that longer distance travelers will put up with lower frequencies, if the total travel time can be made up in speed. In your example, even at hourly headways your total travel time would not be significantly faster using rapid transit, so you wait for the commuter rail.
Commuter rail wait time 30 min
Commuter rail travel time 25 min
Total travel time 55 min
Rapid transit wait time: 5 min
Rapid transit travel time: 50 min
Total travel time: 55
If however, the commuter rail frequency was every 2 hours, I’d be willing to bet, you would take Rapid Transit. So you see, it is not the speed alone that attracts you to commuter rail, but the combination of frequency and speed.
Jarrett’s issue with the Mapnificent algorithm is that, as you can appreciate, it is simply wrong to say the travel time from your home to downtown is 25 minutes on commuter rail.
Frequency determines wait times, which may sometimes be at the end of the trip. Nice. I had never thought of it in that way.
Ok, the technical description of how these travel time maps are generated is not fully accurate.
“The software basically takes the point you select and runs Google Transit trip planning searches for areas nearby, until it gets out to a point where the travel time crosses the threshold.”
“The second assumption arises from the fact that rather than making a huge number of Google trip planning queries, Mapnificent.net just gets frequencies and travel times from Google, and then assembles the trip itself — presumably because this is much faster to compute.”
Mapnificent and Walk Score do not use Google Maps for generating travel times. Both the Walk Score and Mapnificent ingest General Transit Feed Specification (GTFS) data, and use that data in their own routing software that builds the travel time maps. Google Maps is just used as a display canvas. For more information about how Mapnificent works, check out Stefan’s blog: http://blog.stefanwehrmeyer.com/post/1448498820/a-mapnificent-world
Here’s a bit more. Google Transit and GTFS are very often conflated. This is in part because the General Transit Feed Spec was originally called the Google Transit Feed Spec after Google released the specification. Now there is a lot of other software that incorporates this data specification in some way. However, some agencies choose to make their GTFS data only available to Google, which prevents the availability useful tools like these. So, it’s important that people understand that open data enables this sort of innovation.
For more on the concept of open GTFS, and many other tools and efforts surrounding this data, see this report: http://bit.ly/leverage-gtfs
This is another tool that produces isochrones in a similar fashion, however I do not think there are sites where it is installed on a server and ready for us all to use (you have to download the software and install it on a server): http://analyst.opentripplanner.org/
@Aaronrp, The earlier beta Walk Score Transit Time Map doesn’t include AC Transit, but the more recent Apartment Search does: http://walk.sc/10rhwMJ
Also, Google Hotel Finder (http://www.google.com/hotelfinder) has a neat isochrone feature to find hotel locations that are convenient for transit-using guests. I believe this works anywhere transit directions are implemented in Google Maps — this one is likely more closely linked to Google Transit.
If anyone is curious, the mother-load of open GTFS data is here: http://www.gtfs-data-exchange.com/agencies
@anonymouse and stephen,
Agree with all you said.
Thanks for Aaron Antrim’s comment. The second passage that he quotes has been deleted in response to his input, and the first was edited with a reference to the comment.
Hi Jarrett. Just re-read this as your latest post related to GTFS. Couldn’t find one specifically on GTFS though. Did I miss one? Also any update on your last sentence in the article?
The good news: I’m involved with people who are working on something better. Stay tuned!