<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Bad Reliability Metrics</title>
	<atom:link href="http://seattletransitblog.com/2010/02/04/bad-metrics/feed/" rel="self" type="application/rss+xml" />
	<link>http://seattletransitblog.com/2010/02/04/bad-metrics/</link>
	<description>Transit in the Greater Seattle Area</description>
	<lastBuildDate>Sat, 26 May 2012 05:09:07 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Andrew</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103986</link>
		<dc:creator>Andrew</dc:creator>
		<pubDate>Sun, 07 Feb 2010 22:16:57 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103986</guid>
		<description>First of all, commuters won&#039;t notice nor care, because there isn&#039;t a schedule. It only says the trains depart every 7, 10 or 15 minutes. People arrive to the station just to catch the next train since they run so frequently.

Plus, Seattle&#039;s light-rail isn&#039;t even a year old. Wait until we have a vast 100-mile light-rail/subway network, and then you&#039;ll see consistant departure times and an organized system. It takes time for an infrastructure to take place.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
First of all, commuters won&#8217;t notice nor care, because there isn&#8217;t a schedule. It only says the trains depart every 7, 10 or 15 minutes. People arrive to the station just to catch the next train since they run so frequently.</p>
<p>Plus, Seattle&#8217;s light-rail isn&#8217;t even a year old. Wait until we have a vast 100-mile light-rail/subway network, and then you&#8217;ll see consistant departure times and an organized system. It takes time for an infrastructure to take place.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nathanael</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103799</link>
		<dc:creator>Nathanael</dc:creator>
		<pubDate>Sun, 07 Feb 2010 07:51:04 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103799</guid>
		<description>OK, so (a) and (b) are actually different.

Suppose a train arrives 4 minutes late and then departs 30 seconds late for the next run.

It is late by definition (b) but not definition (a).

Dunno why they set up this complicated definition though.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
OK, so (a) and (b) are actually different.</p>
<p>Suppose a train arrives 4 minutes late and then departs 30 seconds late for the next run.</p>
<p>It is late by definition (b) but not definition (a).</p>
<p>Dunno why they set up this complicated definition though.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Doppmann</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103487</link>
		<dc:creator>Jeff Doppmann</dc:creator>
		<pubDate>Fri, 05 Feb 2010 20:29:56 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103487</guid>
		<description>All we really need would be a light positioned in view of the cab while berthed at the station which would turn on when the signal system would not accept a LRV request without a delay.

If the light is not lit - we would immediately request the LRV signal after arriving at the station. If lit we would wait until the light turns off before making the request.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
All we really need would be a light positioned in view of the cab while berthed at the station which would turn on when the signal system would not accept a LRV request without a delay.</p>
<p>If the light is not lit &#8211; we would immediately request the LRV signal after arriving at the station. If lit we would wait until the light turns off before making the request.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Dublin</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103476</link>
		<dc:creator>Mark Dublin</dc:creator>
		<pubDate>Fri, 05 Feb 2010 19:49:13 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103476</guid>
		<description>Martin, you&#039;re doing right by insisting on good metrics: the information decsionmakers truly need to run a transit system, accurately reported. You&#039;re also fighting global warming. Millions of acres of woodland are felled for paper, and trillions of BTU&#039;s are released powering computers to process information that businesses and agencies put out to generate numbers they pray nobody will read.

But as a transit driver who was on a committee that helped design this system, this exercise seems like a movie where somebody invents a time-machine so he can go back and apply computer-generated batting averages seven and a half months after Abner Doubleday invents baseball.

A 7.5 minute headway regional rail line that shares a mile-long four-stop downtown subway with scores of buses,and then runs four miles of surface track with dozens of street and pedestrian crossings, with another agency in control of its signals...that&#039;s going to take some practice.

Just remove the buses? While you&#039;re at it, just get our signals back from SDOT too. While somebody&#039;s working on those things, which could take awhile, people have to figure out how to make what we&#039;ve got work- people who read STB. You know who you are, and most of you are doing great. 


Anybody been to Essen, Germany? Somebody posted a YouTube video of a system there where streetcars share stations and track with dual-power trolleybuses (poles and all!) with guided steering? If so, please either post or comment-this could be the only system in the world comparable to ours. 

