Eglinton + Finch LRT vs. Eglinton Subway

Now that I've figured out how to use the TTC schedule data to build maps of transit times in Toronto, I decided that it might be interesting to use my map generator to analyze some of the proposed transit plans for Toronto. Right now there's a lot of controversy over whether the city should build one long subway under Eglinton or build a shorter subway on Eglinton with the savings going towards an LRT on Finch. By generating different maps for these two different transit plans, I could then see for myself the effect of these plans on transit times.

Methodology

I've already described in detail in previous posts how I generated my maps based on the TTC schedules. Simulating the effect of the new transit plans simply involve adding in new fake schedules for the new transit lines. I could create these fake schedules based on the descriptions of stops, headways, and vehicle speeds given in various TTC and Metrolinx reports (many of which I found by digging through Steve Munro's blog). One issue I purposely avoided dealing with though is the fact that existing bus lines are modified whenever new transit lines are introduced. For example, when a new subway is introduced, bus service in the area is drastically reduced because most people will take the subway and the TTC needs the cost savings from eliminating bus service to pay for the operation of the subway. The bus service that is maintained is usually redesigned to funnel as many people as possible to the subway instead of trying to take people directly to their destinations. I considered the possibility of building up new fake routes and schedules for buses near the new transit lines, but it seemed time-consuming and error-prone. Instead, I'll just rely on the reader to use their judgment when interpreting the maps. The maps only show a broad approximation of what might occur if the new transit lines are introduced.

Baseline

Both of these plans will probably take 10 years to finish, so the Spadina subway extension will be done long before these plans will be implemented. Since the Finch LRT is designed to link up with the Spadina extension, it's important to model the Spadina extension in the experiment.

I went to the TTC website for the Spadina subway extension and figured out the approximate positions of the new subway stations. I wasn't sure if I put the stations in the right spots (i.e. beside existing bus stops so that transfers are easy), so to be safe, I changed the simulation to allow people to walk 200m between stops (unlike the 100m limit that I used previously). The different stations were about 1-1.5km apart from each other. Elsewhere on the Yonge-University-Spadina subway line, the subway seemed to be able to travel about 1.2km in about 2 minutes and 15 seconds, so I used that as the time needed to travel between each station on the new extension. I went through the existing schedules for the YUS-subway. Whenever a subway ended its route or began its route at Downsview station, I extended its schedule with stops along the Spadina extension.

Here is a map of the transit times to downtown including the Spadina subway extension:

Transit times to downtown with the Spadina extension
Data, imagery and map information provided by MapQuest,
Open Street Map and contributors, CC-BY-SA. 

This map serves as a baseline that we'll add the different Eglinton transit plans to. Remember that this is a map of the travel times needed to get to Queen or Osgoode stations. It shows an average of the latest times you can leave in order to reach one of those stations before 8:55 and 9:00.

Eglinton Subway

Although I was able to find general information about the Eglinton subway, I have problems finding detailed reports about its route. I was able to find information about all the stops for the Eglinton LRT, so I simply took this list of stops and pruned out those stops that were too close together and hence unlikely to be made into a subway station. The information I could gather from various Metrolinx presentations suggested that the Eglinton subway would go along Eglinton from Black Creek to Kennedy and then follow the route of the Scarborough RT to McCowan. The average speed for route was simulated to be 32 km/h with a 6 minute peak-time headway.

Transit times to downtown with the Spadina extension and the Eglinton subway
Data, imagery and map information provided by MapQuest,
Open Street Map and contributors, CC-BY-SA. 

Eglinton and Finch LRTs

I was able to find information about the Eglinton LRT stops and simply fed those into the model. The Eglinton LRT goes along Eglinton from Jane to Kennedy. The stops from Keele to Laird are underground while the rest are below ground. When moving between underground stations, I modeled the LRT as moving at 32 km/h. At other times, I modeled the LRT as moving as 22km/h. I kept the 6 minute headways the same as with the Eglinton subway. There is talk that this plan might include rebuilding the Scarborough RT as an LRT that goes from Kennedy to Scarborough Town Centre and then to Sheppard, but I couldn't really easily find any reports on this, so it might just be talk.

