National Academies Press: OpenBook
« Previous: Chapter 8 - Conclusions and Recommendations for Future Data Collection Efforts
Page 79
Suggested Citation:"Appendix A - Project 2 Data Dictionary." National Academies of Sciences, Engineering, and Medicine. 2011. Feasibility of Using In-Vehicle Video Data to Explore How to Modify Driver Behavior That Causes Nonrecurring Congestion. Washington, DC: The National Academies Press. doi: 10.17226/14509.
×
Page 79
Page 80
Suggested Citation:"Appendix A - Project 2 Data Dictionary." National Academies of Sciences, Engineering, and Medicine. 2011. Feasibility of Using In-Vehicle Video Data to Explore How to Modify Driver Behavior That Causes Nonrecurring Congestion. Washington, DC: The National Academies Press. doi: 10.17226/14509.
×
Page 80
Page 81
Suggested Citation:"Appendix A - Project 2 Data Dictionary." National Academies of Sciences, Engineering, and Medicine. 2011. Feasibility of Using In-Vehicle Video Data to Explore How to Modify Driver Behavior That Causes Nonrecurring Congestion. Washington, DC: The National Academies Press. doi: 10.17226/14509.
×
Page 81
Page 82
Suggested Citation:"Appendix A - Project 2 Data Dictionary." National Academies of Sciences, Engineering, and Medicine. 2011. Feasibility of Using In-Vehicle Video Data to Explore How to Modify Driver Behavior That Causes Nonrecurring Congestion. Washington, DC: The National Academies Press. doi: 10.17226/14509.
×
Page 82
Page 83
Suggested Citation:"Appendix A - Project 2 Data Dictionary." National Academies of Sciences, Engineering, and Medicine. 2011. Feasibility of Using In-Vehicle Video Data to Explore How to Modify Driver Behavior That Causes Nonrecurring Congestion. Washington, DC: The National Academies Press. doi: 10.17226/14509.
×
Page 83
Page 84
Suggested Citation:"Appendix A - Project 2 Data Dictionary." National Academies of Sciences, Engineering, and Medicine. 2011. Feasibility of Using In-Vehicle Video Data to Explore How to Modify Driver Behavior That Causes Nonrecurring Congestion. Washington, DC: The National Academies Press. doi: 10.17226/14509.
×
Page 84
Page 85
Suggested Citation:"Appendix A - Project 2 Data Dictionary." National Academies of Sciences, Engineering, and Medicine. 2011. Feasibility of Using In-Vehicle Video Data to Explore How to Modify Driver Behavior That Causes Nonrecurring Congestion. Washington, DC: The National Academies Press. doi: 10.17226/14509.
×
Page 85
Page 86
Suggested Citation:"Appendix A - Project 2 Data Dictionary." National Academies of Sciences, Engineering, and Medicine. 2011. Feasibility of Using In-Vehicle Video Data to Explore How to Modify Driver Behavior That Causes Nonrecurring Congestion. Washington, DC: The National Academies Press. doi: 10.17226/14509.
×
Page 86

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

