RTPI and 'missing' busses

km991148

Anyone notice buses dropping off the RTPI?

I have noticed this in the past - but standing at a stop this morning and 65b did not come (an entering service bus did however..)

RTPI showed it comming at 7.12.. then.. nothing..

In taxi now - another 20 quid gone grr..

No information was better than wrong information.

truedoom

sure it's common enough for buses to not show up imo. Happened me a number of times in college. Equally annoying when they are at hour intervals, and you end up late for lectures.

Mrs OBumble

Yup, I've noticed that in Galway.

I think that the system tells lies about what is real time; sometimes it says real time but it's actually a prediction from the timetable.

LXFlyer

km991148 wrote: »

Anyone notice buses dropping off the RTPI?

I have noticed this in the past - but standing at a stop this morning and 65b did not come (an entering service bus did however..)

RTPI showed it comming at 7.12.. then.. nothing..

In taxi now - another 20 quid gone grr..

No information was better than wrong information.

Mrs OBumble wrote: »

Yup, I've noticed that in Galway.

I think that the system tells lies about what is real time; sometimes it says real time but it's actually a prediction from the timetable.

I think "tells lies" is a bit strong - it's a predictive system.

How the system works is - until about 2-3 minutes before a bus leaves the terminus it does use the timetable to predict when it will arrive at each stop along the route. At that point it switches to the bus. From then on the system uses GPS and the bus' current location and applies the predicted timetable from that location all along the route to generate the estimated times that the bus will appear.

What can cause buses to disappear from the system?
* If a driver is not signed into his ticket machine the bus will drop off the system 2-3 minutes prior to departure - it needs the ticket machine to be live to function
* Where a change of drivers takes place midway along the route the bus will disappear while one driver signs off and the new driver signs on
* If the bus has defective GPS equipment it will not show up on the system once the system switches to "live" mode.
* Similarly if for whatever reason (e.g. breakdown, no driver available) that the bus does not operate, unless the controller manually intervenes and marks it as cancelled the bus will appear on the system until it switches to "live" mode.

Perhaps in the OP's situation the bus broke down as it was en route. In that case the controller would then cancel the service on the system, and this would cause it to disappear off the system.

stop

I wonder would there be any benefit of leaving the cancelled bus on rtpi, but with 'cancelled' in place of the due time instead of just removing it, and allowing it to time out on each stop in line with the 'expected' arrival times?

At least then customers would have an idea if the bus is not coming at all, or the GPS equipment may be faulty (i.e. worth waiting around to see).

It would also introduce some transparency into cancellations.

GLaDOS

Leaving cancelled buses up on the board isn't good enough. It's inconvenienced me plenty of times when I could have gone to another bus stop if I'd known that one wasn't going to show up.

Mrs OBumble

lxflyer wrote: »

I think "tells lies" is a bit strong - it's a predictive system.

I would agree with you, if these entries had "Predicted" written in blue under them.

But they don't, they have a satellite icon and the words "Real time". If the system is going to say that data is "real time", then it needs to be "real".

An example - see this tweet https://twitter.com/GTdotI/status/509450590385356800/photo/1

The bus that's listed arrived at the stop just as I was taking the screen shot, a whole 11 minutes ahead of the alleged "real time".

And their prediction algorithm is pretty off, too: I was able to predict the bus would arrive pretty much when it did, based on previous observation of buses at that time of the evening. It ain't rocket science - but the system cannot do it.

lxflyer wrote: »

How the system works is - until about 2-3 minutes before a bus leaves the terminus it does use the timetable to predict when it will arrive at each stop along the route. At that point it switches to the bus. From then on the system uses GPS and the bus' current location

Ahh, sorry, but that's not how it's working in Galway.

in the example above, the bus was due to leave it's terminal at Merlin Park at 10pm, and I'm be fairly sure that's when it did leave, based on when it arrived at the stop I was at.

LXFlyer

Mrs OBumble wrote: »

I would agree with you, if these entries had "Predicted" written in blue under them.

But they don't, they have a satellite icon and the words "Real time". If the system is going to say that data is "real time", then it needs to be "real".

An example - see this tweet https://twitter.com/GTdotI/status/509450590385356800/photo/1

The bus that's listed arrived at the stop just as I was taking the screen shot, a whole 11 minutes ahead of the alleged "real time".

