|
Post by northerner on Mar 31, 2013 20:02:48 GMT 1
I completely agree but I don't think they adopt a zero-tolerance approach to drivers who run early. The original service I emailed them about is an hourly, Metro supported service and I think if the service receives a subsidy that money should be forfeited if a timing point is passed early. Even if it was geniunely human error the operator should have a duty to get any passengers who missed the bus to their destination if the next bus is at least 30 minutes away.
|
|
kuyoyo
Forum Member
Posts: 106
|
Post by kuyoyo on Mar 31, 2013 23:51:17 GMT 1
It would still be unacceptable for a bus to leave early in those circumstances. I have emailed Transdev Keighley a few times about some of their services routinely running early to which their standard, probably pre-typed response is 'human error'. Whilst this may be the case on the odd occasion, it doesn't excuse why the service controllers aren't picking up on it and why the planners aren't rescheduling the services. The other week I was on a 760 service which arrived at a timing point 4 minutes before its due time so the driver pulled up, checked the running board, then departed 2 minutes early anyway and earlier this week I ended up walking as the driver on the half hourly service I was intending to travel on sped past the timing point 3 minutes early How can it be human error, that response is so insulting and patronising. The bus runs to a timetable, stick to it, its not rocket science. If your supposed to leave a timing point at 40 minutes past leave at 40 minutes past not 38 or 39!!! Its just another case of the operators doing their own thing and bugger the passengers. They should be hammering it into the drivers and taking disciplinary action against drivers who run early. The Bus leaving at 39 is classed as on-time, the VOSA define 'on time' as from 1 minute early upto 5 minutes late.
|
|
|
Post by Kenton Schweppes on Apr 1, 2013 10:27:07 GMT 1
How can it be human error, that response is so insulting and patronising. The bus runs to a timetable, stick to it, its not rocket science. If your supposed to leave a timing point at 40 minutes past leave at 40 minutes past not 38 or 39!!! Its just another case of the operators doing their own thing and bugger the passengers. They should be hammering it into the drivers and taking disciplinary action against drivers who run early. The Bus leaving at 39 is classed as on-time, the VOSA define 'on time' as from 1 minute early upto 5 minutes late.Irrespective of that, passengers are not interested in VOSA specifications, if they read the timetable and it says it leaves at 40 minutes past and it leaves at 39 minutes past its early. Why publish timetables then, if buses have leeway to run early or a bit late? This is the kind of thing that annoys passengers and that's why passengers are deserting bus services and that's why Metro want to force the QC's on the area. Operators are their own worst enemies at times, they really are. Where as I agree the need for industry operating specifications. There should be no leeway on slack operating on timetables. Passengers come first,simple as that.
|
|
BusNut
Forum Member
Posts: 154
|
Post by BusNut on Apr 1, 2013 11:25:06 GMT 1
The Bus leaving at 39 is classed as on-time, the VOSA define 'on time' as from 1 minute early upto 5 minutes late. Irrespective of that, passengers are not interested in VOSA specifications, if they read the timetable and it says it leaves at 40 minutes past and it leaves at 39 minutes past its early. Why publish timetables then, if buses have leeway to run early or a bit late? This is the kind of thing that annoys passengers and that's why passengers are deserting bus services and that's why Metro want to force the QC's on the area. Operators are their own worst enemies at times, they really are. Where as I agree the need for industry operating specifications. There should be no leeway on slack operating on timetables. Passengers come first,simple as that. By whos time/watch do you say it left early though?
|
|
|
Post by Kenton Schweppes on Apr 1, 2013 12:17:58 GMT 1
The timetable is set by GMT,as I would expect the ticket machines to be set by GMT plus any real time information to be as well.
I set my time pieces by GMT and I would expect everyone else too as well,that is standard time for Britain,so I would expect any timetables to run to GMT.
If your own personal time piece isn't set to GMT then,I'll side with the bus operator on this one,its your own fault if you miss the bus,but early running is just not acceptable.
|
|
|
Post by stevieinselby on Apr 1, 2013 16:53:08 GMT 1
Isn't real time information operated via satellite tracking? I thought that's what actually made it so useful. If the bus is being tracked by a satellite then surely the info is going to be correct? The information is only as good as the data that is received. Sometimes buses don't seem to get logged properly, so even when they are running normally (or maybe just a few minutes late) they don't show up with live times. And if a bus is seriously delayed, diverted or whatever else, that's when it is most likely to not be tracked. And there's no way for the system to record buses that are cancelled. In all of these cases, the system just shows scheduled times. Yes, when the buses are running approximately normally and they all get tracked properly, the system doesn't need manual intervention ... but we need to be honest and acknowledge that that isn't always the case!
|
|
158757
Forum Member
Posts: 176
|
Post by 158757 on Apr 1, 2013 19:41:00 GMT 1
I've had the metro yournextbus system show a bus as cancelled before.
|
|
|
Post by dwarfer1979 on Apr 2, 2013 9:16:17 GMT 1
See this is the main problem, First ticket machines include the technology for real time info but non of the other operators do,making the whole system disjointed. Either no one has it or everyone has it, its just pointless one company operating with the technology and the others just doing their own thing. This is why customers and Metro are hacked off with the bus network and expressed a desire for change. Honestly, if a normal business acted like this they would've been put out of business months ago. Its so amateurish and is not good for the network. There is need for a strategy throughout West Yorkshire to set out some objectives to be achieved asap, so what needs to happen is Metro need to develop a plan get all operators round the table, tell them what is expected and needed and see if they can take it forward. Left to their own devices the operators will not quickly implement any changes in unison or quickly enough. The thing is, Metro have set out their expectations and objectives, they're called QC's. The West Yorkshire system doesn't run off the ticket machines (or at least it doesn't have to) it is a simple box plugged into the ticket machine so it knows what journey it is working to produce real time. All Centrebus vehicles except K-Line (and I assume they will get it with their new ticket machines over the summer) have vehicle tracking fitted (and it should be working) however we hadn't got the schedules quite working to give the flow through from inbound to outbound reading (though that should be done now or very soon - certainly the base standard Centrebus output that works elsewhere has been sent to Metro). It is actually a hell of a lot of work and a very complicated job to get real time systems set up and working properly, not helped by the fact that each authority area often has different data requirements for RTI data input - so data set up in a style that works for one authority may be rejected by another despite using the same base system, not too much of an issue if you only supply to one authority but if you are supplier similar data to many authorities and each has to be slightly different in how the data is laid out it becomes almost impossible to manage. Too set this up you have to program every bus stop into every route, including a standard location code, using standard names that don't tend to have any reference to the name used on the public timetables, and allocate times for every stop for every journey. This then has to be linked to the scheduling system (assuming you have one - I suspect the main issue for the small operators is that they don't actually use a scheduling system that can be used to provide RTI data, an excel spreadsheet as many smaller operators us to produce their duty boards can't supply the info in the right form) and that data then has to be modified and fiddled with to get it into a compatible form that can export to the RTI system. An export is then produced and sent to the local authority (or their RTI system supplier) who then check it over and request changes to make it fit (for the early versions as you are setting it up this can take days or weeks of too-ing and fro-ing to get the data in the correct form, later versions should be quicker). The bigger groups can probably afford to dedicate one person to this permanently but the smaller operators probably have to incorporate this into someone else's role and it can be a time consuming process (my colleagues need about 2 months of concentrated work for a 40 vehicle pvr depot)
|
|
|
Post by Kenton Schweppes on Apr 2, 2013 14:12:01 GMT 1
See this is the main problem, First ticket machines include the technology for real time info but non of the other operators do,making the whole system disjointed. Either no one has it or everyone has it, its just pointless one company operating with the technology and the others just doing their own thing. This is why customers and Metro are hacked off with the bus network and expressed a desire for change. Honestly, if a normal business acted like this they would've been put out of business months ago. Its so amateurish and is not good for the network. There is need for a strategy throughout West Yorkshire to set out some objectives to be achieved asap, so what needs to happen is Metro need to develop a plan get all operators round the table, tell them what is expected and needed and see if they can take it forward. Left to their own devices the operators will not quickly implement any changes in unison or quickly enough. The thing is, Metro have set out their expectations and objectives, they're called QC's. The West Yorkshire system doesn't run off the ticket machines (or at least it doesn't have to) it is a simple box plugged into the ticket machine so it knows what journey it is working to produce real time. All Centrebus vehicles except K-Line (and I assume they will get it with their new ticket machines over the summer) have vehicle tracking fitted (and it should be working) however we hadn't got the schedules quite working to give the flow through from inbound to outbound reading (though that should be done now or very soon - certainly the base standard Centrebus output that works elsewhere has been sent to Metro). It is actually a hell of a lot of work and a very complicated job to get real time systems set up and working properly, not helped by the fact that each authority area often has different data requirements for RTI data input - so data set up in a style that works for one authority may be rejected by another despite using the same base system, not too much of an issue if you only supply to one authority but if you are supplier similar data to many authorities and each has to be slightly different in how the data is laid out it becomes almost impossible to manage. Too set this up you have to program every bus stop into every route, including a standard location code, using standard names that don't tend to have any reference to the name used on the public timetables, and allocate times for every stop for every journey. This then has to be linked to the scheduling system (assuming you have one - I suspect the main issue for the small operators is that they don't actually use a scheduling system that can be used to provide RTI data, an excel spreadsheet as many smaller operators us to produce their duty boards can't supply the info in the right form) and that data then has to be modified and fiddled with to get it into a compatible form that can export to the RTI system. An export is then produced and sent to the local authority (or their RTI system supplier) who then check it over and request changes to make it fit (for the early versions as you are setting it up this can take days or weeks of too-ing and fro-ing to get the data in the correct form, later versions should be quicker). The bigger groups can probably afford to dedicate one person to this permanently but the smaller operators probably have to incorporate this into someone else's role and it can be a time consuming process (my colleagues need about 2 months of concentrated work for a 40 vehicle pvr depot) You make some valid points there Dwarfer mate and I assume you work for one of West Yorkshire's operators, judging by your response? I understand the difficulty in getting systems to Web ADI into the main system as in my line of work we have used and had difficulty with them. Under the QC proposals would this fall into Metro's remit to control and operate any RTI system? If there is to be any improvement and for the systems to become the norm and work efficiently would it not be a good idea for Metro to take over and specialise in RTI and the more technological side of the improvements needed to take the the bus network forward. They would have more resources at there disposal and be able to manage the system easier than a small operator who do not have the man power or the expertise.
|
|
|
Post by dwarfer1979 on Apr 3, 2013 8:26:20 GMT 1
The West Yorkshire system doesn't run off the ticket machines (or at least it doesn't have to) it is a simple box plugged into the ticket machine so it knows what journey it is working to produce real time. All Centrebus vehicles except K-Line (and I assume they will get it with their new ticket machines over the summer) have vehicle tracking fitted (and it should be working) however we hadn't got the schedules quite working to give the flow through from inbound to outbound reading (though that should be done now or very soon - certainly the base standard Centrebus output that works elsewhere has been sent to Metro). It is actually a hell of a lot of work and a very complicated job to get real time systems set up and working properly, not helped by the fact that each authority area often has different data requirements for RTI data input - so data set up in a style that works for one authority may be rejected by another despite using the same base system, not too much of an issue if you only supply to one authority but if you are supplier similar data to many authorities and each has to be slightly different in how the data is laid out it becomes almost impossible to manage. Too set this up you have to program every bus stop into every route, including a standard location code, using standard names that don't tend to have any reference to the name used on the public timetables, and allocate times for every stop for every journey. This then has to be linked to the scheduling system (assuming you have one - I suspect the main issue for the small operators is that they don't actually use a scheduling system that can be used to provide RTI data, an excel spreadsheet as many smaller operators us to produce their duty boards can't supply the info in the right form) and that data then has to be modified and fiddled with to get it into a compatible form that can export to the RTI system. An export is then produced and sent to the local authority (or their RTI system supplier) who then check it over and request changes to make it fit (for the early versions as you are setting it up this can take days or weeks of too-ing and fro-ing to get the data in the correct form, later versions should be quicker). The bigger groups can probably afford to dedicate one person to this permanently but the smaller operators probably have to incorporate this into someone else's role and it can be a time consuming process (my colleagues need about 2 months of concentrated work for a 40 vehicle pvr depot) You make some valid points there Dwarfer mate and I assume you work for one of West Yorkshire's operators, judging by your response? I understand the difficulty in getting systems to Web ADI into the main system as in my line of work we have used and had difficulty with them. Under the QC proposals would this fall into Metro's remit to control and operate any RTI system? If there is to be any improvement and for the systems to become the norm and work efficiently would it not be a good idea for Metro to take over and specialise in RTI and the more technological side of the improvements needed to take the the bus network forward. They would have more resources at there disposal and be able to manage the system easier than a small operator who do not have the man power or the expertise. I work for Centrebus (though naturally any comments on any internet groups are entirely my own and nothing to do with my employers) though at Head Office at Leicester rather than in West Yorkshire, though all back office (including schedules - largely just me for the whole of Centrebus - & RTI) are done centrally in Leicester for all Centrebus & associated companies. Metro control & operate the RTI system currently so QCs wouldn't make any difference the issue is the integration of the operators schedules with the Local authorities real-time systems and that would have to remain under the operators control as they have to schedule their own staff (you couldn't have the local authority do that even under QCs as union agreements on schedules will vary from operator to operator and as such have to be negotiated locally). It would, however, be perfectly possible for the local authority to produce the base timetable files for an operator with all the stop level data added in (they have a copy of our registrations with route descriptions, maps & timetables and probably have better access to the necessary stop lists and the like than the operators do) and they could even if they wished take copies of a smaller operators schedules & enter it into an appropriate system for export to the RTI system. This is all possible under the current set-up (we currently supply a set of schedules at every change - not set up for RTI - to Metro to enable their service monitors to work out vehicle workings for tendered journey checking) but Metro have probably had bigger fish to fry (like getting the equipment fitted to everyone). Now that the equipment is becoming more widespread it may well be part of the next phase to get the system operating on more operators (I am not privy to the inner workings of the Metro mind). There is some debate as to whether any smaller operators will survive under a QC regime, in part it does depend on how the QC packages are structured but London doesn't hold out much hope (there are two non-big groups surviving on London tendered work - one is a very large community transport operator (HCT who also run school buses in West Yorkshire & Hull P&R) & the other an operator (Sullivans Buses) who does more work outside TfL tendering than in it, so in both cases they aren't reliant on TfL for their continuing survival). It all depends on how the packages are structured and sized, Nexus want to tender everything in one big deal which means only the largest groups could win them, Metro is looking smaller and may have been planning to offer some packages small enough for a little guy to take on but if they don't ensure you can't bundle batches of routes together into a super package then the big guys can take all with a heavily discounted bid for all services - and under QCs you don't have the allowance for the normal small guy response to big packages which is to register the best route commercially to break the package & they can then win selected smaller stuff with their cheaper individual prices.
|
|