A P P E N D I X A Project 2 Data DictionaryMotivation and intent were important criteria. The motivations behind the driver’s actions, when able to be clearly determined, weighed more heavily than actual behaviors. Events were coded according to judgment with respect to why the alert went off— as though one was looking through the eyes of the driver. Time of Day Dusk was difficult to classify as either day or night; this classi- fication was subjective. Events were coded to reflect whichever the clip was most similar to, day or night. • 0 = Day. • 1 = Night. Road Condition Glare and reflection helped determine whether the road was dry or wet. • 0 = Dry. • 1 = Wet. (Any moisture on the road led to the classification as wet; there did not need to be standing water. The road was classified as wet if it was wet from snow but not snow covered.) • 2 = Snow covered (Snow covered would have included ice covered if it was observed, but it was never observed. If any portion of the road, including turn lanes, was covered in snow, then the classification was snow covered.) Precipitation Spots on the windshield or wiper activity helped determine if there was in fact precipitation. • 0 = None. • 1 = Rain. (Light rain and drizzle were classified as rain, as were downpours.)79• 2 = Snow. (This category included sleet. Several cues helped indicate if the precipitation was in fact snow; snow tended to be larger and fall more slowly than rain, it looked like white flurries and was also present on the ground, reinforcing the classification as snow. Also, precipitation that occurred in December through February was assumed to be snow, not rain. Snow could be coded in other months, but the assump- tion that the precipitation was snow was not as strong.) Location of Eyes at Time of the Alert This category was coded at the actual time of the alert, when the radar display showed 100 for the alert level. Eye location was coded by what the reviewers could see of the driver’s eyes at the time of the alert, even if they could not see the eyes preceding the alert. Reviewers coded the location of the driver’s eyes even if they could see only one eye because it was assumed that the driver’s eyes moved in parallel. Because of the absence of an eye-tracking camera and the limitations of the face camera, some ambiguity often existed about where the drivers were looking. Reviewers needed to be confident in the location of the driver’s eyes in order to code as a specific location. In many instances, the reviewers were confident that the driver’s eyes were not looking forward but could not tell specifically where the eyes were looking. These instances were coded as 8s. One such example is when the driver appeared to be looking at the camera. In this situation, it was difficult to determine if the driver was looking at the camera intention- ally, glancing out the corner, or looking slightly out the left window; therefore, it was coded as an 8. The determination of whether glances were still forward or if they were away was also difficult and subjective. Reviewers agreed on an area or “box” that they considered to be looking forward; this allowed for slight glances but even many scans across the forward scene were considered glances away. This process defined “looking forward” narrowly and essentially meant straight forward.

