My plan is to generate a set of LSOA-to-LSOA matrices covering:
a. A drive-time matrix (this won't take account of variation incongestion or anything like that, so nominal departure/arrival time are largely irrelevant).
b. Travel-time matrices based on a small (3-5?) set of depart-after times.
c. Travel-plus-waiting-time matrices based on a small set (again 3-5?) of arrive-by times.
For the sake of easier explanation, I'm going to use the following LSOAs as examples:
- Holyhead Town (W01000016), approx postcode LL65 1UR
- Gwynedd 002A (W01000064), approx postcode LL57 2BQ
For example, going from LL65 1UR to LL57 2BQ and departing after 09:00 on a Tuesday morning, the first public transport trip involves:
- Setting off from LL65 1UR at 09:14 for Holyhead Railway Station
- Getting the 09:23 train to Bangor, arriving at 10:01
- Walking the 20 minutes to LL57 2BQ, arriving at 10:21
The travel time lasts from 09:14 to 10:21, totalling 1h07m. The wait between 09:00 and 09:14 doesn't matter (but any waits for transfers would, to be clear.) (Edit: Actually this might be trickier to handle than I think and it might have to be 1h21m for now...)
These matrices would be intended to reflect more clearly on issues like frequency of public transport services, and how these affect accessing appointments.
For example, the latest possible trip from LL65 1UR to LL57 2BQ, arriving by 11:00 on a Tuesday morning, is the same trip described above.
However, this trip involves an enforced wait from 10:21 to 11:00 at the other end. The total travel-plus-waiting-time lasts from 09:14 to 11:00, totalling 1h46m.
A further complication is that (using my current toolset) I can probably only look at departure times in blocks without the computational power required being excessive. For example, I might only be able to look in 15 minute blocks, in which case I might conclude that you need to set out at 09:00 from LL65 1UR to get to LL57 2BQ by 11:00 - totalling 2h00m.
Each matrix would be made available as a CSV, in the following arrangement:
| from_id | W01000002 | W01000003 | W01000004 | W01000005 | W01000006 |
|---|---|---|---|---|---|
| W01000001 | 50 | 127 | 126 | 69 | 72 |
with LSOA origins as rows, LSOA destinations as columns, and durations (in minutes) in each cell.
This arrangement has the advantage of being relatively compact with early examples coming in at around 12MiB
(versus easily 5x that for a 'long' normalised arrangement with from_id, to_id and duration_minute columns).
It has the disadvantage that it's not very legible without further documentation, but I think this a relatively minor concern.
I would also make available more detailed files (including departure and arrival times, for example) in single-R-object .rds format.
DfT Travel Time Statistics have attempted to be representative of the 'morning peak' ('requiring the journey to be completed between 7 and 10am') on a Tuesday, sometimes specifically in the second week of October ('since this provides a fairly typical week, unaffected by major national holidays, school holidays or other seasonal effects').
I think this seems like a good starting point, looking at departures after 07:00, for example (although I'll probably permit journeys longer than 3 hours), and then some others later in the day.
I think it's perhaps less useful for thinking about appointments and arrive-by times, and I've been thinking about how to spread these through the day, e.g. 0830, 1100, 1530, 1800 or something like that. I'm not sure whether to offset these by 5 minutes (e.g. 1105) and whether this makes any sense in terms of thinking about tolerably late arrivals.
Any thoughts on what might help guide the selection of sensible time points would be very gratefully received!
I'd also like to do a couple of depart-after and arrive-by points on a Saturday.