For the Finch LRT, I was able to find a list of stops in the Finch BRT plan. I modeled the Finch LRT as moving at 22km/h with 5 minute headways.

Transit times to downtown with the Spadina extension, Eglinton LRT, and Finch LRT
Data, imagery and map information provided by MapQuest,
Open Street Map and contributors, CC-BY-SA. 

Commentary

In the end, it turns out it's really hard to tell the difference between these two transit plans. Part of the problem is that my maps only have a new colour for each 20 minute interval, so commute times have to differ by at least 10 minutes before it's even noticeable on the map. Overall though, neither the subway or LRT plans provide large transformative changes compared to the other.

The Eglinton LRT is essentially the same transit line as the Eglinton subway except that it pops up above-ground for a few small sections. These two small sections are rather short and don't have a major effect on commute times. As such, both plans have largely the same effect in the central portions that are underground or near the underground sections.

Both plans provide a significant benefit to people living on Eglinton in the west. They seem to see good improvements in commute times to downtown. The Eglinton LRT extends a little bit further west than the subway, reaching Jane Street instead of ending at Black Creek. The map seems to suggest that this extra stop gives the LRT an additional benefit over the subway for people living west of Jane Street. I'm not sure if the extra 1.5km of LRT actually makes that big a difference in travel times. It might just be an anomaly with the way the LRT schedule lines up with the local bus schedule in the simulation.

Both plans show some small benefit on Eglinton between Yonge and the Don Valley. That area was actually already well served by buses and express buses, so the subway and LRT don't provide huge improvements in commute time to downtown.

The LRT shows some improvements in commute times for people living on Eglinton between the Don Valley and Victoria Park. The subway shows even more improvement for the people who live in that area.

Once you go east of Victoria Park though, things become a little murky. My maps seem to suggest that east of Victoria Park, it's no longer clearcut as to whether you should go downtown via Eglinton or take a bus down to the Bloor Danforth subway and ride that downtown instead. If a subway is built, it looks like it would be slightly better for commuters in the area to take the Eglinton subway over going down to the Bloor Danforth, especially if bus service ends up cut later on to fund the operation of the Eglinton routes. If the LRT is built, then it's probably better to take the bus down to the Bloor-Danforth than to take the LRT.

Once you actually get to Kennedy station though, I think it really becomes a toss-up as to which route you should take. If Metrolinx was overly conservative on the speeds for the Eglinton subway, and the TTC schedule for the Bloor-Danforth subway is optimistic then maybe it makes sense to take the Eglinton. Otherwise, my maps seems to suggest that the Scarborough RT and Bloor-Danforth subway actually already work pretty well together in providing fast service to Scarborough south of the 401. The main benefit of the Eglinton subway was that you wouldn't have to transfer at Kennedy onto the Bloor-Danforth subway not that it would actually get you downtown significantly faster. If the Eglinton LRT is built, then it is definitely better to take the Bloor-Danforth subway downtown than to travel along Eglinton.

One caveat of my discussion so far is that these maps show commute times to downtown. For people in Scarborough traveling to midtown, then there is a noticeable difference between the Eglinton LRT and Eglinton subway (7 extra minutes). For Scarborough people going downtown though, the Eglinton subway doesn't provide a huge benefit.

The main benefit of the Eglinton LRT over the Eglinton subway though is that it frees up money to spend on an LRT along Finch. The maps show that a Finch LRT provides a small improvement in commute times. Compared to existing service, the Spadina subway extension will actually provide a huge benefit in terms of improving commute times to downtown from the Jane and Finch area. The building of an LRT will only provide some modest improvements over the existing bus lines by about 6-7 minutes or so for people living around highway 400. It's not a huge, transformative gain, but that and the more reliable service that comes from having dedicated transit lanes are nice.

Big Picture

To be honest, I was a little disappointed at how little difference there was between the two plans. I was thinking that there would be huge swings in transit times depending on whether you included the full Eglinton subway or Finch LRT. Instead, all this arguing and fury over the plans are mostly about minor 5 minute differences in commute times at very specific points in the city. The colour differences on my maps are so small that I find it hard to tell the difference between actual differences in commute times and calibration problems with my monitor.