80Glances toward the right of the forward scene, the right area of the windshield, were glances away and were coded as 8s. • 0 = Looking forward at forward scene. (Looking forward included looking at the head-up display [HUD].) • 1 = Left outside mirror or window. • 2 = Looking over left shoulder. (The driver’s gaze needed to look over the driver’s shoulder, although the driver’s chin did not necessarily need to cross over the driver’s shoulder.) • 3 = Right outside mirror or window. • 4 = Looking over right shoulder. (The driver’s gaze needed to look over the driver’s shoulder, although the driver’s chin did not necessarily need to cross over the driver’s shoulder.) • 5 = Head down, looking at instrument panel or lap area. (Looking at the HUD was not considered part of the instru- ment panel.) • 6 = Head down, looking at center stack console area. (Con- sole means the area in which the stereo, thermostat, and clock are located.) • 7 = Driver wearing sunglasses or glasses with glare. (Glare prohibited the ability to classify where the eyes were look- ing. In some instances, drivers were wearing sunglasses, but the reviewers thought that they could confidently iden- tify the location of the drivers’ eyes. In these instances, eye location was recorded.) • 8 = Cannot accurately evaluate eye location. (An 8 was cho- sen when the reviewer was unsure of the eye position or classification within a reasonable level of confidence but not because of glasses. Typically, the reviewer could see the actual eye but could not determine where the gaze was directed. Eyes in transition were often coded as 8 because it was unclear where the driver’s gaze was at that particular moment.) • 9 = Other. (For example, the driver may clearly be look- ing at the passenger side floor. When a glance was coded as other, the location was noted in the notes section. The most common position recorded as other was the rearview mirror.) Location of Eyes During the Last Nonforward Glance and Time from the Last Nonforward Glance If the driver’s eyes were on the forward scene at the moment of the alert but had looked away during some portion of the clip previous to the alert, this location was recorded. The reviewers also recorded the amount of time between when the driver’s gaze began to return to the forward scene and the moment of the alert, according to the radar display showing alert level 100. We did not count the actual moment of the alert; the time rep-resents the time between the change in gaze and the alert. Time was recorded in 10ths of seconds. If the driver was always look- ing forward, then the time from the last nonforward glance was left null because that category was not applicable. If the driver was looking away 0.1 s before the alert and then was looking forward at the time of the alert, the time from the last nonfor- ward glance was recorded as 0. If the driver’s eyes were not visible, typically because of glare, for any portion of the clip, the location was coded as a 7 because one could not be certain there was not a glance away. The only exception to this rule was when the reviewers could not see the driver’s eyes and then the eyes became visible so that the reviewers could see the eyes and there was a glance away before the alert. This situation negates the fact that the reviewers could not see the eyes at the begin- ning of the clip, because there was a nonforward glance after the portion during which the eyes were unclassifiable. If the eyes were then unclassifiable again, before the alert but after the glance, the eyes were coded as a 7 because the reviewers could not be certain what happened during that portion of the clip. If the location of one eye could be determined but not that of the other eye, location was still coded. Reviewers were confident in coding eye position when only one eye could be seen because eyes normally move in parallel. If the driver’s eyes glanced away before the alert and were in transition at the time of the alert, the last nonforward glance code reflected where they were look- ing at the time of the alert, not where they had previously been looking. For more details on eye location, see the information on eye location at the time of the alert. The criteria for classify- ing a glance as a specific location are the same as the criteria for eye location at the time of the alert. • 0 = Always looking forward at the forward scene. (Looking forward includes looking at the HUD.) • 1 = Left outside mirror or window. • 2 = Looking over left shoulder. • 3 = Right outside mirror or window. • 4 = Looking over right shoulder. • 5 = Head down, looking at instrument panel or lap area. • 6 = Head down, looking at center stack console area. (Con- sole means the area in which the stereo, thermostat, and clock are located.) • 7 = Driver wearing sunglasses or glasses with glare. (Glare prohibited the ability to classify where the eyes are looking.) • 8 = Cannot accurately evaluate eye location. (An 8 was cho- sen when the reviewer was unsure of the eye position or classification within a reasonable level of confidence but not because of glasses. Typically, the reviewer could see the actual eye but could not determine where the gaze was directed. Eyes in transition were often coded as 8 because it was unclear where the driver’s gaze was at that particular moment.) • 9 = Other. (For example, the driver might clearly be look- ing at the passenger side floor. When a glance was coded

81as other, the location was noted in the notes section. The most common position recorded as other was the rearview mirror.) Eyes on Task at Time of the Alert • 0 = No. (The classification of no was used only when the reviewer could confidently determine that the driver’s eyes were off the task of driving at the time of the alert [e.g., the driver was looking at a friend or the stereo system].) • 1 = Yes. (The classification of yes does not mean looking forward; it means that the driver’s eyes were on the task of driving.) • 2 = Cannot determine. (For instance, the driver was wear- ing glasses with glare or reviewers could not see the dri- ver’s eyes for some other reason. This classification was also used when reviewers could not tell if the eye location was on task [e.g., the driver was looking out the window, but it was unclear whether the driver was looking at traffic or at a fancy building that was distracting the driver’s attention]. In any case, reviewers did not know whether the driver was on task.) Eyes in Transition To classify the driver’s eyes as in transition, they must have been in transition at the time of the alert and must have started the transition at least 0.1 s before the alert. The eyes could not be at the beginning of a transition or the end of one; they must have been in the transition at the time of the alert. • 0 = No. • 1 = Yes, toward forward scene. • 2 = Yes, away from forward scene. • 3 = Cannot tell. (Cannot tell was selected when the driver was wearing sunglasses or reviewers could not see the driver’s eyes for some other reason; therefore, it was uncertain whether they were in transition.) Visual Response to Alert and Time to Visual Response Reviewers coded the time that it took the driver to initiate a visual response to the alert by filling in the number of 10ths of a second the response took. The time counted was the time between the alert and when the look was initiated, not includ- ing the moment of the alert or the moment of response. If the response was initiated within 1.0 s, then the driver was consid- ered to have looked in response to the alert. The amount of time it took to look in response was always recorded for appli- cable situations, even if this was greater than 1.0 s. If the driver was already looking at the road and continued to look forward,the code was null (not applicable). If reviewers were not sure of the location of the driver’s eyes, then the time to visual response was left as null. The time to visual response was recorded for Week 1, even though there was no alert to which to respond. The rationale for coding this was that a baseline would provide an idea of what a normal time to visual response was compared with the time to response with an alert. • 0 = Looked in response. (The driver initiated a look in response to the alert within 1.0 s. Glances qualified as a look in response.) • 1 = Did not look in response to alert. (The driver did not look within 1.0 s of the alert.) • 2 = NA. (This option was always used for Week 1 because no alert occurred during that week; thus, this category could not be coded. This option was also selected when the driver was already looking forward at the time of the alert; this category was not applicable.) • 3 = Cannot tell. (Because the driver was wearing sunglasses or other glasses with glare, reviewers could not tell where the driver’s eyes were looking.) Visual Occlusion Occlusion was coded with regard to the driver as well as to the reviewers. For instance, heavy rain or bright sun might have occluded the scene for both parties, whereas blurry video occluded the scene only for reviewers. The occlusion did not necessarily have to impact the reviewers’ ability to code the scene. • 0 = None. • 1 = Sun or headlight glare. (This classification includes when the scene was whitewashed from the sun. Only head- light glare was included in this section; taillight glare was coded as other.) • 2 = Other, specified in notes section. (The most common entry was taillight glare.) Startle Response Coding the startle response was subjective, and the classifica- tion as such was often hotly debated. The driver had to be vis- ibly rattled. The driver’s startle was observed by body response, dialogue, or both. Cursing was not sufficient to be coded as startle, because it might have resulted from anger or frustration, not startle. This category tried to capture startle either to the situation or to the alert. • 0 = No. • 1 = Yes.

