Workarounds in Public Transit Modelling with EMME and Perl Matt Carlson & John Armstrong 12 th October st International EMME Conference, Toronto

Contents Introduction to need for workarounds Case Studies EMME Wish Lists

Introduction EMME – Established in the UK in large public transport models: Railplan (Transport for London) Docklands Public Transport Model (Docklands Light Railway, London) PLANET (Department for Transport) However, there are cases where additional tools are needed in addition to EMME: Processing electronic timetable data for rail services input to EMME ‘Cleaning up’ EMME outputs of transit lines Reversing of EMME transit lines Hence scripting languages used

Scripting Languages AWK used with EMME/2 for decades Python used increasingly with Emme 3 Perl used recently in Arup Doesn’t matter too much: just need to get the job done

Case Study 1 – Exporting EMME Transit Lines No matter how ‘readable’ the data is when imported to EMME, it is exported like this… Awkward spacing No ‘clues’ about nodes (multiple 6-digit nodes at stations don’t easily convert to unique and readable 4 character labels)

Step 1 Remove carriage returns where us3 values are ‘orphaned’ on to new lines

Step 2 Read all elements from the tidier file… …and re-export desired data with Names

Wish List 1 To be able to choose which data is exported by EMME, including Database attributes

Case Study 2 – Reversing Transit Lines INRO has included a facility in the network editor for reversing lines interactively, but what if: 1.An entire network needs to be transposed (such as to create a PM network from an AM)? 2.The reverse journeys required different nodes? Use a script to reverse the lines

Example Network – DLR

Example Network (Inset) Note separate nodes by direction To enable line-to-line interchange movements at complex stations

Reverse Lines Use a script to read a ‘tidied’ output: Input all values into an array Export in reverse order Look up opposite node

Wish List 2 Splitting of stations into so many nodes would be un-necessary if line-to-line transfer information was more easily extracted Currently there is a need to re-code the network with one node per line and extract the line-to-line data (as transfer.mac* and transfer.awk*) Perhaps if something similar to auto turn movements for transit were output at the end of an assignment… * See transfer.zip by Heinz Spiess at

Case Study 3 – Processing Transit Line Data Railplan Model (Rail, Metro, Tram, Bus) Rail is more complicated: Stopping patterns vary, Trains join and split, Timetables change more frequently Other modes simple by comparison Usually headways only difference Need an automated approach

Data Sources 1 – Network Rail CIF Network Rail use a ‘Common Interface Format’ (CIF) This contains all rail movements in a given timetable period including Freight Trains Empty stock movements 3 Million+ Lines Cryptic Format Example: Manchester-London

Data Sources 2 – Issues Very little vehicle information E.g. EMU 125mph – data suited to train pathing not passenger use No capacity information (4/8/12 car???) Need to convert to multiple station nodes Need to convert to transit line codes

Methods - Software Perl is used Perl = Practical Extraction and Reporting Language Open Source Cross Platform

Methods - Overview 1.Extract subset of ‘relevant’ trains from CIF; 2.For ‘relevant’ trains extract the subset of ‘relevant’ nodes required; 3.Look up ‘relevant’ nodes dependent on direction and TOC; 4.Subtract journey times between ‘relevant’ nodes; 5.Aggregation of identical lines; 6.Allocate a Railplan service code to each line; 7.Assign Vehicle Types; 8.Export in Railplan format; 9.Import to EMME 10.Harmonise times & Fix Join-Split

1 - Extract subset of ‘relevant’ trains from CIF Is a passenger service Not freight or empty stock Is in a relevant TOC Runs in the south east of the UK Is within the correct time period Passes most important station between 7-10am / 10am-4pm

2 - For ‘relevant’ trains extract the subset of ‘relevant’ nodes required Skeletal nature of model means stops near edge of model are ignored

3 - Look up ‘relevant’ nodes dependent on direction and TOC Stations are often split into separate nodes by direction Note: 4 nodes at Raynes Park 7 nodes at Waterloo

4 - Subtract journey times between ‘relevant’ nodes The journey time is stored in us3 This avoids problems with times for ‘irrelevant’ nodes i.e. subtract the times between modelled nodes after discarding ‘irrelevant’ nodes

5 - Aggregation of identical lines Lines with identical stopping patterns are aggregated This includes: noboa noali

6 - Allocate a Railplan service code to each line Lines are named according to TOC, O-D Pair, Direction

7 - Assign Vehicle Types Vehicles are assigned according to: TOC Timetabled Type Speed

8 - Export in Railplan format Note: Non-interpolated times

9 - Import to EMME Interpolate us3 times with splitime.mac Reset noboa and noali flags from us1 and us2 This allows splitime to work with ‘timing points’ as well as stops

10 – Modify in EMME Harmonise times for common stop-stop sections Fix join-split times

10a – Harmonise Times All Stop-to-Stop pairs are consistent and rounded to an integer us3 Including common Stop-to-Stop pairs on different routes

10b – Fix Join-Split Times Sections ‘x’ minutes long where trains stop at a dummy node are: x-0.01 minutes on main leg 0.01 minutes on dummy leg

Transit Lines are Output (as Case Study 1) Transit Lines exported: Node Names shown for clarity us3 times interpolated and ‘bucket-rounded’ to 2 d.p. Un-necessary info (us1, us2) removed from file.

Wish List 3 To model join-split trains as a single line, e.g. Y-shape To be able to view transit lines in terms of stop-stop times, not node-node times: Similar to configurable attributes Underlying segment data could still be stored as now

Conclusions Various tedious or tricky operations are made possible by use of a scripting language Learning a scripting language pays off very quickly

Matt Carlson Arup 13 Fitzroy Street London W1T 4BQ UK linkedin.com/in/mattcarlson linkedin.com/in/mattcarlson