london Archives

December 3, 2007

Congestion Pricing is a Technology, Remember?

In many ways London's system for Congestion Pricing should be model for New York, but in other ways it really isn't. The most obvious way that it isn't is in the actual technology proposed to do the job. Yes there are cameras and computers involved, that's sort of where the similarity ends.

Specifically, in the UK tradition, all of the cameras relay a full video feed to some central processing location. Not only is this absurdly costly (think fibre!!) but it allows for plenty of privacy invasion by anyone who has access to the cameras' feeds. The proposition for New York is very different. The proposition is much cheaper and seems to all but eliminate the possibility of using the cameras for anything but looking at license plates. That's because the cameras would be equipped with enough smarts to know when to snap a photo, and only that still image would be sent to be processed. If you don't believe me, read this excerpt from IBM's recently released proposal:

A worst case analysis shows that for a very busy lane, with one thousand vehicles passing the detection equipment every hour and forced to send two 100kB images for each vehicle, the bandwidth requirement is a mere 57kB/s. This is within the capacity of wireless networks today, but is not the optimal solution approach.

A more realistic case, in which 50% of vehicles are equipped with an E-ZPass tag, 90% of the remaining license plates are read with a sufficient confidence at roadside and 80% of charges are paid in a timely manner, leads to a bandwidth requirement of 8kB/s. A very busy, six-lane detection point would thus be well within the capacity of NYCWiN, even without local reinforcement of the wireless network.

We estimate that, with our proposed solution approach to vehicle detection at the edge of the network and given the estimated amount of traffic in the city, the average local bandwidth requirement across the system will be on the order of less than 1kB/s per lane, and the overall load on the backbone of the wireless network will be small.

More generally speaking, I think it suffices to say that Congestion Pricing uses technology, and as we know technology only gets better and cheaper over time, so we can be sure that NYC's Congestion Pricing technology will be much better and cheaper than London's.

Now, if only somebody would only explain this to all the privacy freaks and civil libertarians that are making this process so painful...

November 6, 2008

You Know What I Did Last Summer?

I spent 10 weeks last Summer as an intern on the strategy team of Transport for London's (TfL) London Rail division. This part of TfL is responsible for the London Overground, the Docklands Light Railway, and Tramlink, is the presumptive operator of Crossrail (if and when...), and serves as TfL's interface with the National Rail network. My general task was to help London Rail start to make use of the oceans of data spewing out of the Oyster smartcard ticketing system, but I spent the bulk of my time working on a project that came to be titled Oyster-Based Performance Metrics for the London Overground. I've posted my final report and slides and outline for the presentation I gave to TfL executive management.

Rather than try to explain the work, I've just cut and pasted the executive summary from the report and included some of my favorite figures (with no explanation). It's not a terrible paraphrasing, but if there is a lot of really good meat in the document if you are bored and hungry. Snooze on...

The London Overground is a pre-existing rail service in London whose operating responsibility and revenue risk were recently granted to Transport for London (TfL). Here we discuss the prospect of using data from the Oyster smartcard ticketing system to evaluate the performance of the London Overground explicitly from a passenger’s perspective.

The core idea behind our approach is to directly measure end-to-end individual journey times by taking the difference between entry and exit transactions stored by the Oyster system. The focus of this study is Excess Journey Time (EJT), calculated on a trip-by-trip basis as the difference between the observed journey time and some standard. In this case, the standard is determined for each trip with reference to published timetables, indicating how long the trip should have taken under right-time operations. A positive EJT indicates that the journey took longer than was expected.

Excess Journey Time is interpreted as the delay experienced by passengers as a result of services not running precisely to schedule. The distribution of EJT indicates reliability. We validate these interpretations using a detailed graphical analysis, and then aggregate them to the line and network level over a variety of time periods. Our analysis is conducted on large samples of Oyster data covering several months and millions of Overground trips in 2007.

At the aggregate level, relative values of Excess Journey Time are largely in line with expectations. The North London Line has the highest average Excess Journey Time of all lines on the London Overground, around 3 minutes, and the widest distributions (i.e. least passenger reliability). On all lines, there is significant day-to-day variability of Excess Journey Time. For the whole London Overground, and for the North London Line in particular, Excess Journey Time is worst in the AM and PM Peak timebands.

The current performance regime for the London Overground is the Public Performance Measure (PPM), which measures the fraction of scheduled vehicle trips arriving at their destinations fewer than five minutes late. Over time, EJT shows a strong correlation to PPM. There is clear additional variation in EJT, indicating that it captures certain information about passenger experiences that PPM does not. This variation tends to increase as PPM decreases, particularly in the AM and PM peak timebands, which suggests that the effectiveness of PPM as a measure of the passenger experience decreases as service deteriorates.

Another quantity of interest derivable from Oyster data is the time between passenger arrival at the station and the scheduled departure of the following train. The spread of this distribution of this quantity indicates the degree to which passengers arrive randomly (i.e. "turn up and go") rather than time their arrivals according to schedules. We have found that on the North London Line, especially during the AM, interpeak, and PM peak periods, passengers tend to arrive randomly. This is apparently in contrast to conventional wisdom for National Rail services, and has distinct implications for crowding levels and timetabling practice. In an appendix to this report we look at this in detail, and recommend that even headways be prioritized in timetabling the North London Line.

The Overground is, by design, part of a larger integrated multimodal network. Oyster data, by nature, is somewhat ambiguous in representing passenger trips on such a network that involve transfers or multiple routing options. This poses certain problems to our methodology, but also presents the opportunity to quantify and understand the experience of passengers across the entire network. We discuss these problems, potential solutions, and opportunities at length, as well as other applications for this methodology, and future research directions.

We have concluded that Oyster-based metrics are effective for monitoring and identifying problems as experienced by passengers on the London Overground. They may be even more effective for use across the whole of London's public transport network, particularly as Oyster is in the process of being rolled out to all National Rail services in the Greater London Area.

About london

This page contains an archive of all entries posted to Frumination in the london category. They are listed from oldest to newest.

hip-hop is the previous category.

me is the next category.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.