DB No real time information on Sunday

LeinsterDub

Just an FYI.

JuliusCaesar

Bloody crazy - the day you need information most. What is up with their Real Time information system that it can't cope with route changes?

punisher5112

Its pointless as buses won't be running to schedule and are all over the place.

LXFlyer

JuliusCaesar wrote: »

Bloody crazy - the day you need information most. What is up with their Real Time information system that it can't cope with route changes?

OK - to repeat how the RTPI system works:


1) Every individual departure on each route has it's own timetable that the schedulers have prepared which has times for every single bus stop en route.

2) The GPS reads the location of the bus and then applies that individual timetable from the current location to come up with predictive times for the rest of the route.

To do that properly for today would require drawing up a complete set of revised timetables in advance by the scheduler for every single departure on every route that serves the city centre and for every stop along those routes. That's a massive task, and all the more difficult given the difficulty of trying to estimate journey times in advance along the diverted sections of the routes when you have much heavier traffic than normal. I imagine that there are numerous curtailed services due to buses being held up in the traffic - that's pretty much impossible to predict.

Also there are a large number of extra buses running that will operate as and when necessary to fill gaps in the service as demand dictates and as such would not have a timetable.

ArmaniJeanss

Why does it have to work on timing though, why not swap to distance instead on days like this? So the system could tell me my bus is 2700 metres away (and it wouldnt matter if its a scheduled or extra service) and I could see this distance get smaller and smaller and then make my way to the bus stop.
Clearly its not as good as being told in minutes, but its vastly superior to getting no information at all.

Obviously this isn't something that could be dreamt up this morning. But in general it wouldn't be a difficult thing for someone to look at each of the routes and work out the distances. (Theres a reasonable chance this information has already been correlated so would just be needed to be input into the RTPI system).

Deu

Found out in this thread why there is no real time information once explained I can understand why the system won't work today.

It does not explain the Dublin Bus website for a bus stop it says "Sorry, Real Time Information is currently unavailable for this bus stop."
It gives the impression that it is problem at this time why not state clearly that the system is not working because it is unreliable because of all the diversions and extra services, it is very bad form from Dublin Bus.

Victor

Was RTPI working for those routes that weren't affected?

Was there any message on display?

devnull

Worked fine for me today.

cdebru

Deu wrote: »

Found out in this thread why there is no real time information once explained I can understand why the system won't work today.

It does not explain the Dublin Bus website for a bus stop it says "Sorry, Real Time Information is currently unavailable for this bus stop."
It gives the impression that it is problem at this time why not state clearly that the system is not working because it is unreliable because of all the diversions and extra services, it is very bad form from Dublin Bus.

It is repeating the RTPI information which is controlled by the NTA, DB can't change what the signs say.

Victor

cdebru wrote: »

It is repeating the RTPI information which is controlled by the NTA, DB can't change what the signs say.

The data on the RTPI signs (in Dublin) is Dublin Bus controlled. Yes, most of it is automated and there may be standard messages, but it is Dublin Bus that has control, not the NTA.

The signs are owned by the councils. The NTA merely provided funding.

The NTA RealTime app doesn't even use the same algorithm as Dublin Bus.

GreatDefector

Victor wrote: »

The NTA RealTime app doesn't even use the same algorithm as Dublin Bus.

Algorithm?

devnull

Victor wrote: »

The NTA RealTime app doesn't even use the same algorithm as Dublin Bus.

I believe the NTA feed is a raw feed lifted straight from the information coming from the vehicles, it's not run through any systems or filters before being published.

GreatDefector

devnull wrote: »

I believe the NTA feed is a raw feed lifted straight from the information coming from the vehicles, it's not run through any systems or filters before being published.

Then how do you get phantom buses? It's a glorified digital timetable

Real time implies that you know where the bus actually is. We now know that phantom buses are the symptom of inserting the ETA from the timetable if a bus is scheduled and not actively on route... In reality the bus is just simply not there. Buses estimated and not real time should be highlighted, and not camouflaged with the real time info to try hoodwink us into thinking it's something akin to the luas info.

Therefore it's a glorified timetable. The fact that it can't work on non standard days is because it's difficult but instead of trying to tackle the challenges it seems everyone has just shrugged their shoulders and said *I dunno* ... It could be done correctly but there's just no will at all

LXFlyer

GreatDefector wrote: »

Then how do you get phantom buses? It's a glorified digital timetable

Real time implies that you know where the bus actually is. We now know that phantom buses are the symptom of inserting the ETA from the timetable if a bus is scheduled and not actively on route... In reality the bus is just simply not there. Buses estimated and not real time should be highlighted, and not camouflaged with the real time info to try hoodwink us into thinking it's something akin to the luas info.