Not only stats, but firsthand report from there would help a lot.

Mark Dublin</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
Martin, you&#8217;re doing right by insisting on good metrics: the information decsionmakers truly need to run a transit system, accurately reported. You&#8217;re also fighting global warming. Millions of acres of woodland are felled for paper, and trillions of BTU&#8217;s are released powering computers to process information that businesses and agencies put out to generate numbers they pray nobody will read.</p>
<p>But as a transit driver who was on a committee that helped design this system, this exercise seems like a movie where somebody invents a time-machine so he can go back and apply computer-generated batting averages seven and a half months after Abner Doubleday invents baseball.</p>
<p>A 7.5 minute headway regional rail line that shares a mile-long four-stop downtown subway with scores of buses,and then runs four miles of surface track with dozens of street and pedestrian crossings, with another agency in control of its signals&#8230;that&#8217;s going to take some practice.</p>
<p>Just remove the buses? While you&#8217;re at it, just get our signals back from SDOT too. While somebody&#8217;s working on those things, which could take awhile, people have to figure out how to make what we&#8217;ve got work- people who read STB. You know who you are, and most of you are doing great. </p>
<p>Anybody been to Essen, Germany? Somebody posted a YouTube video of a system there where streetcars share stations and track with dual-power trolleybuses (poles and all!) with guided steering? If so, please either post or comment-this could be the only system in the world comparable to ours. </p>
<p>Not only stats, but firsthand report from there would help a lot.</p>
<p>Mark Dublin<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Dublin</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103459</link>
		<dc:creator>Mark Dublin</dc:creator>
		<pubDate>Fri, 05 Feb 2010 18:51:11 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103459</guid>
		<description>Route 8 or 48 and a bike might work better- downhill from Madison and MLK. Not making light of the problem- but real embarrassment is having a route like the 11 on an hour headway before midnight any night.

Remember having a Vancouver BC trolleydriver apologize to me because after 10PM the Route 4 Commercial Street line went from 4 to 8-minute headways.

Not making excuses, either. Whatever problems LINK has keeping on time have to be worked out. But I doubt any bullet-train line worldwide has to worry about city bus shedules that really say: &quot;After 9PM, call a cab.&quot;

Mark Dublin</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
Route 8 or 48 and a bike might work better- downhill from Madison and MLK. Not making light of the problem- but real embarrassment is having a route like the 11 on an hour headway before midnight any night.</p>
<p>Remember having a Vancouver BC trolleydriver apologize to me because after 10PM the Route 4 Commercial Street line went from 4 to 8-minute headways.</p>
<p>Not making excuses, either. Whatever problems LINK has keeping on time have to be worked out. But I doubt any bullet-train line worldwide has to worry about city bus shedules that really say: &#8220;After 9PM, call a cab.&#8221;</p>
<p>Mark Dublin<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Oran Viriyincy</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103439</link>
		<dc:creator>Oran Viriyincy</dc:creator>
		<pubDate>Fri, 05 Feb 2010 17:33:42 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103439</guid>
		<description>Right, thanks for the detailed explanation. I think you talked about that at the last meetup and it matches what the SDOT signal guy showed me while they were testing the thing.

I don&#039;t know what kind of information the control center has access to but showing how many seconds before the next full signal cascade is possible would be helpful.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
Right, thanks for the detailed explanation. I think you talked about that at the last meetup and it matches what the SDOT signal guy showed me while they were testing the thing.</p>
<p>I don&#8217;t know what kind of information the control center has access to but showing how many seconds before the next full signal cascade is possible would be helpful.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Adam B. Parast</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103359</link>
		<dc:creator>Adam B. Parast</dc:creator>
		<pubDate>Fri, 05 Feb 2010 10:11:07 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103359</guid>
		<description>Wow Jeff thanks for that!

One question about when you have to wait for some kind of delay. What are the procedure for announcements for riders in those situations?</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
Wow Jeff thanks for that!</p>
<p>One question about when you have to wait for some kind of delay. What are the procedure for announcements for riders in those situations?<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Adam B. Parast</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103358</link>
		<dc:creator>Adam B. Parast</dc:creator>
		<pubDate>Fri, 05 Feb 2010 10:04:27 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103358</guid>
		<description>I&#039;ll have to read that manual. I&#039;m not familiar with it.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
