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

DB No real time information on Sunday

2»

Comments

  • Registered Users Posts: 10,460 ✭✭✭✭MJohnston


    I think the RTPI screens operate about as best as one could expect them to, given that they have to communicate simple information only in a very abbreviated fashion. What should happen is that RTPI should also operate along with a live map system that you can access from your smartphone or the web, displaying a buses actual location, overlaid with both traffic density info, and the route paths. To anyone with a cursory knowledge of Dublin traffic patterns, this would be far more valuable than any ETA counter.


  • Registered Users Posts: 78,218 ✭✭✭✭Victor


    Algorithm? :confused:
    As I understand it.

    Let us say a bus route has 11 stops (including termini). According to the timetable, it takes 1 minute to travel between each stop, for a total of 10 minutes (1 less legs than stops). If the bus runs to schedule, the system will work perfectly.

    However, let us say there are road works between stops 3 and 4, that delays the bus by 4 minutes. The system can then say "That bus is 4 minutes late and will be 4 minutes late at each stop." The RTPI sign at stop 4 will say "due" until the bus arrives, but once it reaches stop 4, the RTPI sign at stop 5 can say "5 minutes", the RTPI sign at stop 6 can say "6 minutes" and so on. The driver's display on the bus will say "-4 minutes" (it might be "+4 minutes"), but you get the idea.

    So, while the above is useful once the bus gets to stop 4, until it gets there, it will be saying the bus is "due" for 4 minutes. A similar issue arises at the subsequent stops.

    So, to improve this, a few things are done, e.g. the introduction of "Virtual stops" at locations known for congestion, e.g from Amiens Street to the Customs House. When I had access to the virtual stop data, there were probably less than a hundred, out of about 7,000 Dublin Bus stops. However, being in strategic locations, they covered most routes, most buses and most congestion.

    So, if there were virtual stops on our example route above at, say, stop 3.5, then the system would learn much more quickly that the bus is running late. However, the virtual stops are much more useful for persistent issues like the Customs House or Luas CRoss City disruption and less use for occasional road works, collisions or events.

    However, the next time our bus makes the above trip, it will make the exact same mistake. So, to improve out prediction, the system records how long it has taken to travel each leg on recent journeys. I've been told that the Dublin City Council / Dublin Bus system tracks the last 100 journeys of each bus departure. Given that there are about 100 routes and 1,000 buses in the DB fleet and each bus checks in with the system perhaps once per minute, that's a lot of data. The system can only store a few days data, although some summary data is likely to be kept.

    So, having realised that the leg from stop 3 to 4 took 4 minutes last time, the next time the system will expect it to take more than the 1 minute in the timetable. Maybe it will allow 2 minutes. If, through the day, it is constantly taking 4 minutes, then the system will learn to allow 4 minutes. When the roadworks finish, over the following journeys, the system will gradually change back to using the timetable.


    Where it would be good, is if DB and the other organisations created a timetable to cover routine and exceptional situations. DB have public weekday, Saturday and Sunday timetables. Privately, the have working timetables, where due to different running times, a route that might need 12 buses in winter might need only 10 in summer.

    There are specific days though the year where there are habitual changes, e.g. public holidays, Christmas, Easter and summer school / college holidays where DB have to publish announcements that there will be no service, no service on certain routes, limited service etc. Very few of the published timetables account for this, e.g. there are some notes in timetables that certain departures only operate from UCD during the college term.

    In some countries, the public timetable will have weekday, Saturday, Sunday, public holiday and summer timetables. The difference might only be a different number of departures at peak times, but there is much greater clarity.

    Regarding exceptional situations, the Westland Row to Gardiner Street route needs to be protected (permanent stand-by bus stops, no stopping / parking, garda enforcement, tow trucks).

    Unfortunately, there seems to be several days per month where there will be a parade, protest march or similar in the city centre and the system falls apart, which the Japanese and German motor industries and suburban shopping centres must love. It would be good if there were a timetable / arrangement to cover such situations.


  • Registered Users Posts: 78,218 ✭✭✭✭Victor


    devnull wrote: »
    Except that Google Maps predicts a journey based from A to B without stopping on it's route planner.

    Dublin Bus has something known as bus stops between A & B and doesn't always take the fastest route between A & B.
    Google Transit has the timetables loaded from the NTA database.
    MJohnston wrote: »
    I think the RTPI screens operate about as best as one could expect them to, given that they have to communicate simple information only in a very abbreviated fashion.
    The messaging option is grossly under-used.
    What should happen is that RTPI should also operate along with a live map system that you can access from your smartphone or the web, displaying a buses actual location, overlaid with both traffic density info, and the route paths. To anyone with a cursory knowledge of Dublin traffic patterns, this would be far more valuable than any ETA counter.
    A few things need to happen. I'm not sure if a 'shiny' app is the solution - heal the patient, don't take pictures of their illness.

    An analysis need to happen of the historical RTPI data to see where buses are being delayed.

    If a bus isn't logged into the system, then the NTA needs to withdraw the subsidy for that departure. This should reduce the number of ghost buses substantially.

    There needs to be a bus etiquette publicity campaign, especially aimed at maximising capacity use. People block the aisle from the stairs to the white line need to be thrown off the bus. :) More reasonably, move the white line back to the stairs.

    The bus gates that were built, e.g. Rathmines (Swan Centre to petrol station) need to be put into action. Others need to be put in place at strategic locations.

    Bus lane, red light and yellow box junction cameras are needed to enable these facilities to be used properly.

    Bus stops need to be large enough to enable the typical number of buses using them to pull in. Having spent money on Kassel Kerbs for the exact length of one bus is useless (not least that there are no doors at the back of the bus), especially if there are typically three buses using the stop at a time at peak. Having parking bays before and after bus stops means the bus can't pull in properly, thereby slowing boarding and alighting.


  • Registered Users Posts: 19,587 ✭✭✭✭Muahahaha


    Just on the phantom buses, when RTP1 was launched I was under the impression that the driver would have to 'log-on' to the RTP1 system to show central control that the bus is running on time and does actually exist. Thus meaning there would have to be a physical bus for info about its timing to show on the RTP1 system.

    Am I wrong or was this feature dropped during the launch period? And what exactly happens with the system when there is no bus, does it still show waiting passengers minutes due with it reducing to 'Due' and then nothing shows up? If so that much be incredibly frustrating for regular bus users.


  • Registered Users Posts: 78,218 ✭✭✭✭Victor


    As best I know, the log-in requirement is still there, as otherwise the RTPI system doesn't know which vehicle is operating which departure. There is an intermittant problem with drivers not logging-in.

    If a bus isn't logged-in to the system, the system assumed it is still operating and will give the predictions based on the timetable. If the bus doesn't run to the timetable, it will result in two ghost buses - a bus not on the system that shows up and a bus on the system that doesn't show up.

    When the RTPI system is operating to timetable, it should say so, e.g by putting an asterisk after the time.


  • Advertisement
  • Closed Accounts Posts: 22,651 ✭✭✭✭beauf


    Its not a big task for a computer though. All it needs is the scheduled time, and the real time. Then analyse the differences.

    If for example over 50% of buses real time are not close to their schedule time, an automated message comes up saying the buses aren't running to schedule and post estimated times based on their real times. Lots of similar stuff automated could be done.

    Also all the stuff with historical data as Victor said.

    I don't get the bus much. when I do I almost encounter ghost buses, and also stealth buses, ones that aren't on any timetable or real time tracking. So there must a lot of them for people who get the bus a lot.

    Its the same problem with the train though. Very little real time information.


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


    Victor wrote: »
    As best I know, the log-in requirement is still there, as otherwise the RTPI system doesn't know which vehicle is operating which departure. There is an intermittant problem with drivers not logging-in.

    If a bus isn't logged-in to the system, the system assumed it is still operating and will give the predictions based on the timetable. If the bus doesn't run to the timetable, it will result in two ghost buses - a bus not on the system that shows up and a bus on the system that doesn't show up.

    When the RTPI system is operating to timetable, it should say so, e.g by putting an asterisk after the time.


    A driver can't not log in, the logging in is done automatically when the driver sets the ticket machine for a particular journey. It's possible to enter a wrong duty number but that will flag on the controllers system as is usually picked up fairly quickly.Sometimes machines can be faulty, it's usually mechanical error rather human error.


Advertisement