Chris Lightfoot, mySociety <chris@mysociety.org>
This work was funded and supported by the Department for Transport.
(See also: main report.)
Clearly the travel-time for a particular journey is a function of the origin and destination points, the time of travel (whether of departure or arrival), the modes used, and of decisions made by the traveller (for instance whether to prefer faster or cheaper journeys). Our travel-time maps can only conveniently display a function of one point (the origin or destination point), so we need to fix the other arguments so that (a) it describes journey times which are useful to users in some context, and (b) it is practical to compute.
We evaluate the travel-time function using published the following journey planners:
In each case custom programs were written to drive the journey planner. For RailPlanner, this took the form of a small Microsoft Windows program which simulates filling of the text fields for origin, destination and departure time in the RailPlanner application window, simulates clicking of the button to start a search, and extracts the results using the Windows debugging API. This allows queries for routes between rail stations to be computed quickly and conveniently; because it runs on the local machine, the search is fairly fast, and a few minutes is enough to compute the journey time from a given starting location to all other railway stations in the country.
In the other two cases a conventional web "scraper" was written using the WWW::Mechanize perl extension. In these cases we ask for routes between postcodes, rather than between named bus stops, tube stations, etc. We chose this approach because, while there is a standard dictionary of bus stop etc. names in the National Public Transport Access Node database, we were not confident that those names would be interpreted unambiguously by the journey planner websites. By contrast, postcodes are completely unambiguous and since most bus stops etc. are in built-up areas, nearby postcodes can be used as placeholders for their locations; we offset travel time by the assumed walking distance from the origin postcode to the nearby interchange point. Admittedly this is not ideal!
The RailPlanner scraper is very fast: it can find the travel times from a single station to all the other (c. 2,800) stations in Great Britain in two or three minutes on a modest desktop PC. The web scrapers are much slower, partly because they have to call out over the network, partly because the multimodal route planning problem is much harder than for rail alone, and partly because those services are of course heavily used by people for real journey planning rather than experiments. For TransportDirect query times of tens of seconds for individual journeys are common. We limited the rate at which we sent queries to ensure that there was no adverse effect on the services for other users.
Most journeys don't start and finish at railway stations or bus stops, so we need to be able to calculate journey times between arbitrary points; these are used to estimate the time taken to get from an origin to join a public transport service, and from its destination to the final destination point.
In the case of the railway travel-times, we did this by assuming that users would continue from the destination station to their final destination by taxi, taking ten minutes to change mode. Taxi journey times were assumed to be a simple function of the distance travelled—we ignore the effects of the road network, and of traffic. To form an estimate of this model we simulated a large number of car journeys using off-the-shelf route-planning software, and then fit a simple function to the journey time. For long distances we find that the cross-country speed is about 66km/h; while that seems slow, bear in mind that the distance in question is the as-the-crow-flies distance. We assume that people will tolerate a taxi journey of up to one hour, though obviously this is an arbitrary choice.
In the multimodal case, TransportDirect and the TfL journey planners will actually compute travel-times for journeys starting and ending at arbitrary postcodes. However, it's much more efficient to restrict our search to journeys starting at bus stops, tube stations etc., and then to compute travel times from arbitrary locations to the appropriate bus stop. In this case we assume that the user will begin their journey on foot, travelling at 1m/s cross-country; this matches the assumption made by the journey planner for the time to (e.g.) walk between nearby bus stops. We let the journey planner site determine the time taken for the final component of the journey (typically, from a nearby bus stop to the fixed final destination), since there is no disadvantage to doing so. We assume that people will tolerate a walk of up to 15 minutes at the start of their journey.
Therefore, in each case, we compute the maps as follows:
This generates a grid of points at which we know the journey time, or know that no journey is possible. From this it is trivial to draw a map where each point is coloured according to journey time, or uncoloured if no journey is possible. We choose the colours according to a standard scale, but adjust the colours using histogram equalisation so that each colour covers approximately the same area of map.
Drawing the contours, which are essential to making the map comprehensible, is slightly more subtle, because the function to contour (the travel-time) is not actually defined everywhere in the region of interest. We fix this up by extrapolating the values of the travel time outside the domain of the function, contouring the extrapolated function, and then clipping the contours agains the domain of the function. Our extrapolation is a solution to Laplace's equation, fixing its value to the value of the travel-time on the boundary of its domain, and fixing the normal derivative at zero on the boundary of the region of interest. Though there is no real justification for this approach it produces acceptable results.
For the national rail travel maps, the coloured fields and contours were generated using the University of Hawaii's Generic Mapping Tools, which generate PostScript output; this was then manually composited with raster base-map data in an image-processing program. Unfortunately it is hard to produce satisfactory results by this means, so for the other maps a custom tool was developed to plot and contour maps into raster graphics files which were therefore correctly aligned with the base map data. The overlays are rendered with alpha of around 50% (adjusted by eye for contrast with the different base maps).
If you'd like a copy of the custom software we wrote, or if you have any other questions or comments, please email me at chris@mysociety.org. Our software is available under the terms of the GNU Affero GPL.
Excludes timetable data supplied through RailPlanner and the journey planning websites.
These data were kindly supplied by agreement with the Department for Transport.