I&#8217;ll have to read that manual. I&#8217;m not familiar with it.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Adam B. Parast</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103357</link>
		<dc:creator>Adam B. Parast</dc:creator>
		<pubDate>Fri, 05 Feb 2010 10:02:24 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103357</guid>
		<description>This is one of my biggest pet peeves.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
This is one of my biggest pet peeves.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Doppmann</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103355</link>
		<dc:creator>Jeff Doppmann</dc:creator>
		<pubDate>Fri, 05 Feb 2010 09:59:31 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103355</guid>
		<description>The term preempt is probably misused here. The only true preempt on MLK would be the opticom system used by emergency vehicles.

The signal system gets LRV requests by call loops embedded in the trackway. When at stations on MLK the operator pushes a button which starts a timing sequence which if unimpeded by pedestrian walk phases or a signal timeout gives the LRV a proceed through the immediate intersection and the next couple of intersections at a time approximate to when the train would approach each subsequent intersection whether the train leaves the station or not.

The proceed signal will only show for a limited time. If the train is delayed for any reason the proceed indication will timeout requiring the train to stop and recall the signal which can be done at loops located immediately prior to the intersections or crosswalk signals where the train is stopped.

There are a few reasons why the LRV signal proceed indication can be delayed as a train approaches, some which are predictable and some that are hard to figure out. Emergency responses along or crossing MLK will delay the LRV proceed indication until the emergency vehicles clear, If another train travelling in the opposite direction clears the intersection that your train is approaching before that same signal shows a proceed for you - the signal will often go into a short cycle phase for cross traffic then show a proceed for your train (This usually delays the train on approach but not too long to lose the &quot;signal cascade&quot; for subsequent intersections), Occasionally an intersection signal &quot;times out&quot; as a train approaches and makes the train wait for a complete cycle (all traffic gets a green in turn including cross walk phases if requested) before the train gets a proceed - this is hard to predict and time consuming to recover from.

Sometimes the train is delayed getting a proceed signal before it leaves a station for the same reasons listed above. I believe it is better to wait before requesting the LRV signal to avoid a delay if it is obvious that one will occur (the parallel signal just went red as you arrived at the station and pedestrians have started walking across the street) rather than immediately pressing the button as we have been instructed to do. If there were some way for the operator to know when it is a &quot;bad&quot; time to request a LRV signal this could eliminate some of the unnecessary delays of both trains and other vehicles when we have to re-request the LRV signal after a delay (other vehicles have to suffer extra LRV phases when one is &quot;wasted&quot;)

We are still learning the best practice on how to continue after being stopped by a signal between stations. Do you immediately zoom up to each signal stop and request the next all the way to the next station? Or do you wait until the next couple of intersections clear the LRV phase and then push the button possibly giving you the &quot;cascade&quot; back and allowing the train to proceed unimpeded? 

And there are still a couple of pedestrian cross walk signals which fail to give a LRV proceed as a train approaches even though there is no pedestrian traffic and the auto traffic signal stays green. We call them mystery signals (often late at night).

All the above can easily add two to three minutes to the travel time between stations on MLK and if it happens more than once per trip it can cause a delay bad enough to require the following trains to wait at MBS southbound or RBS northbound to ensure they do not bunch up.