And their prediction algorithm is pretty off, too: I was able to predict the bus would arrive pretty much when it did, based on previous observation of buses at that time of the evening. It ain't rocket science - but the system cannot do it.

Ahh, sorry, but that's not how it's working in Galway.

in the example above, the bus was due to leave it's terminal at Merlin Park at 10pm, and I'm be fairly sure that's when it did leave, based on when it arrived at the stop I was at.

Well why don't you look at the full schedule for the route at www.a-b.ie (the link is on the right of that page) - that's what is used to predict the journey times.

Someone in Bus Eireann has to draw up these times in the first place and if the times that they have used have an error, then inevitably the system won't be giving correct predictions.

When something like this happens, it tends to be down to human error, rather than someone "telling lies". I think it might be better to point out to BE/NTA that there are errors in the predictive times in a proactive way, rather than using terms such as "lies".

To be honest it sounds like the GPS equipment on that bus may have been defective.

Any system giving predictions for bus times is never going to be 100% accurate, given there are external factors that can cause delays.

Avada

What I've noticed (with Dublin Bus anyway), is it is usually the same bus missing each day. For example there is one bus I get each day where the 22.40 bus is pretty much never on the board

n97 mini

+1

I get the same buses regularly missing off the RTPI, but still arrive. A long way from the start of the route too.

When a bus has been cancelled could a message not be scrolled at the bottom of the sign to indicate that?

Mrs OBumble

lxflyer wrote: »

When something like this happens, it tends to be down to human error, rather than someone "telling lies". I think it might be better to point out to BE/NTA that there are errors in the predictive times in a proactive way, rather than using terms such as "lies".

I'm sure that the NTA are only too well aware of the weaknesses in their predictive approach, and in particular with algorithms which make the same predicted journey times for
peak time (lots of pax)
day-time non-peak (less passengers, but they tend to be old/disabled so slower-moving)
night-time off-peak (fast journeys).

I don't call inaccurate predictions based on this lies - as you say, they are weaknesses.

The lie is the system is saying that the times are "real time" when they obviously and blatantly are not. If any data from the bus in my example has been used, then the predicted time would have been way more accurate.

And I don't believe that the example given is due to defective equipment on one bus: I've been seeing similar behaviour over and over again in Galway - except on route 403 which has been remarkably accurate.

LXFlyer

Mrs OBumble wrote: »

I'm sure that the NTA are only too well aware of the weaknesses in their predictive approach, and in particular with algorithms which make the same predicted journey times for
peak time (lots of pax)
day-time non-peak (less passengers, but they tend to be old/disabled so slower-moving)
night-time off-peak (fast journeys).

I don't call inaccurate predictions based on this lies - as you say, they are weaknesses.

The lie is the system is saying that the times are "real time" when they obviously and blatantly are not. If any data from the bus in my example has been used, then the predicted time would have been way more accurate.

And I don't believe that the example given is due to defective equipment on one bus: I've been seeing similar behaviour over and over again in Galway - except on route 403 which has been remarkably accurate.

You keep going on about algorithms - this is based on a schedule that a scheduler has drawn up - I've told you where to look for it. If they've prepared it using the wrong times, then inevitably the predictive times will be wrong.

Again, the NTA are not responsible for the predictive times - that is down to the operator, in this case Bus Eireann.

BE are responsible for generating the predictive times and for the equipment on the buses.

All that the NTA are responsible for is the delivery of this information to the end user via their apps. They, however, rely on the operators getting this right.

I would suggest that you should be getting in touch with both organisations, but Bus Eireann in the first place, as they are responsible for generating the expected journey times.

LXFlyer

n97 mini wrote: »

+1

I get the same buses regularly missing off the RTPI, but still arrive. A long way from the start of the route too.

When a bus has been cancelled could a message not be scrolled at the bottom of the sign to indicate that?

That sounds more like defective GPS equipment on the bus.

n97 mini

lxflyer wrote: »

That sounds more like defective GPS equipment on the bus.

Could be, but I find the 25A/B and 66A are very regularly missing.

Heroditas

n97 mini wrote: »

Could be, but I find the 25A/B and 66A are very regularly missing.

Yeah definitely agree with you. It happens a lot when I'm getting those buses from Willsbrook or Woodies heading into town.

Avada

lxflyer wrote: »