Therefore it's a glorified timetable. The fact that it can't work on non standard days is because it's difficult but instead of trying to tackle the challenges it seems everyone has just shrugged their shoulders and said *I dunno* ... It could be done correctly but there's just no will at all

Have you some kind of crystal ball that can accurately predict traffic conditions on days such as Sunday and St Patrick's Day, and how long diversions are going to take?

ArmaniJeanss

lxflyer wrote: »

Have you some kind of crystal ball that can accurately predict traffic conditions on days such as Sunday and St Patrick's Day?

ArmaniJeanss wrote: »

Why does it have to work on timing though, why not swap to distance instead on days like this? So the system could tell me my bus is 2700 metres away (and it wouldnt matter if its a scheduled or extra service) and I could see this distance get smaller and smaller and then make my way to the bus stop.
Clearly its not as good as being told in minutes, but its vastly superior to getting no information at all.

My earlier suggested solution. (though wouldn't work for diversions).

cdebru

Victor wrote: »

The data on the RTPI signs (in Dublin) is Dublin Bus controlled. Yes, most of it is automated and there may be standard messages, but it is Dublin Bus that has control, not the NTA.

The signs are owned by the councils. The NTA merely provided funding.

The NTA RealTime app doesn't even use the same algorithm as Dublin Bus.

My understanding is that DB provide the information but have no control over what is displayed on the RTPI boards so a controller can provide information but has no control on how that information is displayed.

cdebru

ArmaniJeanss wrote: »

My earlier suggested solution. (though wouldn't work for diversions).

An app that allowed you to pick a route and direction then displayed a map with the location of buses on that route in that direction would at least partially address the issue and show diversions, it wouldn't tell you when a bus would arrive at a particular point but it could show where the buses actually are.

LXFlyer

cdebru wrote: »

An app that allowed you to pick a route and direction then displayed a map with the location of buses on that route in that direction would at least partially address the issue and show diversions, it wouldn't tell you when a bus would arrive at a particular point but it could show where the buses actually are.

This would be the best solution.

Sam Russell

GreatDefector wrote: »

Then how do you get phantom buses? It's a glorified digital timetable

I do not know about how the system works but I have been on a bus that was full and so went out of service - so presumably that would be a phantom bus.

GreatDefector

lxflyer wrote: »

Have you some kind of crystal ball that can accurately predict traffic conditions on days such as Sunday and St Patrick's Day, and how long diversions are going to take?

No, but my sat-nav (which uses GPS) does a fine job of route recalculation

AlekSmart

Sam Russell wrote: »

I do not know about how the system works but I have been on a bus that was full and so went out of service - so presumably that would be a phantom bus.

A significant issue and one which should not have been allowed to develop.

A Full Bus is just that,Full,but remaining in-service.
Bus services are dynamic,an so the bus which is full at Georges St,may effectively empty at the Central Bank.

A Full Bus should be dealt with by the Driver managing the load,ensuring that the total capacity of the vehicle is utilized,and if required,denying access at stops.

Displaying,or being instructed to display, "Out-Of-Service" on a vehicle which is merely Full,is in no way acceptable,as in the broader perspective,that journey is then recorded as having proceeded without issue,whereas the reality is one of a capacity issue,which now may never appear on the stats....which of course,is what the NTA will use when reviewing the route performance for future alterations.

Out-Of-Service buses,should not have fare-paying passengers on board.

LXFlyer

GreatDefector wrote: »

No, but my sat-nav (which uses GPS) does a fine job of route recalculation

All of these RTPI systems work (around the world) by reading from a timetable - someone has to go and come up with a full route timetable for each departure for every stop - they apply the buses' current location (as read by the GPS equipment on the bus) to that timetable and thereby extrapolate predictive times for the rest of the route.

With almost 1,000 buses out there at any one time that's a lot of schedules to prepare for a single day - do you think DB have the resources to do that? They did it for the full timetable but expecting them to do it for every day there's a special service with numerous diversions is a bit excessive. It's not going to be very reliable for a start.

Add in the fact that there were extra buses operating on an ad hoc basis as and when required (not timetabled) and it becomes even more difficult.

Other cities that I've visited have done the same thing as Dublin.

I think you are expecting a bit much.

GreatDefector

lxflyer wrote: »

I think you are expecting a bit much.

Expecting a functional system is a bit much? Let's agree to disagree there. There's more practical ways to do it i'm sure. Stockholm manage to include these things

http://www.eurotransportmagazine.com/17865/news/industry-news/real-time-information-improves-stockholm-bus-passenger-satisfaction/


but, we get this instead... All too common missing buses. Again its called "Real Time" so I should under no circumstances have buses that don't appear. Yet, it's rampant. Happened to me over the weekend. If you're tracking buses in real time, they can't just disappear

http://www.irishtimes.com/opinion/letters/waiting-for-a-real-time-bus-1.2317373

devnull

So if you are 5 minutes away from a terminus you expect the screen to be blank until the bus leaves the terminus?

LXFlyer

I don't see any mention in that article of the Stockholm system coping with massive diversions from normal?

Quite clearly what happened in the example quoted in the letter to the Irish Times is that the first #14 bus got held up in traffic for whatever reason - no system can legislate for that. The predictive times are based on normal traffic conditions. If a bus gets stuck somewhere the time will "freeze".

It may have then been curtailed at Eden Quay by the controller due to it being late, and passengers switched to the one behind.

Unfortunately the bus service does get affected by what's going on around it. There isn't an all seeing eye that can make predictions of these things.

Sam Russell

AlekSmart wrote: »

Out-Of-Service buses,should not have fare-paying passengers on board.

Out-Of-Service buses should be a rarity. I'm sure Ryanair or Aer Lingus do not have many Out-Of-Service flights.

I have seen Out-Of-Service buses outnumber in service buses in O'Connell St at 5pm on a weekday. How could this be?

12Phase

lxflyer wrote: »

Have you some kind of crystal ball that can accurately predict traffic conditions on days such as Sunday and St Patrick's Day, and how long diversions are going to take?

Google maps does this all the time in real time. No crystal ball required. Traffic info comes from monitoring phones in cars.

devnull

12Phase wrote: »

Google maps does this all the time in real time. No crystal ball required.

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.

LXFlyer

Sam Russell wrote: »

Out-Of-Service buses should be a rarity. I'm sure Ryanair or Aer Lingus do not have many Out-Of-Service flights.

I have seen Out-Of-Service buses outnumber in service buses in O'Connell St at 5pm on a weekday. How could this be?

You're presumably seeing buses travelling from Broadstone/Phibsboro depot to take up service on Xpresso routes - they do have to travel from the depot to the terminus to start service. There's no magic flying carpet to get there!!

The bus service is operated by a mix of bus and driver duties, some of which see the bus out on the road all day, others come out only for the peak periods and return to the depots during the day and after the evening peak finishes.

AlekSmart

Sam Russell wrote: »

Out-Of-Service buses should be a rarity. I'm sure Ryanair or Aer Lingus do not have many Out-Of-Service flights.

I have seen Out-Of-Service buses outnumber in service buses in O'Connell St at 5pm on a weekday. How could this be?

In the Airline industry they're known as Positioning Flights,and are entirely part and parcel of the daily routine.

In the O Connell St case,these OOS Buses could be due to several different reasons,accidents,roadworks,events,human-factors,breakdowns...all of which would result in duties being regulated,in an attempt by the controller,to get it back on time for it's next scheduled journey.

This is more prevalent in Dublin,than say,London as we do not have the menu of Curtailed destinations which London has,so that a route can be operated in-service over the busiest sector,and then "turned short" to get back on schedule.

In Dublin,a controller is limited to,usually 2 options,Out-Of-Service or City-Centre Curtailment.

If the various bodies were to be brought together under the NTA's remit,to agree on a selection of Curtailment Points,with appropriate Bus Turning arrangements then the incidence of OOS running would decrease considerably.

You would be correct to suggest that Airlines seek to limit such flights,and with full control of their corridors,are largely successful at that.

In the Bus world (Not merely Dublin) Out-Of-Service running will remain,sadly quite common,as the mode competes,largely unsuccessfully with Private Cars for roadspace.

Nowwhere was this more evident than on O Connell Bridge Northbound,during the 1916 events....That very large Electronic Display advising all and sundry that The Street was Closed EXCEPT for deliveries AND Access to Arnotts Car Park

Getting rid of an Imperial Power was the easy bit...a hundred years later,Dublin City's Traffic Management,is firmly controlled by the Multi-Storey Car Park Operators and their profitability requirements ...;)

markpb

devnull wrote:

So if you are 5 minutes away from a terminus you expect the screen to be blank until the bus leaves the terminus?

For the first bus of the day, it could and should display the eta based on the departure time from the terminus. For all other buses, it should be based on the current location of bus which will operate that departure plus any break time.

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.

Victor

GreatDefector wrote: »

Algorithm?

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.

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.

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.

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.

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.

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.