Caveat: I could have all this completely wrong. This only comes from my own observations while operating LRVs the last several months.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
The term preempt is probably misused here. The only true preempt on MLK would be the opticom system used by emergency vehicles.</p>
<p>The signal system gets LRV requests by call loops embedded in the trackway. When at stations on MLK the operator pushes a button which starts a timing sequence which if unimpeded by pedestrian walk phases or a signal timeout gives the LRV a proceed through the immediate intersection and the next couple of intersections at a time approximate to when the train would approach each subsequent intersection whether the train leaves the station or not.</p>
<p>The proceed signal will only show for a limited time. If the train is delayed for any reason the proceed indication will timeout requiring the train to stop and recall the signal which can be done at loops located immediately prior to the intersections or crosswalk signals where the train is stopped.</p>
<p>There are a few reasons why the LRV signal proceed indication can be delayed as a train approaches, some which are predictable and some that are hard to figure out. Emergency responses along or crossing MLK will delay the LRV proceed indication until the emergency vehicles clear, If another train travelling in the opposite direction clears the intersection that your train is approaching before that same signal shows a proceed for you &#8211; the signal will often go into a short cycle phase for cross traffic then show a proceed for your train (This usually delays the train on approach but not too long to lose the &#8220;signal cascade&#8221; for subsequent intersections), Occasionally an intersection signal &#8220;times out&#8221; as a train approaches and makes the train wait for a complete cycle (all traffic gets a green in turn including cross walk phases if requested) before the train gets a proceed &#8211; this is hard to predict and time consuming to recover from.</p>
<p>Sometimes the train is delayed getting a proceed signal before it leaves a station for the same reasons listed above. I believe it is better to wait before requesting the LRV signal to avoid a delay if it is obvious that one will occur (the parallel signal just went red as you arrived at the station and pedestrians have started walking across the street) rather than immediately pressing the button as we have been instructed to do. If there were some way for the operator to know when it is a &#8220;bad&#8221; time to request a LRV signal this could eliminate some of the unnecessary delays of both trains and other vehicles when we have to re-request the LRV signal after a delay (other vehicles have to suffer extra LRV phases when one is &#8220;wasted&#8221;)</p>
<p>We are still learning the best practice on how to continue after being stopped by a signal between stations. Do you immediately zoom up to each signal stop and request the next all the way to the next station? Or do you wait until the next couple of intersections clear the LRV phase and then push the button possibly giving you the &#8220;cascade&#8221; back and allowing the train to proceed unimpeded? </p>
<p>And there are still a couple of pedestrian cross walk signals which fail to give a LRV proceed as a train approaches even though there is no pedestrian traffic and the auto traffic signal stays green. We call them mystery signals (often late at night).</p>
<p>All the above can easily add two to three minutes to the travel time between stations on MLK and if it happens more than once per trip it can cause a delay bad enough to require the following trains to wait at MBS southbound or RBS northbound to ensure they do not bunch up.</p>
<p>Caveat: I could have all this completely wrong. This only comes from my own observations while operating LRVs the last several months.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Z</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103330</link>
		<dc:creator>Z</dc:creator>
		<pubDate>Fri, 05 Feb 2010 07:01:23 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103330</guid>
		<description>Except on weekends, where your boss&#039;s frequency on the 194 got cut in half (Presuming he went to seattle). All its really doing is shifting the cost from one agency to another. It&#039;s too bad ST dosent have the added funds to run the 578 on the weekends the same as on the weekdays (although bi-directional all day vs, the weekday schedule). Now the upside with sounder is... You dont get stuck in traffic! Well worth the extra money for me.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
Except on weekends, where your boss&#8217;s frequency on the 194 got cut in half (Presuming he went to seattle). All its really doing is shifting the cost from one agency to another. It&#8217;s too bad ST dosent have the added funds to run the 578 on the weekends the same as on the weekdays (although bi-directional all day vs, the weekday schedule). Now the upside with sounder is&#8230; You dont get stuck in traffic! Well worth the extra money for me.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Fellows</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103329</link>
		<dc:creator>Rob Fellows</dc:creator>
		<pubDate>Fri, 05 Feb 2010 07:00:03 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103329</guid>
		<description>So - the reliability of headways/arrivals and of travel time are both important, but every agency wants to have a single number so they can report something simple.  If you&#039;re waiting for a bus or train, the wait time seems most important because there&#039;s uncertainty about whether you&#039;ll be stood up or not by your ride.  Waiting is more stressful than riding because of the uncertainty and discomfort, which is why people who model ridership add a weighting factor to weight time that&#039;s usually about twice the &quot;cost&quot; of in vehicle time when you&#039;re sitting comfortably reading.  If you&#039;re heading to work you care more about the travel time and arrive time than if you&#039;re heading home in the evening - unless of course you&#039;re trying to connect with a bus.  There&#039;s a lot to this.

