Workarounds in Public Transit Modelling with EMME and Perl

1. Workarounds in Public Transit Modelling with EMME and Perl Matt Carlson & John Armstrong 12th October 2007 21st 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: • An entire network needs to be transposed (such as to create a PM network from an AM)? • 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.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 • Example: Manchester-London • 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

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 • Extract subset of ‘relevant’ trains from CIF; • For ‘relevant’ trains extract the subset of ‘relevant’ nodes required; • Look up ‘relevant’ nodes dependent on direction and TOC; • Subtract journey times between ‘relevant’ nodes; • Aggregation of identical lines; • Allocate a Railplan service code to each line; • Assign Vehicle Types; • Export in Railplan format; • Import to EMME • 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 CarlsonArup13 Fitzroy StreetLondonW1T 4BQUK+44 20 7755 4114matt.carlson@arup.comwww.arup.comlinkedin.com/in/mattcarlson