Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

RTPI and 'missing' busses

Options
124»

Comments

  • Closed Accounts Posts: 829 ✭✭✭smellmepower


    RTPI for the 76 in Clondalkin Village this morning was stuck on 3 mins for over ten minutes before the bus eventually showed up. Rushed to get to the stop in time for absolutely nothing.

    Yesterday afternoon at Liffey Valley the RTPI for a 76 counted from 15min to due and just disappeared off the list.Was waiting from 15:20 to 16:10 for the next one, which was packed of course.

    Such an annoying system.


  • Registered Users Posts: 1,179 ✭✭✭KD345


    RTPI for the 76 in Clondalkin Village this morning was stuck on 3 mins for over ten minutes before the bus eventually showed up. Rushed to get to the stop in time for absolutely nothing.

    Yesterday afternoon at Liffey Valley the RTPI for a 76 counted from 15min to due and just disappeared off the list.Was waiting from 15:20 to 16:10 for the next one, which was packed of course.

    Such an annoying system.

    It sounds like something delayed your bus this morning at a previous stop. Possibly heavy traffic or a problem with a passenger.

    A 76 broke down yesterday and the 15:20 from Chapelizod couldn't operate.


  • Closed Accounts Posts: 829 ✭✭✭smellmepower


    I know it sometimes gets delayed crossing the Belgard to Fonthill at Newlands, but 10 minutes is a bit much. Surely the GPS would refresh the buses location to the RTPI system more than once in 10 minutes?


  • Registered Users Posts: 17,554 ✭✭✭✭LXFlyer


    I know it sometimes gets delayed crossing the Belgard to Fonthill at Newlands, but 10 minutes is a bit much. Surely the GPS would refresh the buses location to the RTPI system more than once in 10 minutes?



    I think the point is that the RTPI schedule would have shown it as taking 3 minutes to get from where it was to Clondalkin Village, but that the bus got blocked for whatever reason - it will still show three minutes as the computer system can't tell how long a blockage is going to take to clear.


  • Closed Accounts Posts: 18,969 ✭✭✭✭syklops


    When I was involved in speccing and delivering an RTPI system in the UK, we got round the predicted / scheduled conundrum by showing sheduled times as such (eg 12:25), and predicted ones as a countdown (eg 5 mins). This was explained on stop information. The customers knew therefore that a predicted bus was definitely on the way, whereas a scheduled one may or may not be.

    The problem with the latter is that, unless the system is monitored continuously, there is no way of the system knowing whether it is a fault on the bus, driver incorrectly signed in or the bus not being present. Hence, unless you pay someone to sit there and manually update, "Bus Cancelled" messages for individual journeys are impractical.

    Its disheartening to hear someone who had a hand in delivering a system like this say there is no way of building in fault tolerance and error checking into a system such as this.

    Why can't each bus automatically check in at each stop on the route, meaning the system has an up to date record of where each bus is?

    Real time information planners have been deployed in cities much bigger and much smaller than Dublin/Galway and some are highly accurate. Part of the problem is as Mrs O'Bumble points out its not really a Real Time Planner, its really just a digital representation of the timetable.

    I also don't buy this "The driver didnt properly sign in to the ticketing machine" story.


  • Advertisement
  • Moderators, Motoring & Transport Moderators, Technology & Internet Moderators Posts: 22,486 Mod ✭✭✭✭bk


    syklops I'm afraid you are mistaken about all that.

    The buses actually do constantly communicate their current location via GPS and the mobile networks to the central RTPI servers.

    However what is then shown on the RTPI screens is a mix of an estimate based on the timetable, the buses current location and an algorithm that predicts arrival.

    I think it is better for RTPI to say the bus will come in 3 minutes and have it turn up in 10 minutes then the other way around! It is hard for RTPI to predict the arrival time when it is due to an unexpected blockage.

    For instance in this case the bus might be 3 minutes away per the schedule and usual traffic for that time of day, but the bus might be stuck behind a road accident for 10 minutes. There is no way RTPI can tell this and deal with this in any other way then saying the bus is 3 minutes away.

    What I do have a problem with is:

    - Ghost buses, buses which say they are arriving now, but never turn up.
    - Wrong bus route shown. No a 16C isn't a 16!

    These are problems caused by Dublin Bus management and controllers and shows a simple lack of professionalism. They should never happen.


  • Closed Accounts Posts: 5,761 ✭✭✭cdebru


    syklops wrote: »
    Its disheartening to hear someone who had a hand in delivering a system like this say there is no way of building in fault tolerance and error checking into a system such as this.

    Why can't each bus automatically check in at each stop on the route, meaning the system has an up to date record of where each bus is?

    Real time information planners have been deployed in cities much bigger and much smaller than Dublin/Galway and some are highly accurate. Part of the problem is as Mrs O'Bumble points out its not really a Real Time Planner, its really just a digital representation of the timetable.

    I also don't buy this "The driver didnt properly sign in to the ticketing machine" story.


    Your problem is you are not really thinking about what RTPI is and how it can be delivered, just real time information is useless, and you are incorrect it is not a representation of the timetable, it is not just real time either, it is a mixture of both as well as trying to predict how long it will take a bus to get to a particular point while taking into account all the possible variables, like traffic, passenger loading, how fast slow the driver is, roadworks, accidents etc etc etc.
    For what it is and does I find it an excellent system and a vast improvement on what we had before which was guess how long a bus will take yourself.
    Could it be improved? yes like I said a map option on the Dublin bus app that showed you actual location would be a huge benefit.
    Differentiate when they are using "real" time and "expected" time based on the timetable.
    Give information when a bus is removed, just a couple of words, mechanical breakdown, traffic incident, passenger incident, no staff etc whatever it is.

    Lastly give the controllers a kick in the arse so they update the system, if they know a bus is due in 10 minutes at the terminus but is 20 minutes away on a previous journey then it should be removed at that stage not let it continue to count down only to disappear off the system.
    I would suggest that people actually complain when the RTPI let's them down at least that way the ones that are just someone not doing their job can be addressed, if no one says anything the people in charge presume its all good.


  • Closed Accounts Posts: 5,761 ✭✭✭cdebru


    bk wrote: »
    syklops I'm afraid you are mistaken about all that.

    The buses actually do constantly communicate their current location via GPS and the mobile networks to the central RTPI servers.

    However what is then shown on the RTPI screens is a mix of an estimate based on the timetable, the buses current location and an algorithm that predicts arrival.

    I think it is better for RTPI to say the bus will come in 3 minutes and have it turn up in 10 minutes then the other way around! It is hard for RTPI to predict the arrival time when it is due to an unexpected blockage.

    For instance in this case the bus might be 3 minutes away per the schedule and usual traffic for that time of day, but the bus might be stuck behind a road accident for 10 minutes. There is no way RTPI can tell this and deal with this in any other way then saying the bus is 3 minutes away.

    What I do have a problem with is:

    - Ghost buses, buses which say they are arriving now, but never turn up.
    - Wrong bus route shown. No a 16C isn't a 16!

    These are problems caused by Dublin Bus management and controllers and shows a simple lack of professionalism. They should never happen.



    Agree 100%

    But it should also be possible to communicate with passengers via the RTPI so if there is an accident in Fairview the RTPI screens further along the routes affected could display that information a simple "accident Fairview expect delays" would be better than staying stuck on 3 minutes for 10 minutes.


  • Closed Accounts Posts: 829 ✭✭✭smellmepower


    bk wrote: »
    syklops I'm afraid you are mistaken about all that.

    The buses actually do constantly communicate their current location via GPS and the mobile networks to the central RTPI servers.

    However what is then shown on the RTPI screens is a mix of an estimate based on the timetable, the buses current location and an algorithm that predicts arrival.

    I think it is better for RTPI to say the bus will come in 3 minutes and have it turn up in 10 minutes then the other way around! It is hard for RTPI to predict the arrival time when it is due to an unexpected blockage.

    For instance in this case the bus might be 3 minutes away per the schedule and usual traffic for that time of day, but the bus might be stuck behind a road accident for 10 minutes. There is no way RTPI can tell this and deal with this in any other way then saying the bus is 3 minutes away.

    What I do have a problem with is:

    - Ghost buses, buses which say they are arriving now, but never turn up.
    - Wrong bus route shown. No a 16C isn't a 16!

    These are problems caused by Dublin Bus management and controllers and shows a simple lack of professionalism. They should never happen.


    The reverse you mentioned has happened to me before too. IE: I've left the house with the RTPI app saying bus is 10 mins away only to double check it as I'm walking and see it has dropped to 2 mins, and I either have to sprint to the stop, or miss it and wait for another.

    Its not a reliable system, and seems like a massive waste of money to come up with what is essentially a fancy guesstimate of the timetable.

    Only way I'll actually trust it is when its possible to view your chosen buses location in proper real time on a map. Why isn't this possible now?


  • Closed Accounts Posts: 18,969 ✭✭✭✭syklops


    My problem is I can't trust the RTPI system because it is wrong 50% of the time. Thats my number 1 problem.


  • Advertisement
  • Moderators, Motoring & Transport Moderators Posts: 11,587 Mod ✭✭✭✭devnull


    Unfortunately the system does not posses a crystal ball.


  • Registered Users Posts: 6,464 ✭✭✭MOH


    cdebru wrote: »
    Your problem is you are not really thinking about what RTPI is and how it can be delivered, just real time information is useless, and you are incorrect it is not a representation of the timetable, it is not just real time either, it is a mixture of both

    The problem being that it's called "Real time", which gives people the not unreasonable expectation that it actually is.
    The DB website states "Updates are usually received from the vehicle location system at 30 second intervals, so information on the signs is regularly updated".
    And yes, I know it says "usually", and it doesn't actually say the sign is accurate to within 30 seconds, but that is the impression it gives.
    and again, the fact it refers to 2011 as being in the future shows how often it's updated for accuracy.
    cdebru wrote: »
    But it should also be possible to communicate with passengers via the RTPI so if there is an accident in Fairview the RTPI screens further along the routes affected could display that information a simple "accident Fairview expect delays" would be better than staying stuck on 3 minutes for 10 minutes.
    This, definitely.
    devnull wrote: »
    Unfortunately the system does not posses a crystal ball.
    No, but it would help if it made better use of the data available to it.
    By this stage it should have a wealth of information about bus movements at various times of day, various times of year. It should be primarily using that over the kind of intermediate timetable information that would have been necessary when the system was launched.
    If there's multiple buses serving a route, or a stretch of one, and they're all being delayed, or even running slower than usual, around the same location, then chances are there's a traffic issue which should be detectable.


Advertisement