There is a manual called the Transit Capacity and Quality of Service manual, which proposes standardized measures that might make it possible to compare one transit service to another.  Unfortunately, for their own reasons, each agency wants to set its own measures and standards, so it&#039;s impossible to compare one to another.  The Transit Capacity manual looks at reliability differently depending on the headway.  For longer headways they look at the variability of arrive times compared to the schedule, since schedules matter on long headways.  For short headways they look at the variability in headways, since nobody knows what the schedule is - the average wait time from the user&#039;s perspective is affected by how regular the headways are, and if they&#039;re unreliable, the average effective weight time is longer and the service is less desirable.

I think the important thing that the Transit Capacity and Quality of Service manual introduces is that it&#039;s the customer experience that matters.  Reliability (and other service measures) need to be rooted in what the customer experiences.  And sometimes that requires more than one measure to understand reliability of both departure and travel times, as well as whether loads are even - since bunching affects both reliability and loading in a similar way.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
So &#8211; the reliability of headways/arrivals and of travel time are both important, but every agency wants to have a single number so they can report something simple.  If you&#8217;re waiting for a bus or train, the wait time seems most important because there&#8217;s uncertainty about whether you&#8217;ll be stood up or not by your ride.  Waiting is more stressful than riding because of the uncertainty and discomfort, which is why people who model ridership add a weighting factor to weight time that&#8217;s usually about twice the &#8220;cost&#8221; of in vehicle time when you&#8217;re sitting comfortably reading.  If you&#8217;re heading to work you care more about the travel time and arrive time than if you&#8217;re heading home in the evening &#8211; unless of course you&#8217;re trying to connect with a bus.  There&#8217;s a lot to this.</p>
<p>There is a manual called the Transit Capacity and Quality of Service manual, which proposes standardized measures that might make it possible to compare one transit service to another.  Unfortunately, for their own reasons, each agency wants to set its own measures and standards, so it&#8217;s impossible to compare one to another.  The Transit Capacity manual looks at reliability differently depending on the headway.  For longer headways they look at the variability of arrive times compared to the schedule, since schedules matter on long headways.  For short headways they look at the variability in headways, since nobody knows what the schedule is &#8211; the average wait time from the user&#8217;s perspective is affected by how regular the headways are, and if they&#8217;re unreliable, the average effective weight time is longer and the service is less desirable.</p>
<p>I think the important thing that the Transit Capacity and Quality of Service manual introduces is that it&#8217;s the customer experience that matters.  Reliability (and other service measures) need to be rooted in what the customer experiences.  And sometimes that requires more than one measure to understand reliability of both departure and travel times, as well as whether loads are even &#8211; since bunching affects both reliability and loading in a similar way.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Z</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103328</link>
		<dc:creator>Z</dc:creator>
		<pubDate>Fri, 05 Feb 2010 06:57:25 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103328</guid>
		<description>If you dont publish the full timetable, its more difficult to assertain if your train is &quot;on time&quot; or not. Of course, its a very nice (although can be large) thing to have when you are taking your trip. But it&#039;s also nice to see all the times down on paper instead of some random &quot;Every 7-8 Minutes&quot;.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
If you dont publish the full timetable, its more difficult to assertain if your train is &#8220;on time&#8221; or not. Of course, its a very nice (although can be large) thing to have when you are taking your trip. But it&#8217;s also nice to see all the times down on paper instead of some random &#8220;Every 7-8 Minutes&#8221;.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: alexjonlin</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103325</link>
		<dc:creator>alexjonlin</dc:creator>
		<pubDate>Fri, 05 Feb 2010 06:34:05 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103325</guid>
		<description>Even if they could just walk over to SODO station, it would lessen delays and be a little nicer.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
Even if they could just walk over to SODO station, it would lessen delays and be a little nicer.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Oran Viriyincy</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103314</link>
		<dc:creator>Oran Viriyincy</dc:creator>
		<pubDate>Fri, 05 Feb 2010 05:36:56 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103314</guid>
		<description>A few bits from the SDOT Blog about Link signal priority on MLK:

&lt;blockquote cite=&quot;http://sdotblog.seattle.gov/ask-us-a-question/comment-page-4/#comment-322&quot;&gt;
The signals along that corridor are designed to accommodate trains operating at 7.5 minute spacings, matching the Sound Transit schedule. Even if the trains are off schedule by up to 33%, the designed signal timings still work well. However, right now many trains are off by more than 33%. Shorter train spacings result in longer wait times for the north and south bound left turns at some locations, including Dawson. Our next step to improve your wait time there is to work with Sound Transit to see what we can do to resolve the train spacing problem. I’ll contact you one-on-one with a little more information. Thanks for checking our blog!
&lt;/blockquote&gt;