Personally, I think the main thing that all this simulation has shown me is how much Toronto's obsession with subways and trains has poisoned its transit planning. The people of Toronto have literally spent decades arguing over how to find the billions of dollars of funding necessary to build new LRTs and subways. Yet small, modest, and cheap improvements that provide real benefits like buying double-decker and articulated buses or setting aside land for future transit corridors have been completely ignored.

I was actually thinking of doing some further simulations comparing the difference between a Sheppard subway extension to Victoria Park vs. a Sheppard LRT, but my current simulation results suggest that it would be pointless to do so. All the experts and consultants already know what the results of these sorts of simulations are. All that bluster and anger are about whether a billion dollars should be spent to let people at Victoria Park get to downtown 10 minutes faster or whether a billion dollars should be more evenly distributed so that people all along Sheppard can zip down Sheppard 5 minutes faster. In the end, I don't think either plan makes a big difference to anyone.

Eglinton Subway vs. Eglinton LRT: Who cares?

So I've spent a day combing through transit reports in order to gather the data needed to simulate the effects of  the Eglinton LRT and Eglinton subway transit plans on commute times to downtown. I generated the necessary maps and am now able to carefully compare their effects.

Conclusion: who cares?

I've had to bring out a microscope to be able tell the difference between these two plans. At maximum zoom, I can detect a subtle difference in shading in a few places. It turns out that neither of these plans are big game changers. Apparently, the laws of physics win out. If you live far away from downtown, then it will take you a long time to commute there. If you live on the edges of the inner suburbs, you may end up saving 10 minutes or so on your one-way commutes. If you live in outer Scarborough, you likely won't see any real difference.

I'll write this up more properly later.

I need to get there by 9ish: Refined Toronto transit time map for the TTC and GO

So I've now refined my program for visualizing the transit times for Toronto. First of all, I've now included GO Transit data in the simulation. As I suspected, it didn't have much of an effect on the results. The distances in Toronto are just to small and GO Transit service is simply too infrequent for it to show up in a simulation of this type. Although taking a GO train might get you downtown faster than riding the bus, because the GO train comes so infrequently, you will likely arrive too early at your destination and end up waiting around. Since this simulation tries to calculate the latest you can leave from a location and still arrive at your destination by 9, the GO train ends up faring poorly. It may be possible that my 100m walk restriction may have resulted in GO train stations being unreachable (since GO Transit is mostly designed for car drivers, most of the stations are surrounded by giant parking lots, and you may have to walk more than 100m from the nearest bus stop to get to the train platform), but I don't really see any evidence of this sort of behaviour on the map, and I think the TTC does try to send buses as close to the platforms as possible. I'm not sure how frequent GO Transit service would have to run before it would show an effect on the map. I'll perhaps have to run a simulation one day to figure that out.

Data, imagery and map information provided by MapQuest,
Open Street Map and contributors, CC-BY-SA.

Another change I made was to discard bus stops from the map that do not have any service between 7am and 9am. These are likely late-night bus stops that don't normally receive service during the day, so it was misleading to include them in the final map of rush hour transit times.

And finally, I no longer simply calculate the best way to get to downtown by 9. I also calculate the best way to get to downtown by 8:55, and I then average the two results. This helps ensure that the data isn't skewed because the schedule shows a perfect transfer of buses (e.g. a bus that only runs every 30 minutes, but just happens to arrive just before another rare bus so that you can get to downtown without waiting--even though in practice, if the timing is just a little bit off, things don't line up and you end up 30 minutes late). By averaging the results for different times, it reduces the magnitude of this effect.

In the end though, the final map visualization looks pretty much the same as the previous one I generated except for the extra GO Transit routes.

I need to be there by 9: Transit times in Toronto aboard the TTC

I recently realized that with all of the open data initiatives pursued by the government, it's possible for amateurs to grab this data and process it themselves. That's, of course, the whole point of open data initiatives, but I hadn't realized until the last few months that that included me.