That sounds more like defective GPS equipment on the bus.

I'm not so sure. In my case, the same buses are missing each day, at the first stop

Greenmachine

Stood waiting half an hour at a bus stop on a few occasions watching the minute count down to "bus due" and then have it disappear from the system, and have the same thing happen with the next 2 buses.

km991148

lxflyer wrote: »

I think "tells lies" is a bit strong - it's a predictive system.

Perhaps in the OP's situation the bus broke down as it was en route. In that case the controller would then cancel the service on the system, and this would cause it to disappear off the system.

There are various point here but in this case the bus disapeared at the approx scheduled time.
So reading between the lines the RTPI was reporting the approx time from the timetable. This was being reported when I was at home and decided to get that particular bus. It was being reported as I walked to the bust stop (rather than take a different route) and was being reported up to when the bus would apporx arrive.. and then.. nothing..

What is the point in such a misleading system? It would be better to have no info than wrong info? It must have been known at some point before the scheduled time that the bus was not en route (Driver not signed in, bus broke down, driver pulled a sickie/went for sausage sambo/some other random reason) so why show the fairly pointless timetable best guess..?

km991148

Random_Name wrote: »

I'm not so sure. In my case, the same buses are missing each day, at the first stop

This happens often at the start of the 15a (benson st). Sometimes the buses can be seen diverting towards Pearse st.

I asked DB about it one time.. the answer - check twitter.. ffs like - a multi million euro system named Real Time Passenger Info, that misleads customers (through bad design or otherwise) and relies on someone updating twitter..

LXFlyer

km991148 wrote: »

This happens often at the start of the 15a (benson st). Sometimes the buses can be seen diverting towards Pearse st.

I asked DB about it one time.. the answer - check twitter.. ffs like - a multi million euro system named Real Time Passenger Info, that misleads customers (through bad design or otherwise) and relies on someone updating twitter..

The system reads from a timetable which is stop specific.

If there are diversions in operation they're not going to be on RTPI as that would mean someone having to totally recast the timetables for what could be a certain number of departures.

I know that the 15a/15b have been affected by the closure of the Samuel Beckett bridge which would impact on the services.

Where these diversions are planned (and this is a general comment), DB to be fair have in general put up notices on affected stops.

I don't know of any systems that will show predictive times for buses on diversion.

Mrs OBumble

lxflyer wrote: »

You keep going on about algorithms - this is based on a schedule that a scheduler has drawn up - I've told you where to look for it. If they've prepared it using the wrong times, then inevitably the predictive times will be wrong.

...

All that the NTA are responsible for is the delivery of this information to the end user via their apps. They, however, rely on the operators getting this right

I've looked at their predictive times. Agree it's BEs dumbness that has the same inter-stop times at all times.

But it's the NTA's app that is saying "real time" when the data they are showing is purely predictive.

I repeat - I don't have a problem with their predictions. I do have a problem with the app saying "real time" when it absolutely isn't anything resembling real.

LXFlyer

Mrs OBumble wrote: »

I've looked at their predictive times. Agree it's BEs dumbness that has the same inter-stop times at all times.

But it's the NTA's app that is saying "real time" when the data they are showing is purely predictive.

I repeat - I don't have a problem with their predictions. I do have a problem with the app saying "real time" when it absolutely isn't anything resembling real.

Well reading your first line, you are saying that the predictive times that BE have come up with are wrong - therefore the prediction is incorrect in the first place.

Again, the times should be real time - that's what the operator has contracted to provide - as far as the NTA is concerned that's what they should be doing.

If that is not happening (and clearly it is not) I would be suggesting that you write a well phrased letter to both Bus Eireann in Galway and the NTA.

That's why as I've said your issue in the first instance is with Bus Eireann, and not the NTA.

Avada

lxflyer wrote: »

The system reads from a timetable which is stop specific.

Thats my point. Why are buses missing from RTPI at first stops?

It should NEVER happen. There is no excuse for faulty hardware in this situation, as as you have said multiple times RTPI Should read from timetables in this situation, it just seems it isn't

markpb

Maybe someone who knows how these things work can answer two questions for me.

Why is there no link between bus operations? I.e. Could the system know that bus ax230 is operating an outbound route immediately followed by an inbound route? If it did and it saw that the first operation is late, it could make more useful predictions about the next operation.

