workarounds in public transit modelling with emme and perl n.
Skip this Video
Loading SlideShow in 5 Seconds..
Workarounds in Public Transit Modelling with EMME and Perl PowerPoint Presentation
Download Presentation
Workarounds in Public Transit Modelling with EMME and Perl

Loading in 2 Seconds...

play fullscreen
1 / 34

Workarounds in Public Transit Modelling with EMME and Perl - PowerPoint PPT Presentation

  • Uploaded on

Workarounds in Public Transit Modelling with EMME and Perl. Matt Carlson & John Armstrong 12 th October 2007 21 st International EMME Conference, Toronto. Contents. Introduction to need for workarounds Case Studies EMME Wish Lists. Introduction.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Workarounds in Public Transit Modelling with EMME and Perl' - maylin

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
workarounds in public transit modelling with emme and perl

Workarounds in Public Transit Modelling with EMME and Perl

Matt Carlson & John Armstrong

12th October 2007

21st International EMME Conference, Toronto

  • Introduction to need for workarounds
  • Case Studies
  • EMME Wish Lists
  • 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
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
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
Step 1
  • Remove carriage returns where us3 values are ‘orphaned’ on to new lines
step 2
Step 2
  • Read all elements from the tidier file…
  • …and re-export desired data with Names
wish list 1
Wish List 1
  • To be able to choose which data is exported by EMME, including Database attributes
case study 2 reversing transit lines
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

example network inset
Example Network (Inset)
  • Note separate nodes by direction
    • To enable line-to-line interchange movements at complex stations
reverse lines
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
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 by Heinz Spiess at

case study 3 processing transit line data
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
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
data sources 2 issues
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
Methods - Software
  • Perl is used
  • Perl = Practical Extraction and Reporting Language
  • Open Source
  • Cross Platform

methods overview
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
1 extract subset of relevant trains from cif
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
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
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
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
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
6 - Allocate a Railplan service code to each line
  • Lines are named according to TOC, O-D Pair, Direction
7 assign vehicle types
7 - Assign Vehicle Types
  • Vehicles are assigned according to:
    • TOC
    • Timetabled Type
    • Speed
8 export in railplan format
8 - Export in Railplan format
  • Note: Non-interpolated times
9 import to emme
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
10 – Modify in EMME
  • Harmonise times for common stop-stop sections
  • Fix join-split times
10a harmonise 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
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 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
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
  • Various tedious or tricky operations are made possible by use of a scripting language
  • Learning a scripting language pays off very quickly

Matt CarlsonArup13 Fitzroy StreetLondonW1T 4BQUK+44 20 7755