82Steering in Response • 0 = No steering in response to alert. (Small, jerky reactions or slight wiggling in response to the alert or to the situation was classified as a 0 and not considered steering.) • 1 = Driver steered partially or fully in response to the alert. (Steering, for review purposes, was an evasive maneuver in an attempt to prevent striking a vehicle; thus there must have been a significant amount of steering.) Hand Location at Time of Alert Because both hands were not often visible, reviewers coded what could confidently be inferred from the scene. At times playing the video farther helped determine what was ambigu- ous in a still frame at the time of the alert. For instance, at the time of the alert there may have been a small blur near the steering wheel. On continuation of the video the blur may have moved and come into view as a hand. • 0 = Cannot see the position of either hand or cannot deter- mine the position of either hand. (Reviewers coded 0 if a hand could be seen but they could not tell if it was on the wheel.) • 1 = At least one hand on the steering wheel. (Reviewers used this code when the position of one hand could not be determined but they could see that at least one hand was on the steering wheel.) • 2 = Both hands on the steering wheel. • 3 = At least one hand off the steering wheel. (This code was used when the position of one hand could not be determined but at least one hand was clearly off the steering wheel.) • 4 = One hand on, one hand off the steering wheel. (A 4 was classified when reviewers could clearly see both hands and one was on the wheel and the other was off.) • 5 = Both hands off the steering wheel. (A 5 was classified when reviewers could clearly see both hands and both were off the wheel.) Road Geometry • 0 = Straight. • 1 = Curve. (A curve must be of some substance to be con- sidered a curve.) • 2 = Approaching curve. (The classification of approaching a curve constituted situations in which the driver was almost in a curve, not when there was simply a curve in the distance.) • 3 = Lane shift. (Road geometry was classified as a lane shift when there was a change in the lane structure, for instance, when a new lane was created. If the new lane was a turn lane, it was not classified as a lane shift, because the scenario should have covered the fact that there was a turn lane ifthat were relevant. Lane shifts were also considered shifts in traffic patterns, such as lane shifts in construction areas.) Secondary Driving Behaviors Audio was used to assist in coding whenever possible. For instance, reviewers may have heard the radio station change and seen the driver look at the console; this would indicate in- car system use. The default for nondriving behaviors was none, coded as 0. Cell Phone • 10 = Conversation, in use. (Conversation could be coded for listening, talking, or both while using the cell phone.) • 11 = Reaching for phone. (This classification refers to when the driver reached for the handheld phone to speak on that phone. If the driver reached for the phone simply to answer the phone and talk on the headset the driver was wearing, the classification was other. Simply answering the phone involves far less physical activity by the driver than reach- ing for the phone and holding it during a conversation.) • 12 = Dialing phone. Headset, Hands-Free Phone • 20 = Conversation. (This classification was selected when reviewers could tell that the driver was in a conversation.) • 21 = Reaching for headset. • 22 = Unsure of activity level. (The driver was wearing a headset, but it was not clear whether the headset was in use. The driver may have been listening to someone or wearing the headset in case there was an incoming call.) Eating • 30 = Highly involved. (High involvement includes such things as eating a burger or unwrapping food.) • 31 = Low involvement. (Low involvement includes such things as eating candy or grabbing chips.) Drinking • 40 = Highly involved. (High involvement includes situa- tions in which the driver was trying to open a straw or bot- tle or was blowing on a hot drink.) • 41 = Low involvement. (Low involvement includes situa- tions in which the driver was sipping a drink or drinking without looking.) • 50 = Conversation. (The driver and someone in the car were carrying on a conversation. The driver can be listen- ing during the clip, talking during the clip, or both.)