With my interest in transit, I decided to grab some of the online transit data and see what I could do with it. Since Google has managed to convince everyone to put their transit route and timing information online in the form of GTFS, I decided that a good first step in playing with transit data would be to grab this GTFS feed for the TTC and chart out transit times in the city. The result is below. It shows how early you have to leave from various parts of the city to reach either Queen or Osgoode subway stations before 9am.

Data, imagery and map information provided by MapQuest,
Open Street Map and contributors, CC-BY-SA.

Why downtown during rush hour?
I decided to chart out transit times to downtown during rush hour because this is the most common transit pattern. Most people want to go downtown, and they need to go during rush hour. Even if you do want to go somewhere other than downtown, it's often fastest to still go downtown first because transit systems are usually optimized for taking people to and from downtown the fastest. Of course, the chart isn't representative of off-peak travel times. And sometimes transit systems are overly oriented towards moving people downtown, so it might actually easier to go downtown than to go to the local mall on transit, for example. I was thinking of maybe trying to calculate the transit times to various points in the city, or maybe calculate the transit time needed to reach 70th percentile of the city from any particular location, or maybe the time needed to get 5km away from any location, but doing that would require more complicated coding, and I was feeling lazy, so I opted for the simpler calculation of how long it takes to get downtown.

Simulation Setup
I took the GTFS data for Wednesday, February 15. I took all of the bus stops and transit stations in the data feed and used the transit time information to simulate how long it would take to move between the various stops. In the transit simulation, people are able to walk between stops for a distance of up to 100m at a time at a speed of 4km/h. In reality, some people are willing to much further than 100m if it saves them time, but the 100m restriction prevents the simulation from letting people do things like walk across a highway or across the Don Valley or something. During the simulation, people might walk for a total distance of more than 100m, but they will only walk up to 100m between any two stops. The walk time is simply the time needed to walk the straight line distance between the GPS coordinates of two stops--it doesn't take into consideration buildings in way, terrain, crossing the street, etc.

Weaknesses with the Model
One of the weaknesses of this approach is that it assumes that transit system adheres perfectly to the GTFS data. In reality, buses don't arrive and leave perfectly according to the schedule. People don't try to arrange their bus transfers so that they have exactly 5 seconds to make a transfer. Buses and subways are often late, so people normally would take earlier buses than what the chart shows because they need to ensure there's enough buffer time to make a transfer. There is no sensitivity analysis done on the data--so if I were to run the simulation again but calculate when people would need to leave to get to downtown by 8:55, the calculated transit times might end up being dramatically different. Also, the rule of thumb is that people consider waiting for a transfer to feel like twice as long as actually riding on transit, and that "feel" isn't incorporated into the model either.

Obvious Anomalies in the Map
If you look at the map, you'll notice that there are a lot of purple dots along the Bloor subway line. I suspect that those dots refer to a late-night/early-morning bus that runs when the subway is closed. Due to the 100m walking restriction, those stops can only be "reached" by those overnight buses, but those buses probably don't run during the rush hour since people can just walk a few hundred metres and take the subway instead. I haven't verified this yet.

Previously, I thought that GO Transit doesn't come often enough and that the distances within the city were small enough, that simulating GO Transit wouldn't be useful. But looking at the map now, it looks like that if GO trains come at least twice an hour, then they might provide a benefit for people living at the outer limits of the city, so I might have to incorporate GO data into the simulation later as well.

On the map, you can see the effect of subway lines in the suburbs. Around the subway stations, the transit times are much lower than in the surrounding areas. If you live near a subway station, then you get decent transit times to downtown. Otherwise, you need to take a bus to the station first, which increases your travel time. This effect is particularly prominent on the Sheppard subway and the eastern end of the Bloor subway. Overall, having a subway somewhere in the neighbourhood does seem to improve overall travel times though.

Another annoyance with the way this map is generated is that it's hard to separate the effect of frequency of service from the effect of speed of service. Are poor transit times in some areas caused by infrequent service so people have to wait a long time for transfers or are the times caused by buses moving slowly through congested parts of the city? It's also hard to compare public transit times vs. car times because there's no easy way to calculate how long it takes to drive through the city during rush hour. Oh well, I think it makes a good first step at analyzing some of this public data though.