Why is the system still relying on manually written timetables when, after years of operation in Dublin, it should have a far better idea of when the bus will actually appear at a stop.

km991148

Overall as a moderate bus user, the number of times RTPI has got it completely wrong means I have little confidence in the system. It is a rough guide at best, which is the same as me looking at a time table and guesstimating. That makes a mockery of the system in my opinion and must be a let down for anyone who has worked on it.

It doesn't help that it feels as if there is no will to fix issues such as this. Drivers don't care, the customer service email spews out generic responses and all the while the fares rise by a considerable amount each time (even if using LEAP - another system that is far from ideal).

No wonder so many people drive in this city..

Avada

markpb wrote: »

Maybe someone who knows how these things work can answer two questions for me.

Why is there no link between bus operations? I.e. Could the system know that bus ax230 is operating an outbound route immediately followed by an inbound route? If it did and it saw that the first operation is late, it could make more useful predictions about the next operation.

Why is the system still relying on manually written timetables when, after years of operation in Dublin, it should have a far better idea of when the bus will actually appear at a stop.

The last paragraph is how the NTA say it should work (in combination with timetables). Not so sure about the second paragraph though, seems like a good idea.

LXFlyer

Random_Name wrote: »

Thats my point. Why are buses missing from RTPI at first stops?

It should NEVER happen. There is no excuse for faulty hardware in this situation, as as you have said multiple times RTPI Should read from timetables in this situation, it just seems it isn't

You were referring to 15a/15b services not serving Benson Street.

My point is that they would have been diverted to Pearse Street due to the Samuel Beckett Bridge being closed.

RTPI cannot take account of that.

Buses can disappear from RTPI at the first stop if the driver has not signed in on his ticket machine as I explained above. The system relies (from about two-three minutes before departure) on the bus being "live".

RTPI frankly is more relevant along the route - at/near the terminus it's always best to use the timetable.

LXFlyer

km991148 wrote: »

Overall as a moderate bus user, the number of times RTPI has got it completely wrong means I have little confidence in the system. It is a rough guide at best, which is the same as me looking at a time table and guesstimating. That makes a mockery of the system in my opinion and must be a let down for anyone who has worked on it.

It doesn't help that it feels as if there is no will to fix issues such as this. Drivers don't care, the customer service email spews out generic responses and all the while the fares rise by a considerable amount each time (even if using LEAP - another system that is far from ideal).

No wonder so many people drive in this city..

I can only say that as a fairly heavy user (generally 4 buses per day and quite a variety at that) that for me it does work the vast majority of the time, except for those circumstances that I listed above.


But in general I do tend to use RTPI as a tool, and would still double check the timetable, particularly if I was boarding at or near the terminus.

Avada

lxflyer wrote: »

You were referring to 15a/15b services not serving Benson Street.


My point is that they would have been diverted to Pearse Street due to the Samuel Beckett Bridge being closed.


RTPI cannot take account of that.

Nope, that was another poster. I actually hadn't specified the route. For the record it is the 130 from Abbey Street, operating from its normal (new) stop with no diversions

LXFlyer

markpb wrote: »

Maybe someone who knows how these things work can answer two questions for me.

Why is there no link between bus operations? I.e. Could the system know that bus ax230 is operating an outbound route immediately followed by an inbound route? If it did and it saw that the first operation is late, it could make more useful predictions about the next operation.

Why is the system still relying on manually written timetables when, after years of operation in Dublin, it should have a far better idea of when the bus will actually appear at a stop.

Well in the first case it's up to the controller to decide what to do next - either cancel the service altogether or operate a curtailed version along part of the route. No system can account for that as it requires human intervention.

As for the second question, that I don't know.

km991148

lxflyer wrote: »

I can only say that as a fairly heavy user (generally 4 buses per day and quite a variety at that) that for me it does work the vast majority of the time, except for those circumstances that I listed above.


But in general I do tend to use RTPI as a tool, and would still double check the timetable, particularly if I was boarding at or near the terminus.

But thats the point.. (I mentioned the 15a, but I am now talking the 65b)

I got the 2nd bus of the day at a time with no traffic.. the rTPI reported the same times as the timetable and it was still wrong - misreporting a guess then nothing.