&lt;blockquote cite=&quot;http://sdotblog.seattle.gov/ask-us-a-question/comment-page-6/#comment-1675&quot;&gt;
For the majority of the day, the signal cycle length on the MLK corridor is 120 seconds, which would also be the maximum wait time during normal operation. While this may seem like a long time to a person waiting to cross, this is the shortest cycle length we can use that will accommodate serving all phases one time during each signal cycle. If there is any “unused” time, the extra green time goes to MLK.

When the Light Rail train preempts regular signal operation, the wait time can be longer. The “recovery phase” of this signal after preemption by the train currently begins with the westbound through and left turn vehicle movement. Thus, a pedestrian will not receive a “walk” display until the signal completes its cycle. The pedestrian movement will be served in order.

We have put restrictions into place to minimize the interference of normal operation during excessive Light Rail activity (i.e. trains coming rapidly in succession, rather than on schedule). And we will definitely continue to monitor this intersection to determine if additional restrictions are required to balance the needs of all users of this intersection.
&lt;/blockquote&gt;</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
A few bits from the SDOT Blog about Link signal priority on MLK:</p>
<blockquote cite="http://sdotblog.seattle.gov/ask-us-a-question/comment-page-4/#comment-322"><p>
The signals along that corridor are designed to accommodate trains operating at 7.5 minute spacings, matching the Sound Transit schedule. Even if the trains are off schedule by up to 33%, the designed signal timings still work well. However, right now many trains are off by more than 33%. Shorter train spacings result in longer wait times for the north and south bound left turns at some locations, including Dawson. Our next step to improve your wait time there is to work with Sound Transit to see what we can do to resolve the train spacing problem. I’ll contact you one-on-one with a little more information. Thanks for checking our blog!
</p></blockquote>
<blockquote cite="http://sdotblog.seattle.gov/ask-us-a-question/comment-page-6/#comment-1675"><p>
For the majority of the day, the signal cycle length on the MLK corridor is 120 seconds, which would also be the maximum wait time during normal operation. While this may seem like a long time to a person waiting to cross, this is the shortest cycle length we can use that will accommodate serving all phases one time during each signal cycle. If there is any “unused” time, the extra green time goes to MLK.</p>
<p>When the Light Rail train preempts regular signal operation, the wait time can be longer. The “recovery phase” of this signal after preemption by the train currently begins with the westbound through and left turn vehicle movement. Thus, a pedestrian will not receive a “walk” display until the signal completes its cycle. The pedestrian movement will be served in order.</p>
<p>We have put restrictions into place to minimize the interference of normal operation during excessive Light Rail activity (i.e. trains coming rapidly in succession, rather than on schedule). And we will definitely continue to monitor this intersection to determine if additional restrictions are required to balance the needs of all users of this intersection.
</p></blockquote>
<p><!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anandakos</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103312</link>
		<dc:creator>Anandakos</dc:creator>
		<pubDate>Fri, 05 Feb 2010 05:22:55 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103312</guid>
		<description>Jeff,

You have used the term &quot;signal preempt(ion)&quot; in a context that makes me believe that there is an actual element of pre-emption in the system.  

It&#039;s obvious to any rider that the train has no &quot;absolute&quot; pre-emption.  If it misses the green cycle, it&#039;s stabbed over and over until it gets to the next station.  

IS there actual pre-emption, though.  By that I mean, if the train is fifteen seconds late, will the signals hold for it?  If it&#039;s a few seconds early will the yellow for cross traffic come on more rapidly.  

If neither of these is true, then we should stop referring to &quot;pre-emption&quot; and start using &quot;co-ordination&quot; which the system clearly is.  