83• 60 = In-car system use. (The driver was actively adjusting something. For example, the driver was not just listening to the stereo but also adjusting it. The car lighter was coded under the smoking section.) Smoking • 70 = Lighting. (This classification includes the in-car lighter.) • 71 = Reaching for cigarettes or lighter. (This classification includes the in-car lighter.) • 72 = Smoking. Grooming • 80 = Highly involved. (High involvement includes applying makeup or brushing hair.) • 81 = Low involvement. (Low involvement includes scratch- ing or running one’s fingers through his or her hair.) • 90 = Other/multiple behaviors, specified in notes section. (Such behaviors might include whistling or classifications that reviewers were unsure of [e.g., if the driver’s lips were moving but there was no audio, the behavior might be singing or conversation].) Alert Classifications • 1 = False alarm. (Two reasons were given for the classifica- tion of an event as a false alarm. The first was that the tar- get was out of the lane throughout the episode or it was off the roadway, including both vehicles and stationary objects. The second was that the kinematics of the scenario did not make sense [e.g., when there was a lead vehicle deceleration error resulting in an alert].) • 2 = True/nuisance alert. (The target had to be a vehicle that was in the driver’s path for at least a portion of the episode. The event may have been viewed by the driver as either a needed alert or a nuisance alert.) • 3 = Instigated alert. (An alert was classified as instigated if the driver deliberately drove in such a way as to provoke an alert. This does not apply to when the driver was in adap- tive cruise control [ACC] and was trying to see if the system would brake sufficiently; this was testing the ACC system rather than the forward crash warning [FCW] system.) Target A vehicle was considered in path if even a small portion—for example, a rear bumper—of the lead vehicle remained in the driver’s lane at the time of the alert. Vehicles with both sport- utility vehicle (SUV) and car characteristics, a small SUV, were classified as a car. The classification as a car for these SUVs was because the body of the vehicle, in respect to howthe driver may follow it, is more in line with that of a car than with that of an SUV. • 0 = Vehicle in path—car. • 1 = Vehicle in path—pickup, van, or SUV. • 2 = Vehicle in path—other (e.g., motorcycle, semitrailer, commercial vehicle). • 3 = Vehicle out of path—car. • 4 = Vehicle out of path—pickup, van, or SUV. • 5 = Vehicle out of path—other (e.g., motorcycle, semi- trailer, commercial vehicle). • 6 = Construction. (This includes all equipment associated with construction [e.g., barrels, cones, and construction vehicles].) • 7 = Discrete roadside object. (This classification includes signposts, light poles, trees, fire hydrants, and mailboxes.) • 8 = Overhead items. (This classification includes such items as overhead signs and bridges.) • 9 = Bridge support. • 10 = Guardrail/Jersey barrier. • 11 = Other, to be specified in notes section. Target Stationary or Moving This category was coded using both visual cues and radar data. For vehicles that appeared to be either stopped or slowly mov- ing, visual cues were used if the cues were clear—for example, lane markings—but otherwise, radar data was used to deter- mine the classification. • 1 = Stationary. (The target must have had a velocity of less than or equal to 1.3 m/s to be classified as stationary.) • 2 = Moving. • 3 = Stationary potential threat. (The classification of 3 was made when the target was a vehicle that was stopped [velocity of less than or equal to 1.3 m/s] but had the potential to move at any moment [e.g., stopped cars with drivers in them].) Forward Conflict Scenario The same scenarios are used for classifying supplementary scenarios as needed. The supplementary scenario column also has the option of 0 = none. Supplementary scenarios are available in case there is another possible scenario or if the situation resembles another scenario that may be of interest to people working with that specific type of scenario. Out of Host’s Path • 100 = False alarm. (Two reasons were given for the classi- fication of an event as a false alarm. The first was that the

84target was out of the lane throughout the entire episode or it was off the roadway, including both vehicles and station- ary objects. The second was that the kinematics of the scenario did not make sense [e.g., when there was a lead vehicle deceleration error resulting in an alert].) In Host’s Path The following scenarios were initiated by the host vehicle. Note, however, that this and the following subcategories apply to the stereotypes of scenarios and may not apply to all cases. Nevertheless, these assumptions were used during some analyses. • 200 = Host tailgating. (Tailgating was coded even if the lead vehicle was on an exit or entrance ramp. The criterion for tailgating was a headway of 0.8 s or less. If the host was using ACC and the headway matched the criterion for tailgating, it was not considered tailgating, because the system rather than the driver was controlling the headway.) • 210 = Host approaches an accelerating vehicle. (This typi- cally occurred when the host misjudged the lead vehicle’s acceleration and the host accelerated too fast on a vehicle that was accelerating as well or if the host was approaching a vehicle as a traffic light turned green.) The following scenarios played out naturally with neither the host nor the lead vehicle changing accelerations. • 220 = Host approaches slower vehicle that is traveling at constant speed. (The criteria for this classification were as follows: no brake lights were visible; lead vehicle was always going slower than the host while the target was detected by ACAS; and the target did not appear to be decelerating, either visibly or using the radar data. Slight fluctuations in speed are normal, but the overall speed must have been fairly constant. Typically, the lead vehicle was in the dis- tance at the beginning of the clip and then moved into view as the host gained on it.) • 230 = Host approaches lead vehicle that is already stopped. (The lead vehicle must have been traveling less than 1.3 m/s during all portions of the clip in which it was acquired as a target. Please see the notes on Target Stationary or Moving for more details on how the determination of a target as sta- tionary or moving was made.) The following scenarios were initiated by the lead vehicle. • 240 = Host follows a lead vehicle that decelerates to an un- predictable stop. (This scenario was classified as such when the traffic stopped but the host driver may have thought traffic would just slow and not stop; no stop sign or trafficsignal was in view. The event was coded as 240 even if the lead vehicle had not stopped by the time of the alert, as long as the lead stopped within 12.5 s of the alert [the regular viewing time plus a 10-s continuation]. For coding purposes, stop means that the lead came close to 0 mph [less than or equal to 1.3 m/s].) • 250 = Host follows a lead vehicle that decelerates to a predictable stop. (This scenario occurred when there was a traffic light, stop sign, visibly stopped traffic, or the car in front of the lead had its brake lights on. These cues made it so that the host could logically anticipate that the lead would stop. The event could be coded as 250 even if the lead had not stopped by the time of the alert, as long as it had stopped within 12.5 s of the alert [the regular viewing time plus a 10-s continuation]. For this scenario, a stop means coming close to 0 mph [less than or equal to 1.3 m/s].) • 260 = Host follows a lead vehicle that decelerates in an unpredictable manner but does not stop. (For this scenario the brake lights on the lead vehicle had to be visible or the lead was noticeably slowing even if the brake lights could not be seen but the reason for slowing was not visible or not predictable [e.g., a cat crossing the street]. The classifi- cation as 260 was the default over a 270.) • 270 = Host follows a lead vehicle that decelerates in a pre- dictable manner but does not stop. (For this scenario the brake lights on the lead had to be visible or the lead was noticeably slowing even if the brake lights could not be seen. The code of 270 was selected only if it was clear from the cues available why the lead needed to decelerate [e.g., a slow moving piece of farm equipment was ahead or the car in front of the lead had its brake lights on].) Transitional Host Path: One or Both Vehicles Change Lanes The following scenarios were initiated by the host vehicle. • 300 = Host cuts behind a lead vehicle. (The code 300 was used when the host cut into another lane closely behind the lead vehicle. This maneuver could not be part of a two-lane pass. See the description of a two-lane pass for more details.) • 310 = Host performs two-lane pass in order to pass. (This scenario involves the host’s cutting behind the lead in the process of making a two-lane pass maneuver: the host crossed the middle lane in order to enter two lanes over from the host’s lane of origin. If two alerts occurred for the same smooth transition during a two-lane pass, review- ers coded the first alert as 310 and did not code the second alert in the series. Reviewers commented on the scenario in the notes section, labeling the second alert as such in the notes section. A two-lane pass does not require two alerts.)

