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

2. Contents Introduction to need for workarounds Case Studies EMME Wish Lists

3. 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

4. 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

5. 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)

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

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

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

9. 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

10. Example Network – DLR

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

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

13. 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 http://www.inro.ca/en/download/macros.phphttp://www.inro.ca/en/download/macros.php

14. 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

15. 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

16. 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

17. Methods - Software Perl is used Perl = Practical Extraction and Reporting Language Open Source Cross Platform www.perl.org

18. 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

19. 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

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

21. 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

22. 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

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

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

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

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

27. 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

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

29. 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

30. 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

31. 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.

32. 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

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

34. Matt Carlson Arup 13 Fitzroy Street London W1T 4BQ UK +44 20 7755 4114 matt.carlson@arup.com www.arup.com linkedin.com/in/mattcarlson matt.carlson@arup.com www.arup.com linkedin.com/in/mattcarlson