Thank you.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
Jeff,</p>
<p>You have used the term &#8220;signal preempt(ion)&#8221; in a context that makes me believe that there is an actual element of pre-emption in the system.  </p>
<p>It&#8217;s obvious to any rider that the train has no &#8220;absolute&#8221; pre-emption.  If it misses the green cycle, it&#8217;s stabbed over and over until it gets to the next station.  </p>
<p>IS there actual pre-emption, though.  By that I mean, if the train is fifteen seconds late, will the signals hold for it?  If it&#8217;s a few seconds early will the yellow for cross traffic come on more rapidly.  </p>
<p>If neither of these is true, then we should stop referring to &#8220;pre-emption&#8221; and start using &#8220;co-ordination&#8221; which the system clearly is.  </p>
<p>Thank you.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erik G.</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103284</link>
		<dc:creator>Erik G.</dc:creator>
		<pubDate>Fri, 05 Feb 2010 02:42:06 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103284</guid>
		<description>Why does the driver change have to be at the small platform at the RRRRail facility?

Why not have the new driver just get onboard, and then do the actual switch over at the next station?  At least that way, the doors are open and the customers can get on and off.  Then the &quot;old&quot; driver can just ride the next train back to the RRRRail facility platform.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
Why does the driver change have to be at the small platform at the RRRRail facility?</p>
<p>Why not have the new driver just get onboard, and then do the actual switch over at the next station?  At least that way, the doors are open and the customers can get on and off.  Then the &#8220;old&#8221; driver can just ride the next train back to the RRRRail facility platform.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erik G.</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103283</link>
		<dc:creator>Erik G.</dc:creator>
		<pubDate>Fri, 05 Feb 2010 02:39:07 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103283</guid>
		<description>Yes, but Steve Riggio needs the $$$!</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
Yes, but Steve Riggio needs the $$$!<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mickymse</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103243</link>
		<dc:creator>Mickymse</dc:creator>
		<pubDate>Fri, 05 Feb 2010 00:19:46 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103243</guid>
		<description>Which is another good reason for why riders care more about &quot;late arrival&quot; than &quot;late departure.&quot;

If I expect to take 34(?) minutes to go from Pioneer Square Station to Airport Station, then I could care less if we leave SODO or Mt. Baker one or two minutes late. 

I only care if that makes the trip take three or four minutes longer, and I expect that drivers can find ways to make up the time in certain spots.

This also means that Link could just as easily be consistently &quot;late&quot; in departing a particular station or two on a given day and yet still be &quot;on time&quot; for arrival at my destination.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
Which is another good reason for why riders care more about &#8220;late arrival&#8221; than &#8220;late departure.&#8221;</p>
<p>If I expect to take 34(?) minutes to go from Pioneer Square Station to Airport Station, then I could care less if we leave SODO or Mt. Baker one or two minutes late. </p>
<p>I only care if that makes the trip take three or four minutes longer, and I expect that drivers can find ways to make up the time in certain spots.</p>
<p>This also means that Link could just as easily be consistently &#8220;late&#8221; in departing a particular station or two on a given day and yet still be &#8220;on time&#8221; for arrival at my destination.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Crazy Man</title>
		<link>http://seattletransitblog.com/2010/02/04/bad-metrics/#comment-103233</link>
		<dc:creator>Crazy Man</dc:creator>
		<pubDate>Thu, 04 Feb 2010 23:47:16 +0000</pubDate>
		<guid isPermaLink="false">http://seattletransitblog.com/?p=11980#comment-103233</guid>
		<description>Well, my boss just lucked out.  He had his Metro (milk run) 194 service replaced with enhanced 577/578 ST service!  Now he can come/go any hour of the day with fast bus.

Meanwhile, I&#039;m hamstrung with Sounder/150 -- 23 minutes versus 1 hour!

Still it&#039;s a good trend...getting ST to replace Metro milk runs with &quot;rapid&quot; buses...</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start --><br />
Well, my boss just lucked out.  He had his Metro (milk run) 194 service replaced with enhanced 577/578 ST service!  Now he can come/go any hour of the day with fast bus.</p>
<p>Meanwhile, I&#8217;m hamstrung with Sounder/150 &#8212; 23 minutes versus 1 hour!</p>
<p>Still it&#8217;s a good trend&#8230;getting ST to replace Metro milk runs with &#8220;rapid&#8221; buses&#8230;<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Minified using disk
Page Caching using disk (enhanced)
Database Caching 1/4 queries in 0.002 seconds using disk
Object Caching 424/428 objects using disk

Served from: seattletransitblog.com @ 2012-05-25 22:13:51 -->
