|
|
| Re: Disaster At The Community Board Meeting (1385608) | |||
 |
|||
| Home > SubChat | |||
|
[ Read Responses | Post a New Response | Return to the Index ] |
|
||
|
Re: Disaster At The Community Board Meeting |
|
|
Posted by Stephen Bauman on Mon Feb 15 11:06:48 2016, in response to Re: Disaster At The Community Board Meeting, posted by AlM on Mon Feb 15 10:07:37 2016. If you're running 30 tph, and that's all the system can be managed to handle, then a delay of an M train causes a delay behind that can't be recovered from until rush hour is over.The greater the service level, the more precise the schedule needs to be and the less tolerance there will be for deviations from that schedule. That's assuming the schedule does not generate the switching conflicts, which my schedule extract shows they do. This applies to the entire system. It's a problem that's not unique to grade crossings. If NYCT cannot manage 30 tph at a grade crossing, they will not be able to manage 30 tph anywhere in the system. Here's an extract that shows the TA's thinking regarding precision on schedules. Google set up a format for displaying real time transit data. Here's the TA's explanation of how they represent time of day. 021150 – This identifies the trips origin time. Times are coded reflecting hundredths of a minute past midnight and converts to (03:31:30 also described as 0331+ where the + equals 30 seconds). This format provides more "precision" than can be realistically attributed to a transit operation, and most applications can safely round or truncate these numbers to the nearest minute. Since Transit authority internal timetables frequently involve half-minute scheduling, systems involved in train control or monitoring will need to represent times in a more accurate manner (to at least the half minute, and perhaps to the tenth minute or one second level) |
|
(There are no responses to this message.)
|
|