85• 315 = Host performs two-lane pass to exit or to make a turn that is carried out within the time of the clip. (The scenario was classified as such when the host cut behind a lead in the process of making a two-lane pass maneuver: the host crossed the middle lane in order to enter a lane two lanes over from the host’s lane of origin. If two alerts occurred for the same smooth transition during a two-lane pass, reviewers coded the first alert as 315 and did not code the second alert in the series. Reviewers commented on the scenario in the notes section, labeling the second alert as such in the notes section. A two-lane pass does not require two alerts.) • 320 = Host changes lanes to pass lead vehicle. (The tar- get for this alert type was the vehicle in the host’s original lane. For this event, a pass was coded even if the host had not passed at the time of the alert, as long as the host was act- ing like a pass was planned; for instance, the host was checking the mirrors and accelerating. If the pass was aborted and not carried out during the entirety of the extended clip [10 additional seconds], reviewers classified the event as a pass and marked the scenario as aborted. Reviewers added notes when necessary. If the host was passing a vehicle that was waiting to turn, reviewers coded whichever event seemed to be the reason for the alert and the other event could be chosen in the supplementary scenario section.) • 330 = Host enters turn lane or other dedicated lane (e.g., exit lane) while approaching a lead vehicle in the new lane. (In this case, the target was the vehicle in the host’s new lane.) • 340 = Host enters a turn lane or other dedicated lane (e.g., exit lane) while approaching lead vehicle in original travel lane. (In this case, the target was the vehicle in the host’s original lane.) • 350 = Host weaves in order to avoid an obstacle but does not completely change lanes. (An event was coded as 350 if the host did not completely change lanes in the process of avoid- ing an obstacle. This was not a planned maneuver; there was no turn signal or other indications of a lane change until the last moment—an evasive reaction.) • 355 = Host weaves in order to avoid an obstacle and com- pletely changes lanes. (An event was coded as 355 if the host changed lanes completely in the process of avoiding an obstacle. The motivation for the lane change has to have been to avoid something in the original lane. This was not a planned maneuver; there was no turn signal or other indi- cations of a lane change until the last moment—an evasive reaction.) The following scenarios were initiated by the lead vehicle. • 360 = Lead vehicle changes lanes and cuts in front of host. (The main precipitant of this scenario was the lead cuttingin front of the host. This occurred when the lead was in a lane parallel to the host’s and then cut in or merged close to the front of the host’s vehicle.) • 365 = Lead vehicle is forced to merge in front of host. (An event was classified as 365 when the lead needed to merge into the host’s lane because an entrance ramp was ending or a lane was ending for another reason.) • 370 = Lead executes a two-lane pass. (This scenario was coded when the lead passed from a lane parallel to the host’s, across the host’s path, and then over to the parallel lane on the other side of the host’s car. The lead was only in the host’s path momentarily.) • 380 = Lead vehicle in adjacent lane weaves or encroaches unintentionally/unknowingly into host’s lane. (The classi- fication of an event as 380 refers to events in which the lead entered the host’s lane unintentionally and momentarily. The brief entry into the host’s lane by the lead vehicle caused the alert.) • 390 = A vehicle crossing the host’s roadway travels straight across host’s path. (The scenario is characterized by a vehicle driving straight across the host’s path. The target vehicle did not remain in the host’s path; typically, the radar hit the side of the crossing vehicle, and the intersecting paths were perpendicular to each other.) • 400 = A vehicle makes a left turn across the host’s path in order to travel in a direction other than that of the host. (In this scenario the crossing vehicle turned left either from a perpendicular street or from a parallel lane traveling in the opposite direction of the host’s lane. If the vehicle turned from a side street, it crosses the host’s path and then con- tinues into a parallel lane traveling in the opposite direction. If the vehicle turned left from a parallel lane, it crossed the host’s path and continued onto a perpendicular street. The vehicle crossed the radar path with primarily a perpendi- cular angle, but the angle may be more steeply tilted than when the vehicle was simply crossing straight across the host’s path in other scenarios.) • 410 = A vehicle entering the host’s roadway crosses host’s path and moves into a lane parallel to the host’s lane in the same direction. • 420 = A vehicle pulls out from a side street or driveway and pulls in front of host and into the host’s lane. (This sce- nario occurred when the lead started out perpendicular to the host car and turned into and in front of host’s car.) • 430 = Lead changes lanes out of host’s lane. (This sce- nario developed when the lead departed the host’s lane but the situation was not covered by another described scenario. One instance of this situation is when the host could logically anticipate that the lead vehicle would change lanes because of the lead’s turn signal or another indica- tion and, therefore, the host gained on the lead, sounding an alert.)