I also have a suspicion that the bus that passed me (entering service) was seen at the destination after arrived by taxi - i.e. it just drove straight there - but I am only 90% sure on this..

LXFlyer

Random_Name wrote: »

Nope, that was another poster. I actually hadn't specified the route. For the record it is the 130 from Abbey Street, operating from its normal (new) stop with no diversions

Apologies - well the second half of my point stands - it requires the bus to be "live" - i.e. the driver to be signed in on the ticket machine.

LXFlyer

km991148 wrote: »

But thats the point.. (I mentioned the 15a, but I am now talking the 65b)

I got the 2nd bus of the day at a time with no traffic.. the rTPI reported the same times as the timetable and it was still wrong - misreporting a guess then nothing.

I also have a suspicion that the bus that passed me (entering service) was seen at the destination after arrived by taxi - i.e. it just drove straight there - but I am only 90% sure on this..

I can't really comment on that specific issue - I can only tell you what I've gathered from observing the system over the recent years in general - you'd need to bring it up with Dublin Bus.


Send them an email with the specific times/date and details to customercomment@dublinbus.ie

Avada

lxflyer wrote: »

Apologies - well the second half of my point stands - it requires the bus to be "live" - i.e. the driver to be signed in on the ticket machine.

My understanding is it doesn't and thats also what I got from your post (#20). My understanding is it goes by the timetable until the bus driver signs on, and then goes live.

If it were as you have said, terminus stops would have no buses on RTPI while the buses sit (not live) on Talbot Street.

I believe that there is not valid reason for buses to be missing, just a bad system

ETA: Also, I have brought this up with Dublin Bus, along with a complaint about shutting down RTPI during rush hour for testing, just got the usual PR guff

LXFlyer

Random_Name wrote: »

My understanding is it doesn't and thats also what I got from your post (#20). My understanding is it goes by the timetable until the bus driver signs on, and then goes live.

If it were as you have said, terminus stops would have no buses on RTPI while the buses sit (not live) on Talbot Street.

I believe that there is not valid reason for buses to be missing, just a bad system

ETA: Also, I have brought this up with Dublin Bus, along with a complaint about shutting down RTPI during rush hour for testing, just got the usual PR guff

Read my original post again - it will read predictive times from the schedule until about two minutes prior to departure. It will then switch to the bus. If the bus driver has not signed in on the ticket machine at that point, then the bus will vanish from RTPI.

That's what I meant.

Otherwise, it could be a case of defective GPS equipment on the bus.

I don't recall them switching RTPI down for testing at rush hour, well certainly not a planned shut down - are you sure that it hadn't maybe crashed? They usually do any testing during the mid-morning - they need to do it when buses are on the road to verify that it is working correctly.

Avada

lxflyer wrote: »

Read my post again - it will read predictive times from the schedule until about two minutes prior to departure. It will then switch to the bus. If the bus driver has not signed in on the ticket machine at that point, then the bus will vanish from RTPI.


That's what I meant.


Otherwise, it could be a case of defective GPS equipment on the bus.

I understand what you are saying now. But I still disagree, I'm talking about buses not due for between 5-15 minutes

LXFlyer

Random_Name wrote: »

I understand what you are saying now. But I still disagree, I'm talking about buses not due for between 5-15 minutes

And are those buses still showing up?

Avada

lxflyer wrote: »

And are those buses still showing up?

Yes, the buses nearly always arrive at the timetabled time

LXFlyer

Random_Name wrote: »

Yes, the buses nearly always arrive at the timetabled time

Well that's odd - it shouldn't be happening.


I don't know why that is taking place.

Avada

lxflyer wrote: »

Well that's odd - it shouldn't be happening.


I don't know why that is taking place.

