2014 Sessions

In total, there were 24 fantastic TransportCamp sessions that were proposed during 'agenda setting'. You can take a look at the final agenda matrix.

Our amazing Guest Bloggers created a blog post for each unconference session.  Each post includes all the essential session details, links and a sumamary of all the key points of discussion.

Comments are enabled, so feel free to continue the conversation in the  post or contact the session leader directly.

Stay tuned on Twitter for all the latest updates!

Where’s My Train? The struggle for real time data on the Metro network

Session coverage by guest blogger Alexander Sheko

Session Details 

What goes on behind the communication portal?

What goes on behind the communication portal?

  • Presented by Adam Chandler (Twitter)
  • Location: Room Three
  • Time: Session #2 (11.40am - 12.15pm)
  • Number of Attendees: 18
  • Format: Presentation 

Adam has worked in public transport since 2003, beginning as a customer service officer on the tram network and then learning more about aspects such as timetabling. This has given Adam a focus on passenger needs and the transport experience, including receiving the information you need to be able to travel on public transport.

Adam believes in transparency as a key plank in providing information to passenger - if there is a problem, this should be communicated as soon and as widely as possible so that people can make arrangements.

One problem in this concept of information is that, despite having real time information on trams (TramTracker), no such service exists for Melbourne’s trains. People expect to be able to stand on a platform and be able to see how far away the train is and where it is going. There also needs to be confidence that the people controlling the network from a control centre also have this information in real time and are aware what is going on.

Currently, the location of trains is tracked through signal relays on the train tracks. This is important to know to prevent trains colliding with each other. However, you can only tell whether a train is within a particular “block” - which is anywhere between 50m to 2km. In addition, about 60% of the network is “invisible” to METROL, which is the train control room.

Adam Chandler knows Melbourne's train system from the inside out.

Adam Chandler knows Melbourne's train system from the inside out.

We can’t get realtime data from this “Train Describer System” which is very very outdated - so much so that, to be able to run it on modern computers, a specialist company in Germany was brought on to reverse engineer the original program and be able to run it on an emulator. Despite upgrades, this 60% of the network still can’t be seen by METROL and thus this information cannot be communicated to passengers.

In this majority of the network that cannot be seen by the system, train locations are manually tracked by staff at stations noting train locations and then communicating them to the central control room. This means that information is slow to travel and any delays can take a while to be communicated. There is a lot of potential for error in these parts of the network, meaning confusing information is sometimes passed onto passengers, undermining confidence in the system - and this largely affects outer areas.

Old and obsolete systems mean it is difficult to make use of the information does exist in a form that is useful to passengers e.g. being communicated through a smartphone app. Another problem is that the POTS (Position of Train System), which uses radio tags to track train positions, is very old and these tags are no longer manufactured, meaning that, as they break, they cannot be replaced. These old systems don’t have APIs, meaning that app developers cannot make use of the information that is gathered.

Relying on manual updates means there is a lot of room for error e.g. if the staff member responsible for manually updating the “health board” (showing whether lines have good service or delays) is busy or has gone home, this information will not be communicated.

There were some attempts to consolidate what information is available in a way that is useful to passengers (CLEO and HERMES) but there is a lot of work to be done still and not enough funding has been provided.

Adam believes the solution is working backwards from what the customer needs and expectations are, and then designing systems to be able to provide this information. We should also be sharing information in internationally accepted standards, so that data can be used by services such as Google Transit.

People really want to know about disruptions and how long it is going to take them to get to their destination. We need a stable and real-time data source for Melbourne’s trains. This needs to be on the agenda for new train projects, such as when new radio systems are being installed in trains, or when there are major projects such the Dandenong line upgrade.

Adam says it is possible to “do” real-time data now and reasonably cheaply, making use of existing systems at times. However, this is often a low priority for decision makers such as politicians, perhaps because it is in the “too hard” basket or because it doesn’t feature in their visions for transport. Therefore, part of the solution could be conversations such as TransportCamp and talking to politicians to make sure this is a priority, because it is an important part of the public transport experience.