86• 440 = Lead leaves host’s lane to enter turn lane or other dedicated lane (e.g., exit ramps and turn lanes). • 450 = Lead turns left from host’s travel lane. (The target in this conflict is the turning car. The lead must have begun the turn, even slightly, for the scenario to be coded as 450. If the lead’s turn signal was on but the turn had not yet been initiated, the event was coded as a predictable decel- eration and given a supplementary scenario of 450.) • 460 = Lead turns right from host’s travel lane. (The target in this conflict is the turning car. The lead must have begun the turn, even slightly, for the scenario to be coded as 460. If the lead’s turn signal was on but the turn had not yet been initiated, the event was coded as a predictable decel- eration and given a supplementary scenario of 460.) Scenario Completion • 0 = Completed. • 1 = Aborted. Supplementary Scenario This category allowed reviewers to select a second scenario to which the situation could be attributed. The supplementary scenario could also be a scenario that preceded or followed the imminent scenario but may have contributed to the develop- ment of the actual scenario. This category was designed to be a reference list for people interested in scenarios that could have been classified in other ways. The category also allowed reviewers to indicate two scenarios when the primary scenario was difficult to determine. If reviewers did not indicate a sup- plementary scenario, a 0 was entered for none.Notes A notes section recorded any unusual events or ambiguous situations not covered by categories for a particular question. This section also contains general notes on the clip if there was anything significant taking place that was not adequately covered by the coding process. See section Annex A-1 below for further details. Annex A-1 The following are examples of items that are captured in the notes section, although other, unforeseen events are also noted. Visual Occlusion Rear taillights, glare from rain and wetness on the road, blurry video, dirty windshield, temporary incapacitation, sneezing, flying debris, faulty wiper or defroster, and an object in or over the eyes. Nondriving Behaviors Whistling, two or more behaviors, if there is no audio and the driver is clearly talking or singing but reviewers could not tell which, attempting to avoid an insect in the car, adjusting mir- rors, reading a map, reading other materials, checking a watch, or yawning. Target Shadows and embankments.

Next: Appendix B - Project 5 Data Dictionary »
Feasibility of Using In-Vehicle Video Data to Explore How to Modify Driver Behavior That Causes Nonrecurring Congestion Get This Book
×
 Feasibility of Using In-Vehicle Video Data to Explore How to Modify Driver Behavior That Causes Nonrecurring Congestion
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB’s second Strategic Highway Research Program (SHRP 2) Report S2-L10-RR-1: Feasibility of Using In-Vehicle Video Data to Explore How to Modify Driver Behavior That Causes Nonrecurring Congestion presents findings on the feasibility of using existing in-vehicle data sets, collected in naturalistic driving settings, to make inferences about the relationship between observed driver behavior and nonrecurring congestion.

The report, a product of the SHRP 2 Reliability focus area, includes guidance on the protocols and procedures for conducting video data reduction analysis.

In addition, the report includes technical guidance on the features, technologies, and complementary data sets that researchers can consider when designing future instrumented in-vehicle data collection studies.

The report also highlights a new modeling approach for travel time reliability performance measurement across a variety of traffic congestion conditions.

An e-book version of this report is available for purchase at Google, Amazon, and iTunes.

READ FREE ONLINE

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!