Neither do I (and I'm not sure Dublin Bus or the NTA know either)

SpaceTime

I nearly missed a flight in Belgium because of this.

I was waiting at a bus stop outside the European Commission for the 21 bus that goes to Brussels airport.

The sign said one was due in 9 mins.

Then after 9 mins ... No bus.

Then a message about Heures théoriques scrolled up meaning it was just making up arrival times based on a schedule.

It turned out it was a public holiday but the signs were running weekday timetable.

48 mins late, a lot of irritated Germans and Dutch board the bus cursing Belgian chaotic systems.

Nobody really understood what the significance of "times may be theoretical" meant until the bus didn't arrive.

markpb

lxflyer wrote: »

Well in the first case it's up to the controller to decide what to do next - either cancel the service altogether or operate a curtailed version along part of the route. No system can account for that as it requires human intervention.

No system can account for it but if the system knew about related departures, it could warn controllers and public alike that delays on the subsequent departure are likely.

n97 mini

Heroditas wrote: »

Yeah definitely agree with you. It happens a lot when I'm getting those buses from Willsbrook or Woodies heading into town.

Yes, agree with that. RTPI could say 50 mins to next bus when between the A and B there should be a bus every 15 mins.

Mrs OBumble

lxflyer wrote: »

Well reading your first line, you are saying that the predictive times that BE have come up with are wrong - therefore the prediction is incorrect in the first place.

Again, the times should be real time - that's what the operator has contracted to provide - as far as the NTA is concerned that's what they should be doing.

If that is not happening (and clearly it is not) I would be suggesting that you write a well phrased letter to both Bus Eireann in Galway and the NTA.

That's why as I've said your issue in the first instance is with Bus Eireann, and not the NTA.

I really don't give a rat's arse about the predictions.

I just expect an app that says it is providing real-time information to do just that - at very least for buses which have left their terminus and are travelling towards me.

This includes showing the best estimate of when the bus will reach me, based on the actual time that it last transmitted data (I'd expect that to be once a minute) and the timetable predictions.

Frankly, as a private citizen, I don't see it as my responsibility to be a data-collection agent for BE. The times here are so off that they MUST know about it already, unless they're blind!

cdebru

Mrs OBumble wrote: »

I've looked at their predictive times. Agree it's BEs dumbness that has the same inter-stop times at all times.

But it's the NTA's app that is saying "real time" when the data they are showing is purely predictive.

I repeat - I don't have a problem with their predictions. I do have a problem with the app saying "real time" when it absolutely isn't anything resembling real.

I presume, BE system is the same as DB in which case it is real time, but with a predictive element where a bus hasn't started a journey but is due to start a journey which is based on the timetable.

So if bus X is due to leave Galway at 10:30 it will show up on the real times further along the route an expected arrival based on the 10:30 being correct and predicted times to each stop, but once the bus actually starts the journey then it switches to real time based on where the bus is now.

It has to work this way as if it relied completely on real time it could only start to work once the bus had started the journey, meaning you would get zero information in this case until 10:30 if you are at a stop 2 minutes up the road the information would be no buses due then 2 minutes before it arrives it would start working, which would obviously be useless.

This works fine for most departures but falls down if for example the bus due to operate the 10:30 hasn't arrived in Galway by 10:30 then you get the countdown and then it disappears.

cdebru

km991148 wrote: »

Anyone notice buses dropping off the RTPI?

I have noticed this in the past - but standing at a stop this morning and 65b did not come (an entering service bus did however..)

RTPI showed it comming at 7.12.. then.. nothing..

In taxi now - another 20 quid gone grr..

No information was better than wrong information.

Actually sounds like the 65b may have arrived but was not displaying it's destination, it can happen for various reasons faulty destination display, faulty ticket machine, sometimes even if the bus has a mechanical problem, cuts out and is restarted it can blank the destination , or if a ticket machine goes tits up there is no on off switch so the only way to restart it is to turn off the bus remove all power, this blanks the destination screen, it should return when the ticket machine restarts but sometimes they don't.
The driver is not permitted to get out and check the destination screen without turning of the engine, which will blank the screen and make it pointless to get out and check anyway. ( there is a small LCD behind the driver that says what the front is supposed to be showing but they don't always match up)

Just a suggestion if it happens again stick your hand out for the bus entering service if it is the 65b it will stop ( tell him he has no scrolls), if it isn't nothing lost anyway, not ideal but you might save yourself €20.

km991148

so.. next morning.. get up 1/2 an hour early to get the earlier 65b (after yesterdays mess).. get to the bus stop at around 12 mins to 7 as (bus was showing on RTPI as scheduled for Terenure at 7:56) - as I approach the bus stop another entering service bus zooms past - definitely not with a broken sign as all lights were off etc.

Still no sign of a bus..

I am beginning to suspect this is not the actions of poorly designed RTPI - but the actions of drivers exploiting a poorly designed system.

Someone at DB must take responsibility.

km991148

ok.. 2nd bus came - so based on 2 days, 4 buses were due but only 2 turned up..

Sean9015

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.

To pick up on lxflyers comment about diversions, at least one system did once have this capability in some form. The Williams Industries - later ACIS - Busnet system as originally implemented in Nottinghamshire and Suffolk did not originally use timetable databases to build the predictions. Each display was programmed with which routes went past it, and the compass direction (with a mask) they would be heading in. Bus locations were sent out on open channels, with the GPS giving an accurate time sync for each message. The stop then built its own prediction profile based on the preceding vehicles, wit an algorithm weighting the most recent. This was surprisingly effective, with accurate predictions being built up after 3-4 journeys. If a diversion took place therefore (eg for roadworks) the system could adjust the predictions very quickly and, importantly, without user intervention. Manual intervention was only required if a stop was actually left unserved.

The problem with this system was limited capacity - IIRC it was about 100 buses per channel, but an unlimited number of displays. There could also be issues over the scheduled / predicted times mentioned if the predicted time was more than a few minutes away from the scheduled, as the system sometimes would not clear the scheduled time off the display, leading to confusion especially if the bus was early (I know, there is every excuse for lateness, but none for early running, but it happened). There were also other issues, as the systems of the time were unable to link to ticketing machines so the driver had to set a second box - a challenge to achieve when the "spy in the cab" mentality was present. The stop displays were also more expensive, as they had to have processing power whereas other systems with central prediction processing could just use pager style recievers, although the latter could not be proved remotely.

A change in staff at ACIS lead to the approach being abandoned for a database / GPS / Odometer approach, which required more intrervention - and therefore staffing costs - which led to Nottinghamshire eventually shutting down their system.

LXFlyer

km991148 wrote: »

so.. next morning.. get up 1/2 an hour early to get the earlier 65b (after yesterdays mess).. get to the bus stop at around 12 mins to 7 as (bus was showing on RTPI as scheduled for Terenure at 7:56) - as I approach the bus stop another entering service bus zooms past - definitely not with a broken sign as all lights were off etc.

Still no sign of a bus..

I am beginning to suspect this is not the actions of poorly designed RTPI - but the actions of drivers exploiting a poorly designed system.

Someone at DB must take responsibility.

km991148 wrote: »

ok.. 2nd bus came - so based on 2 days, 4 buses were due but only 2 turned up..

OK leaving aside the RTPI issues, reading your posts, I'm assuming that you're going for the 06:30 or 06:50 departures on the 65b outbound from the city.

From experience (I used to use the 65 and 65b on a daily basis outbound from Terenure in the early mornings for five years) I would expect them to take around 12-20 minutes to appear in Terenure, depending on traffic.

Therefore I'd expect that the first one should appear between 06:40-06:50, and the second one between 07:00-07:10.

I suspect you missed the first one this morning - it would probably have passed a couple of minutes earlier than 06:48.

Depending on where you are going, if you miss either of these you should take a 49 or 65 and connect to another route in Tallaght if necessary - they both intersect with the 77a in Tallaght if you are going to Citywest, rather than forking out €20 for a taxi.

Getting back to the predictive times, looking at the journey planner there appears to be an error in the RTPI predictive times as there is no way it would take 26 minutes at that hour of the morning for the bus to get to Terenure. The predictive times appear to have changed on the journey planner recently, and looking at the older times (which for some reason are still there) they were giving each bus 16 minutes to get to Terenure, which was closer to the mark.

What I don't understand is why the real times are not overwriting the predictive times.

What are you using to look at the real time? An on-street display, Dublin Bus app or NTA Journey planner?

LXFlyer

Mrs OBumble wrote: »

I really don't give a rat's arse about the predictions.

I just expect an app that says it is providing real-time information to do just that - at very least for buses which have left their terminus and are travelling towards me.

This includes showing the best estimate of when the bus will reach me, based on the actual time that it last transmitted data (I'd expect that to be once a minute) and the timetable predictions.

Frankly, as a private citizen, I don't see it as my responsibility to be a data-collection agent for BE. The times here are so off that they MUST know about it already, unless they're blind!

Perhaps I tend to be more civic minded - I always tend to be pro-active when I see things like this as (from experience) in many cases I've found that the transport companies may not be aware of things like this.


There's never any substitute for customer feedback.