|
|
|
|
Chapter 2. Current Industry Practices
Practices for Construction / Roadwork Information AssemblyIt is common that agencies enter information into their RCRS to describe construction, maintenance or any planned or unplanned DOT activities that cause road or lane closures or delays. An example would be emergency utility repairs that require the closing of one or more lanes of traffic. Of the 22 states that replied to the survey for this project describing their RCRS, all indicated that they enter roadwork information manually or in a semi-automated fashion, as shown in Table 3 below. Since state DOTs began operating traveler information websites in the 1990s, the inclusion of current and future roadwork has always been a critical component.
23 CFR 511 Requirements for Construction and Roadwork InformationThe parameters in the 23 CFR 511 Rule require that roadwork information is to be assembled within 20 minutes from the time of closure along Interstates outside metro areas, and within 10 minutes from the time of closure along Interstates and designated routes of significance within metro areas. Typical Procedures for Assembling Construction and Roadwork InformationAgencies entering roadwork information into their RCRS follow a series of steps similar to the following:
Challenges Facing RCRS Information Assembly for Roadwork EventsTwenty of the twenty-two states that indicated they include roadwork in their RCRS described the entry of roadwork as a manual process (the other two indicated partially automated). The manual entry of roadwork descriptions contributes to a number of challenges facing agencies that include roadwork events in the RCRS. Challenge #1: Lack of Detail. The RCRS description of roadwork events is only as complete as the information entered by DOT employees. At the time the roadwork is planned, there might not be extensive details available describing what lane closures will occur and when. Often, these decisions are made on-site and on a daily basis. Therefore, it is not always that the information is not entered into the RCRS; it can be that the information is not available until the crew arrives on at the site and begins work. An example of an actual roadwork event in an RCRS and displayed on a public website in February 2014 is, “The road is being reconstructed until October 31, 2014. Last updated July 15, 2013.” Although this example provides correct information, it does not include the details necessary to be valuable information to the motorist. Challenge #2: Missing Roadwork Reports. The step of manually entering roadwork events into the RCRS creates the opportunity for some roadwork events to be excluded from the RCRS. Larger events that are planned longer in the future are more likely to be included. Smaller roadwork events decided closer to the start time (e.g., pothole patching or repairs) might be more likely to be omitted from the systems. The extent of this challenge is often a factor of the structure and use of the RCRS. If an agency allows or requires multiple groups such as planning, maintenance and construction to perform direct entry into the RCRS, these groups can enter roadwork events as they are planned. If the architecture of the RCRS is such that a limited number of DOT employees perform entry, this emphasizes the need for internal communications to relay details of the roadwork to staff responsible for RCRS entry. Challenge #3: Accuracy of Reports. The manual entry of roadwork events creates the potential for users to incorrectly describe details of the roadwork event. For example, the extent of impacts of the roadwork might not be fully understood when it is entered into the RCRS. Similarly, the start or end date of the roadwork might be entered when the event is created, but as the roadwork is performed, if the work extends beyond the scheduled date or ends early, users may neglect to change the expiration date, causing the system to incorrectly report information to the traveling public. Industry Practices Related to Roadwork Entry into RCRSAs a result of the outreach efforts in this project, the following industry practices related to roadwork entry in the RCRS were identified.
These industry practices are summarized as follows: Roadwork Information Assembly and Entry Industry Practice #1: Semi-automated roadwork entries for Maryland CHARTThe Maryland State Highway Administration (MDSHA) has integrated their Coordinated Highways Action Response Team (CHART) RCRS1 with the department’s legacy Lane Closure Program for semi-automated entry of roadwork alongside state roadways. The Lane Closure Program (formerly part of the agency’s Emergency Operations and Reporting System – EORS) is used by MDSHA to enter permits for any work (e.g., mowing, utilities, construction) along roadways under MDSHA jurisdiction. The respective districts review and approve permits as they are requested. When the scheduled day of work arrives, contractors notify MDSHA staff to activate their permit. MDSHA staff verifies the permit and enters the roadway impacts in CHART as they were defined in the permit. The permitting process ensures that all roadwork is known before it occurs and the integration with CHART allows travelers to receive up-to-date information about potential impacts. Feedback from MDSHA described that the benefit of this industry practice is that by leveraging the comprehensiveness of the existing Lane Closure Program and then integrating that information and process with CHART ensures complete roadwork information and also has eliminated the need to teach additional staff how to operate multiple programs. Roadwork Information Assembly and Entry Industry Practice #2: Wisconsin agency-wide use of RCRS for lane closure entry and approvalWisconsin DOT (WisDOT) operates separate ‘modular’ components that function together as a comprehensive RCRS2. One component of the RCRS is the Wisconsin Lane Closure System (WisLCS). The WisLCS is a web-based entry tool and related database. WisLCS is not only an entry tool used by operators in the statewide Traffic Operations Center (TOC), it is also an internal business process and approval tool that is used by multiple groups within the DOT to enter planned (or unplanned) lane closures. This helps to ensure that every lane closure in the state is included in the database and XML output. As lane closures are planned for state maintained roads within Wisconsin, WisDOT staff throughout the agency use the WisLCS to enter the proposed lane closures, describing impacts, activities, dates and times of closures. The range of staff that use this tool includes the following groups: planning, construction, and maintenance. Effectively, any staff involved in planning, operating, or approving lane closures uses the tool to enter, describe, approve, or remove lane closure descriptions. The WisLCS is more than a system to report information for dissemination to the public. It is also an internal business process and approval tool. Therefore, the proposed lane closures are entered and eventually approved in the system before they are implemented in the field. This coordinated approach whereby all groups involved in planning, approving, and executing lane closures enter the information into the WisLCS ensures that every lane closure is in the system, and available for reporting on traveler information systems. Additional details of the lane closures may be appended to the WisLCS by operators in the statewide TOC as they receive daily or weekly updates from construction crews. Similarly, the WisLCS also allows private sector contractors to access the tool and enter updates describing current impacts of lane closure events. Updates or entries performed by outside contractors all must be approved by WisDOT supervisors before they are accepted or disseminated, but this also reduces the workload on WisDOT staff. One example of the integrated nature of WisLCS is a theoretical bridge hit in Wisconsin. If a vehicle hit a bridge, the incident would be included in the Advanced Traffic Management System (ATMS). If this closed a lane, the lane closure (to respond to the incident) would be entered into WisLCS. If the damage to the bridge was substantial, WisDOT Maintenance would update the lane closure information to describe the long term lane closures needed to repair the bridge. Therefore, the WisLCS is a critical tool for incident response through repairing of the bridge. Feedback from WisDOT has included the following benefits of the unique WisLCS approach:
Roadwork Information Assembly and Entry Industry Practice #3: Michigan DOT agency-wide roadwork entry toolThe Michigan DOT (MDOT) utilizes an in house system called Lane Closure and Restrictions (LCAR) that allow MDOT groups (i.e., construction, maintenance, operations) to enter and update road work information. MDOT reports real-time travel information on the Mi Drive website. One of the key aspects of the website is accurate reporting of road work activities on state maintained highways directly from LCAR. Construction and maintenance staff post planned construction to guide motorists in advanced route planning. MDOT operations staff along with TOC operators, edit LCAR in real-time to ensure accurate information is disseminated to the traveling public. Real-time travel information is obtained through close communication with field staff and control room operators monitoring cameras, speed sensors, and police information. In Michigan, the contractors performing maintenance work must phone in reports daily describing the anticipated impacts of the daily activities planned for the day. The operators working in any of the MDOT TOCs then use the same entry tool to update the status of road work activities. MDOT has observed a benefit of more accurate descriptions of roadwork activities using this agency-wide tool. Practices for Incident / Event Information AssemblyIncidents include crashes, stalled vehicles, traffic stops, highway debris, and spilled loads. Special events include planned activities at entertainment venues, events causing road or lane closures, and other activities that create an increase in demand and/or decrease in capacity. Together incidents and special events create significant delay to travelers, and also are a major contributor to secondary incidents. It is common for agencies to enter information into their RCRS to describe incidents and planned special events that impact travel, especially those restricting traffic flow or closing lanes or roadways. All 22 states that responded to the project survey indicated they include roadway or lane blocking incidents in their RCRS, as illustrated in Table 4 below.
23 CFR 511 Requirements for Incident / Event Information AssemblyThe parameters in the 23 CFR 511 Rule require that roadway or lane blocking incident information is to be assembled within 20 minutes from time of verification along Interstates outside the metro areas, and within 10 minutes from time of verification along Interstates and designated routes of significance within the metro areas. Typical Procedures for Assembling Incident / Event InformationThe procedures followed by the majority of agencies to enter incidents and unplanned events into the RCRS follow a series of steps similar to the following:
Challenges Facing RCRS Information Assembly describing Incidents / EventsFive of the twenty-two agencies that described incident entry when responding to this project’s survey indicated they utilize either semi-automated or fully-automated incident entry into the RCRS. Agencies face a number of challenges to populating the RCRS with timely and accurate incident information, summarized as follows: Challenge #1: Reporting Delays. Obviously, the earlier incidents and events are entered into the RCRS, the greater the benefits to travelers. For incidents observed by DOT staff, incident entry is only delayed by other TOC commitments. However, for incidents reported to law enforcement, there are potential challenges for the DOT to receive the information and create the appropriate events in the RCRS. Because the primary responsibility of law enforcement is incident response, manually notifying the DOT of an incident may take a lower priority. Challenge #2: Lack of Details and Updates. For travelers, the alert that there is any type of an incident provides valuable information, regardless of the detail level. Depending upon the time of day and location of the incident, travelers can often predict the extent of expected delays (e.g., a report of any incident at 5:00 pm in a metro area will most likely result in delays). However, to truly understand impacts and determine travel pattern changes, travelers need details about the incident (e.g., direction of travel, lane closures, etc.). Finally, the most requested, and often most difficult to obtain, information is the forecasted clearance time. Assembling these details and obtaining updates as the conditions change (e.g., on-scene officers close a lane for vehicle removal) can be a challenge. Challenge #3: Special Events Not Reported. While special event notifications will vary by event venue, one challenge that DOTs face is not receiving reliable notifications of special events. This challenge is complex because the threshold that defines when a special event is worthy of notifying a DOT is not always clearly understood (e.g., is the attendance and arrival pattern likely to cause travel delays?). Challenge #4: Special Events Occur on Local Roads. The majority of special events occur at venues located along local roads. DOTs typically do not include local roads in the RCRS. This can present a challenge to including special events in the RCRS. A common approach is to create the event on the state maintained highways (included in the RCRS) that are most likely to be impacted by the event, however a challenge still exists to properly describe the venue to the traveling public. Industry Practices to Address the Challenges of Incident / Events into RCRSAs a result of the outreach efforts in this project, several examples of state DOTs using approaches to overcome the challenges of incident and event entry in the RCRS were identified. A total of eight industry practices are presented, each including unique aspects of approaches to incident and event entry.
These industry practices are summarized as follows: Incident and Event Entry Industry Practice #1: Minnesota DOT integration of State Patrol Computer Aided Dispatch (CAD) data into RCRSThe Minnesota DOT (MnDOT) reports and often responds to crashes and other incidents that block lanes on state roadways. While some crashes are detected in the Twin Cities Metro area by operators and service patrols at the MnDOT Regional Transportation Management Center, most crashes are reported by cellular 911 calls to the Minnesota State Patrol (MSP). MnDOT relies on the statewide events that are received from the MSP CAD system. MnDOT integrated their RCRS3 with the MSP CAD system in 2010. The integration allows a CAD-generated event to appear in the RCRS and then the RCRS allows operators to take over that entry and add further details (e.g., add an event duration, change the location description of the event). The integration has worked well but there have been issues with transferring data between the two agency firewalls that have led to 5-10 minute delays in data transfers. That issue is now being resolved through CAD system updates. Incident and Event Entry Industry Practice #2: New York Thruway Authority automated integration of CAD dataCrashes and other incidents occurring on the New York Thruway are reported to the New York State Thruway Authority (NYSTA) State Police 911 call center, where operators enter incidents into a computer aided dispatch (CAD) system. NYSTA now operates an automated interface between the 911 center CAD system and their RCRS4 to automatically ingest incident information. As incidents are entered into the CAD system, an automated filtering process removes any sensitive information, identifies those incidents in CAD that are relevant to travel on the Thruway, and shares these incident descriptions with the NYSTA RCRS. NYSTA operators using the RCRS can review, edit, accept or reject the incident descriptions. Those accepted become active incidents in the RCRS, with the same functionality as if an operator had manually created the incident. As the incident is managed, 911 State Police operators update information about the incident. Updates are received from the CAD system. NYSTA operators view updates from the CAD system, and can determine if they wish to update the parallel event in the RCRS. One specific detail of this industry practice is the ability of the RCRS user to edit the location of the incident that is received from the CAD system. While early designs of the system originally planned to not allow the RCRS operator to change the location of the incident, it was later determined to be critical, as often the location contained in the CAD system does not match the actual location of the event, or because the traveler information event disseminated to the public is best described by a larger area (e.g., between two major intersections) to allow drivers to detour and avoid the event. Incident and Event Industry Practice #3: West Virginia integration of data from various law enforcement CAD systemsCrashes and other incidents occurring in West Virginia are often reported to one of the many Public Safety Answering Points (PSAPs) throughout the state. The RCRS5 operated by West Virginia DOT (WVDOT) operates an automated ingest function to acquire incident reports from the various PSAPs’ CAD systems. Traffic operators at the statewide TMC receive popup notices in real time as PSAP operators enter new and updated data on 9-1-1 calls. Incident reports to the TMC are filtered to remove any sensitive information. Traffic operators review the 9-1-1 alerts and determine if they should be included in public facing traveler information systems. If the operator decides that the public should be notified then they can initiate a transfer to the public information system. The system will automatically generate a default traveler information message based on the information contained in the alert. The traffic operator can approve the default message, replace it, or add amplifying remarks. It is a conscious policy to force traffic operator to intervene before information is sent to the public. 9-1-1 system data is not necessarily verified or appropriate for the public, so traffic operators are required to exercise their judgment before sending information to the public. In most cases they will seek some kind of independent verification of the event before notifying the public. West Virginia has 9-1-1 integrations in place for almost all counties which contain Interstate mileage. Plans are in place to add coverage for all remaining Interstate mileage as well as strategically chosen US primary routes. Incident and Event Industry Practice #4: Wisconsin integration of incident data from law enforcement centersWisconsin State Patrol operates one overall statewide CAD system that is used to manage incidents received by State Patrol dispatchers. Additionally, Milwaukee County Sheriff’s Office operates a CAD system with incidents in Milwaukee County that includes all state maintained highways and freeways in Milwaukee County. Other counties operate similar CAD systems. Wisconsin DOT (WisDOT) has developed an automated acquisition function to integrate appropriate incident reporting into the ATMS from these and a handful of other law enforcement CAD systems within Wisconsin. As incidents are entered into the CAD system, the WisTransPortal InterCAD application removes any sensitive information and filters incidents that are not of interest to WisDOT. The incident descriptions are then translated from the Global Justice XML Data Model format into the IEEE 1512 standard format. The incidents are then integrated into the ATMS software operated by WisDOT6 as incidents. The operators in the statewide TOC then take over updating the incident. The ATMS system performs the role of the RCRS by publishing an XML feed that includes all incidents. Incident and Event Information Entry Industry Practice #5: Oregon DOT RCRS Combined with Dispatch and Incident Management SystemThe Oregon Department of Transportation (ODOT) has developed one common software system that serves as the RCRS7 and as the dispatch and incident management system used by the ODOT operators. Oregon DOT operators in the TOCs or DOT offices receive phone or radio reports from DOT staff in the field, the traveling public, and law enforcement agencies. These reports describe incidents that include:
The ODOT RCRS is the primary tool that the Transportation Operations Specialists use to enter the information they receive. Each report of a situation is entered into the system. The Transportation Operations Specialists are then responsible for managing the event, which may include dispatching maintenance staff to the scene, posting DMS messages using the TMC software, or other activities, and all of these activities are logged in the RCRS. Because the RCRS and incident management systems are combined, ODOT operators do not need to enter the information into a separate RCRS to feed the traveler information systems. The ODOT RCRS has internal filters and rules for determining what types of events should be shared with Information Dissemination mediums, such as the 511 website or the 511 phone system. Therefore, operators do not need to make a judgment call about what to enter into the traveler information RCRS. As an example, when an operator enters a report of an animal on the shoulder, the RCRS is used to track progress on responding to the event until it is removed, but the event would not be disseminated on the traveler information systems, whereas an entry about a tree blocking a lane would be entered in the same manner, but the RCRS filter would send that message to the traveler information systems. Incident and Event Information Entry Industry Practice #6: Florida SunGuide RCRS Functions Combined with Road Ranger Incident Entry and ManagementThe Florida DOT (FDOT) road condition reporting functions are performed by Traffic Management Center (TMC)/TOC staff using a comprehensive TMC/TOC software tool called the SunGuide Software8. The SunGuide software is used in 12 FDOT TOCs and in several county transportation departments. Because the road condition reporting functionality is integrated as part of the overall event management, the road condition reporting is accomplished by operators as they are managing the events, rather than as a stand-alone entry of information for dissemination. The freeway service patrol (referred to as Road Rangers) use the field modules to enter reports of stalled vehicles or other incident activities. This allows timely and accurate reporting into the RCRS portion of the system, while also enabling FDOT to “grade” their Road Rangers appropriately. The fact that all aspects of event management are performed using the SunGuide software, and activities are entered into one system provides for more comprehensive and accurate incident and event reporting than if a stand-alone RCRS were used. In addition, the details about the event management create a rich data set for performance measurement reporting. Benefits of this functionality include a rich data set capable of generating extensive performance measures, no dual entry of events/incidents into an RCRS system, and comprehensive set of incident reports. Incident and Event Information Entry Industry Practice #7: Washington State DOT RCRS Integration with Radio Log SystemThe Washington State DOT (WSDOT) has an RCRS9 that TMC staff use to enter incidents, closures, driving conditions, and other planned and unplanned events. WSDOT also operates a Radio Log System that is used by radio operators who are responsible for receiving radio and phone calls and dispatching DOT maintenance response. The two systems have separate entry tools but are integrated in that they share the same database, avoiding duplicate entry. WSDOT TMC operators use the RCRS system called ROADS to enter incidents and events. WSDOT radio room operators use a similar software tool called the “Radio Log System” to log radio exchanges and phone calls describing situations that DOT staff members respond to. The integration of the two systems prevents the need for dual entry. For example, a radio operator receiving a call from any source that there is a ‘tree down’ along a highway will enter this into the Radio Log System, where it will be time-stamped and saved to the database. The Radio operator can hit a button causing the event to also be part of ROADS, where TMC staff could also add details to the event description. As the radio operator dispatches crews to clear the tree and eventually enters that the event is clear in the Radio Log System, it also clears in ROADS. One distinct advantage to the integration of both systems is the fact that not all WSDOT TMCs are staffed 24/7. In some centers, there are no TMC operators overnight, but there are always radio operators. As events are reported, the radio operators can enter them in the Radio Log System and have them move into ROADS simultaneously (feeding the traveler information systems such as 511 phone, web and Twitter). Therefore, WSDOT gets 24 hour entry of incidents and events and the radio operators do not need to use a different system from the one they are most familiar with. WSDOT noted that the combined nature of the RCRS and Radio Log System has several benefits:
Incident and Event Information Entry Industry Practice #8: Idaho Transportation Department Shared Resources with Other State Agencies to Perform RCRS Incident and Event EntryThe Idaho Transportation Department (ITD) has a contract with the Idaho Department of Health and Welfare (DHW) agency, EMS Bureau to perform entry of incidents and events into their RCRS10. The Emergency Medical Services (EMS) staff also performs EMS dispatch, and dispatches for a variety of other services, including Idaho Bureau of Homeland Security, Hazardous Materials (HazMat) response and Idaho Fish and Wildlife. Because this one group dispatches for such a wide variety of services, they have a vast knowledge and understanding of the conditions, events and incidents impacting Idaho. This allows for accurate and thorough descriptions of conditions and events in the Idaho RCRS and extensive coordination among agencies during major events. The EMS Bureau performs all of the ITD dispatching statewide. Therefore, it was a logical decision to contract with this group to also perform entry into the Idaho RCRS. As a result, the EMS Bureau performs a large percentage of the event entry into the Idaho RCRS. The ITD maintenance foremen that report road driving conditions execute these reports by radioing the EMS dispatchers, who then enter the reports into the RCRS. Similarly, if there are incidents that close or impact travel lanes (e.g., a tree falling in the road), any ITD staff observing or alerted to such an event would radio the report to the EMS dispatchers. Again, while they are dispatching response crews to clear the event, they also perform an entry into the RCRS. ITD executes a well-developed plan for training these dispatch staff. There is one EMS staff member designated as a liaison person with ITD. This is a full-time staff position enabling one person to regularly attend ITD meetings, and to fully understand the functions, reporting, dispatching, and response strategies of ITD. The liaison is then responsible for training the dispatchers to ensure the ITD procedures are followed. Based on experiences to date, ITD cited the following benefits:
Incident and Event Information Entry Industry Practice #9: Oregon Local Road and Special Location RCRSOregon DOT (ODOT) overcame challenges related to special events along local roads in metropolitan areas by developing a separate RCRS to be used exclusively for events on local roads, and special locations such as the vicinity to the professional basketball arena. This system provides the capability for ODOT to allow cities and counties to enter information about events along local roads. These events often include bridge openings (closing the bridge to traffic), local roadwork, and large events in the vicinity of the convention center or basketball arena. The special locations enable local communities to pre-define a geographic area that can be described by an event. The display to the traveling public (using the ODOT TripCheck website) is a shaded area, allowing travelers to understand that the event will impact all local roads in the area. Practices for Road Weather Information AssemblyRoad weather conditions is one of the most common types of information accessed by travelers through phone, web and social media services by DOTs. The dissemination of roadway conditions help travelers understand the impacts of inclement weather on their trips. Populating an RCRS with road weather information reports allows the various dissemination systems (i.e., phone, web, social media, DMS) to share this information in real-time with the traveling public. Eighteen states responding to the survey in this project indicated that road weather observations are included in their RCRS, as detailed in Table 5.
23 CFR 511 Requirements for Road Weather Information AssemblyThe parameters in the 23 CFR 511 Rule require that roadway weather observations be assembled within 20 minutes from time of observation along Interstates outside the metro areas, Interstates within the metro areas, and metro area routes of significance. Typical Procedures for Assembling Road Weather InformationThe procedures followed by the majority of agencies entering road weather information into the RCRS follow a series of steps similar to the following:
Challenges Facing RCRS Road Weather Information AssemblyRoad weather information assembly can describe information about the roadway surface (e.g., presence of snow or ice, wet pavement, etc.); sensor-recorded data describing atmospheric temperatures, wind, and precipitation; and pavement temperature sensor data, as summarized in Table 6.
Twelve of the eighteen states that participated in the project survey indicated they include road weather observations in their RCRS described the entry of conditions as a manual process (three indicated partially automated and three indicated fully automated). Including road condition information in the RCRS contributes to a number of challenges facing agencies, summarized as follows: Challenge #1: Condition Observation and Data Collection. For agencies that enter driving conditions into the RCRS based on the observations made by field staff, this requires a considerable amount of time that trained staff need to spend driving the roadways and observing conditions. Often, these observations are done while operators are plowing roads, or while maintenance staff are evaluating roads to determine maintenance activities. Automated data collection by environmental sensors and related Road Weather Information Systems (RWIS) update data automatically, however the data itself is typically related to measurements taken at the site of the sensor(s) and not automatically related to roadway segments in the RCRS. Challenge #2: Effort to Enter and Maintain Conditions. The manual step of entering roadway conditions on such a large number of road segments can present operational challenges for staff members. In addition, the activities required to maintain the roadway condition reports, updating them as conditions change or as roads are plowed or treated presents additional operational demands on staff. Similarly, the process of including weather measurements in the RCRS either relies on rules and algorithms to assign the readings from sensor locations to roadway segments, or requires manual entry of the conditions. Industry Practices to Address the Challenges of Road Weather Information AssemblyAs a result of the outreach efforts in this project, the following twelve industry practices that DOTs currently use to overcome the challenges of road weather information assembly in the RCRS were identified, and are presented in this section.
These industry practices are summarized as follows: Road Weather Information Assembly Industry Practice #1: Wyoming Enhanced Citizen Assisted Reporting (ECAR)Wyoming DOT (WYDOT) has developed an approach for citizens to report road conditions which are then used in the department’s RCRS11. WYDOT recognized the need to find a better way to get timely, accurate information about their roadways. They explored traditional options including increased maintenance reporting and additional roadway sensors – both of which posed a significant cost to the department. Instead, the department developed a crowdsourcing type of approach for gathering information from travelers. In 2005, the Enhanced Citizen Assisted Reporting (ECAR) feature was developed for their RCRS and by 2014 it had over 400 citizens sharing information about road conditions and any other incidents they observe on the road. A typical ECAR volunteer is someone who drives a particular stretch of road regularly, and possibly has been doing so on a long-term basis. Many volunteers are affiliated with a transportation company or business that travels Wyoming's highways, but volunteers also include commuters and leisure travelers. ECAR participants are supplied with an illustrated handbook which includes written and visual definitions of the different types of pavement and weather conditions used by WYDOT. As an example, the difference between “slick” and “slick in spots” is described. Volunteers are also instructed on how and when to report issues such as road kill or other debris on the roadway as well as how to report incorrect information on DMS and other roadside systems. After volunteers are trained, they interact with WYDOT operations staff to make their reports on designated routes. When they contact the department, their report consists of the following details:
As a member state of the North/West Passage pooled fund program, WYDOT participated in a 2011 project to share the ECAR experience with other states and explore the feasibility of other states developing similar programs. In the final report for that project, there is a series of suggested steps for an agency to develop a citizen reporting program. Most recently, Idaho and Utah have developed programs similar to WYDOT’s ECAR. The ECAR program has been beneficial for WYDOT. The primary benefits noted are:
Road Weather Information Assembly Industry Practice #2: Idaho Citizen Entry of Driving Condition into RCRSIn 2013, Idaho launched a function of their RCRS to enable citizens to perform entry of road condition events into the RCRS. The Idaho Transportation Department (ITD) 511 Website now includes an invitation for citizens to register to enter driving condition reports. In order to receive authority to perform condition reports, citizens must first create a personal account on the Idaho 511 Traveler Information site, and register any routes for which they intend to enter conditions. This is the same procedure citizens would perform to request alerts along routes or to personalize the 511 phone system to recognize them and play events along their routes of interest. Prior to granting reporting permissions the citizen reporters are provided training by ITD. A web page was specially created to enable citizens to perform entry. The selection of phrases is limited, and the citizens can only select those pre-defined segments that they have registered. Idaho and Wyoming cooperated in the development of the phrases to be used for the citizen entry of events. This is to promote consistent reporting on 511 websites across the Idaho – Wyoming borders, but also in the event that some citizens (e.g., long haul truckers) might register to perform citizen entry in both states, they could use consistent phrases. Road Weather Information Assembly Industry Practice #3: Utah DOT – Citizen Reporting of Driving ConditionsUtah DOT (UDOT) operates a system that enables citizens to report driving conditions to help enhance the road condition information disseminated to the traveling public12. In order to supplement the observations made by plow operators in the field, UDOT allows recruited and trained citizens to enter observed driving conditions to populate the reporting system and ultimately reach travelers viewing the website or calling 511. UDOT has maintained a strong relationship with the Utah Trucking Association, and has invited members of this organization as well as other members of the traveling public to be volunteers to enter observed driving conditions. The overall goal is to have 800-1,000 trained citizens who are authorized to enter driving condition reports. During the first winter of operation (2013-2014, Utah trained 475 volunteer reporters who submitted a combined total of 1800 reports on 120 of the 145 segments. UDOT management has been impressed with the quality and quantity of reports to date. The reports represent a new data set that adds value to the existing data sets. UDOT has determined that the accuracy rate is over 99%, which they attribute to the reporters training program. UDOT has invested considerable time in designing the citizen reporting system and how the citizen reported events will coexist with the other DOT condition reports.
Road Weather Information Assembly Industry Practice #4: Idaho Automated Integration of RWIS Data with the RCRSThe Idaho Transportation Department (ITD) has developed a system to process data generated from sensors operating RWIS environmental stations in real-time and automatically create event messages in their RCRS. This practice helps to increase the number of road driving condition events in the RCRS while reducing the manual effort required to maintain the information. The ITD RWIS Integration was an upgrade to the previous functionality to ingest and display RWIS data on the public website. Previously, the RWIS display on the public website identified the 100+ RWIS locations with icons and provided a mechanism for web visitors to click and view real-time weather information and camera images.
The system upgrade implemented in the fall of 2013 now operates to acquire the RWIS data and ingest it into the RCRS database where rules assign a “circle of influence” that the RWIS report is describing, and is shown in Figure 6. This circle of influence is represented as a circle on a map describing the area that is most likely described by the conditions reported. The stretch of highway that the RWIS data is assigned (and the related circle of influence) will vary based on the terrain. For example, data from RWIS stations on relatively flat straight roadways will have a larger area of influence. Data from RWIS stations in areas that are more hilly or mountainous would be assigned smaller circles of influence because conditions can change quickly as you travel a distance from the RWIS site. The ultimate plan is to automatically create events for stretches of highway based on the circle of influence assigned to each RWIS. Two types of reports are created based on the RWIS data:
Road Weather Information Assembly Industry Practice #5: Oregon DOT – RCRS Ingest of Weather AlertsOregon DOT (ODOT) operates an RCRS that ingests alerts (i.e., weather watches, warnings, and emergencies) from the National Weather Service (NWS). These alerts are either for county-wide areas or smaller more defined areas, as issued by the NWS. The NWS alerts are ingested exactly as issued by NWS. As the alerts are stored in the RCRS, the alerts are part of the traveler information displayed on the ODOT TripCheck website. In addition, because ODOT operators use the RCRS as their entry and management tool for entry of all events and dispatching of response, operators benefit from viewing the NWS alerts while dispatching maintenance response. The ingest of NWS watches and warnings allows ODOT staff and travelers to access NWS alerts, without any manual intervention to enter or edit weather information and content. Road Weather Information Assembly Industry Practice #6: Maryland Automated RWIS Ingest and Integration with Manually Entered EventsThe Coordinated Highways Action Response Team (CHART) RCRS13 ingests data from the Maryland State Highway Administration (MDSHA) RWIS network to deliver high-level roadway weather information to travelers. The RWIS data is also automatically added to any incident entered into CHART to maintain a record of road conditions at the time of the event. MDSHA has a statewide network of RWIS sites along state roadways. CHART polls the RWIS data once every minute and displays high-level roadway weather reports on the department’s traveler information web site. The high-level information includes air temperature, dew point, relative humidity, wind, gust speeds, visibility, precipitation and pavement temperature. Travelers also receive additional road condition information from the manually entered shop reports when a storm is underway. The RWIS data is also automatically attached to incidents (e.g., crashes, debris) that are reported in CHART. This helps MDSHA manage real-time incident response and maintain a record of road conditions in direct correlation with an incident when it occurs. MDSHA has leveraged their initial investment in RWIS for operations, in the further delivery of that information to travelers. It also enhances the shop reports that are manually entered during storms. Attaching the road condition data to incident records also allows the department to identify patterns between incidents and weather conditions. Road Weather Information Assembly Industry Practice #7: Ohio Automated Road Condition Entries into Buckeye Traffic RCRSOhio DOT (ODOT) has integrated their Road Weather Information System with their RCRS, Buckeye Traffic. The integration allows road conditions from 174 RWIS stations to be automatically fed to Buckeye Traffic every five minutes. The information is then posted to the department’s traveler information web site at OHGO.com. Buckeye Traffic ingests data from the department’s network of 174 RWIS stations throughout the state. The stations are typically located along Ohio’s interstate and major corridor system at 30-mile spacing and near county borders. The data from each site typically includes basic information on air and pavement temperature, pavement wet/dry status, precipitation type/intensity, and visibility. Additional information is also provided on relative humidity, dew point and wind speed/direction. Data is updated from each site every five minutes. It is then displayed on the department’s traveler information web site at OHGO.com. The density and updating frequency of RWIS allows both travelers and ODOT’s snow and ice staff to monitor both the onset and impact of storm activity in real-time, a valuable supplement to weather forecasts. During Ohio's snow and ice season (typically November through April), ODOT county garages and outposts throughout the state also update winter road condition approximately every two hours for their respective reporting locations. Buckeye Traffic displays the time at which the winter road condition for a particular route was last updated. Road condition data from Buckeye Traffic is also used for the department’s performance reporting on snow and ice control. The snow and ice control measure tracks hours from snow event close to normal operating speed as defined by ODOT’s travel time reliability index (TTRI). TTRI is defined as the percentage of time where the baseline travel time for a highway segment was not exceeded. For example, road condition data from Buckeye Traffic is used to determine if the department meets its goal for first priority routes – regaining 10 MPH within 0-3 hours. The automated data feed from RWIS ensures that road condition information is updated frequently and consistently, particularly if updates from maintenance staff are interrupted. This consistency is important for traveler information as well as performance reporting. Road Weather Information Assembly Industry Practice #8: North Dakota Automatic Ingest of Radar and Wind SpeedsNorth Dakota DOT (NDDOT) leverages two free data feeds for radar and wind speeds. The data is ingested by their RCRS14 and used for both operations and traveler information purposes. The data allows operators and travelers to see where weather may be coming from and when it may impact North Dakota roads. NDDOT uses a free data feed from the National Weather Service XML Feeds of Current Weather Conditions to overlay wind speeds in their RCRS. The data is updated every 15 minutes. If new data is not available from the NWS feed when queried, the RCRS automatically deletes the previous data and waits for the next query. This is done as a quality check to ensure that current reports are maintained in RCRS. The wind speed data is also passed from RCRS on to the department’s traveler information web site (www.dot.nd.gov/travel-info-v2/) as an information layer for travelers to view. Radar data from Iowa State University Iowa Environmental Mesonet (IEM) has also been integrated with NDDOT’s RCRS to provide operations staff and travelers with a view of weather that may impact North Dakota roads. This data is updated every five minutes and it is also provided to travelers in addition to road condition reports that are manually entered by NDDOT staff. Radar and wind speeds are both presented throughout North Dakota and in the surrounding regions to maximize the ability to track weather that may be moving toward the state. Both sources for radar and wind speed data are provided free of charge for NDDOT use. The automated feeds provide a consistent and frequent source of information for operators and travelers to monitor weather that may impact travel on North Dakota roads. It is also beneficial that the data is freely provided by both sources for NDDOT use. Road Weather Information Assembly Industry Practice #9: Iowa Ingest of National Weather Service AlertsThe Iowa DOT (IADOT) RCRS includes a module (CARS-CAP) that was designed to ingest National Weather Service watches, warnings, advisories and other similar products using the Common Alert Protocol (CAP). CAP is an XML-based information standard used to facilitate emergency information sharing and data exchange across local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. The use of CAP allows the Iowa RCRS to receive NWS alerts and then redistribute them to Iowa’s traveler information services. For example, the data is displayed on 511ia.org under Weather Warnings for the affected counties. The weather information is displayed separately from road conditions, which are entered manually by staff throughout the state. As other emergency warnings are distributed using the CAP standard, the Iowa RCRS would be capable of receiving these as well, provided the CAP standards are adhered to. IADOT has recognized the following benefits of using the CAP standard:
Road Weather Information Assembly Industry Practice #10: Idaho Segment Entry Tool for Efficient Entry of Road ConditionsIdaho Transportation Department (ITD) operators receive radio reports from maintenance foremen describing driving conditions on pre-defined segments and they use an RCRS feature to quickly enter or update multiple segments. Unlike the creation of a one-time RCRS event, where the operator needs the RCRS to allow the selection of the route, the starting point, and the ending point when describing the location, the entry of driving conditions is based on radio reports from maintenance foremen who have recently plowed or observed conditions on the road. The foremen provide quick radio updates that identify the segment ID and the conditions. The ITD RCRS includes a screen that enables operators to enter driving condition reports for segments or multiple segments quickly. Operators may select a segment, or a group of segments (e.g., if a foreman radios in that a number of segments all have the same condition) or even areas from the screen. Once selected, the operators can quickly select from limited options on drop down lists for describing the driving conditions and enter the report. Another function that the segmented entry feature performs is to aggregate data for adjacent segments when the reports are identical. In other words if a stretch of road is divided into three sequential segments (Segment 1, Segment 2, and Segment 3) and an operator selects the same conditions for Segments 1 and 3, the RCRS will create one event for the entire extent of Segments 1, 2, and 3. This helps the information dissemination tools (e.g., 511 phone and web, twitter, email) reduce the number of identical reports. Therefore, callers would hear of only one event and the location described as from the start of Segment 1 to the end of Segment 3. This feature in the ITD RCRS has tremendously reduced the time required for operators to perform road condition entry. Since ITD uses a central call center for all the maintenance foremen to radio reports to, during winter storm they are bombarded with road condition reports. This has made the entry something they can accomplish without keeping the maintenance foremen on the line for too long. In addition, the set of standard pull-down menus for road and weather conditions produces highly consistent travel reports, with little to no variation between individual data entry personnel. Road Weather Information Assembly Industry Practice #11: Utah plow operators and Meteorologist staff reporting driving conditionsUtah DOT (UDOT) reports both current and forecasted driving conditions for state maintained highways for up to the next 24 hours on their traveler information website. The RCRS is used to assemble all the driving condition reports that are then plotted on web-based maps as colored roadways. UDOT’s approach towards reporting driving conditions allows them to report accurate road condition reports to travelers not only for current conditions but up to 24 hours into the future. In order to generate accurate and useful descriptions of the driving conditions, UDOT utilizes four approaches for assembling the road condition reports during winter seasons:
Beyond the benefits to the traveler information system, UDOT has recognized several benefits of the meteorologists on staff, including the dialog and discussions between plow drivers and dispatchers and the meteorologists to plan winter weather response. During summer months, the meteorologists continue to play a critical role in monitoring and managing weather situations such as flooding and forest fires, and also use the time to perform on-site maintenance of the 80 RWIS sites. The benefits cited of the overall approach towards road condition reporting are:
Road Weather Information Assembly Industry Practice #12: Wyoming DOT’s use of Road Condition Messaging GuidelinesAs the Wyoming DOT (WYDOT) considered revisions to their traveler information web site, they incorporated recommendations from Guidelines for Disseminating Road Weather Advisory & Control Information developed by the FHWA Road Weather Management Program in June 2012. WYDOT overhauled www.wyoroad.info in 2012 to address newly released recommendations from FHWA for road weather messaging. The department completely rewrote the software that displays textual information on their web site to be in accordance with the messaging guidelines. The Wyoming Travel Information (WTI) system is WYDOT’s RCRS. It delivers condition codes to a database and the new display software grabs the information from the database to create web pages. Prior to making these changes, WYDOT did extensive surveying of customers to fine tune their modifications. They posted before and after examples on their web site and sought feedback through a brief online survey. The survey asked how easy it was to navigate the site, if the impact level colors were helpful, and if the “description/recommended actions” were clear for each impact level. Final modifications were based on a combination of the recommendations from FHWA and customers. The department also created a series of Frequently Asked Questions for their web site to explain the purpose of the changes. In addition to using the FHWA guidelines for modifying their web site, WYDOT also used them to change DMS timing, phrases and approach. The changes were made in department operating procedures and in the software that displays messages on the signs. Operators now speak of “PLA” – problem, location, action for incidents. Finally, WYDOT used a hybrid of the guidelines for DMS and web sites to develop content for a series of event center monitors. The monitors display special versions of text pages with imbedded The department has a series of monitors installed at the University of Wyoming Arena Auditorium and the Casper Event Center to provide travelers with information as they leave events. The benefits cited by Wyoming include:
Practices for Travel Time Information AssemblyTravel time information is beneficial to travelers planning to depart on a trip and those travelers who are currently en-route. A number of DOTs currently display travel time information on DMS, through the 511 phone system, through traveler information websites and various social media outlets. Similarly, real-time travel time data is commonly included in the in-vehicle navigation displays of vehicles. The sources of travel time data range from DOT calculated and supplied information to private sector products. Of the states responding to this project’s survey, twelve indicated that they include travel time information in their RCRS as shown in Table 7.
23 CFR 511 Requirements for Travel Time Information AssemblyThe parameters in the 23 CFR 511 Rule require that travel time information is to be available within 10 minutes latency along Interstates and designated routes of significance within the metro areas. Typical Procedures for Assembling Travel Time InformationTravel time information requires automated collection or calculation of actual travel times or speed data from which travel times are derived. The following are technology approaches used today:
Challenges Facing RCRS Travel Time Information AssemblyAll twelve of the states in Table 7 above that indicated they include travel times in their RCRS described the entry of travel times as a fully automated process. The inclusion of travel times in the RCRS is too time dependent to be a manual process. Therefore, all instances involve automated integration from travel time sources to populate the RCRS. During the research for this project, two distinct differences in approaches for including travel times were identified:
Industry Practices to Address the Challenges of Travel Time Information AssemblyAs a result of the outreach efforts in this project, the following five industry practices were identified describing approaches that agencies use to overcome the challenges of travel time information assembly in the RCRS.
These industry practices are summarized as follows: RCRS Integration of Speed and Travel Time Industry Practice #1: New York State Thruway Authority TRANSMIT Travel Time IntegrationThe RCRS that the New York State Thruway Authority (NYSTA) operates includes a module that integrates travel time data from TRANSCOM’s System for Managing Incidents and Traffic (TRANSMIT). TRANSMIT is a comprehensive system that includes traffic surveillance and incident detection and is based on E-ZPass electronic toll collection tags and toll readers located in multiple states. Since 1993, travelers on the New York State Thruway have had the option of electronic toll collection using the E-ZPass system. TRANSMIT aggregates all the toll tag reads to generate travel time data that is completely void of any personal information about any individual vehicles. The volume of E-ZPass equipped vehicles allows for accurate reporting of travel times. The NYSTA RCRS includes a module (referred to as CARS-TIMES) that ingests the travel time data available from TRANSMIT. Once the travel time data is in the RCRS, the times are used to generate travel times for key segments of the Thruway. These travel times are then disseminated on DMS reporting travel to downstream landmarks, on the website, and through the Highway Advisory Radio (HAR) broadcasts. The NYSTA RCRS also includes functionality that considers the TRANSMIT travel time data and automatically generates events describing locations of slow traffic. These events describe the portion of the Thruway experiencing slower than normal traffic, and are disseminated on the website, broadcast on the HAR towers, or displayed on DMS. NYSTA cited benefits of the travel time data ingest to be:
RCRS Integration of Speed and Travel Time Industry Practice #2: Maryland CHART Automated Speed and Travel Time ReportsThe Maryland State Highway Administration (MDSHA) purchases private sector data on roadway speeds to provide the basis for their Coordinated Highways Action Response Team (CHART) RCRS to develop speed and travel time reports. INRIX, a third party data provider, provides data in a link-based format for MDSHA’s CHART system to assess and develop into reports about speed and travel time on state roadways. CHART also determines which DMS to active with an incident report once it is developed. The reports are also shared via the MDSHA traveler information web site. Travelers can view roadway speeds under the site’s “Traffic” page and they can view DMS messages about travel time or other incident information under the site’s “Info Devices” page. The information allows MDSHA to respond more efficiently to incidents and provide travelers with information that minimizes delay and the likelihood of secondary incidents. Each year, the University of Maryland conducts an independent evaluation of CHART as a program using data from the RCRS component. In their latest evaluation, the University concludes, “With respect to its performance, CHART has maintained nearly the same level of efficiency in responding to incidents and driver assistance requests in recent years. The average response time in 2012 was 9.92 minutes. In view of the worsening congestion and the increasing number of incidents in the Washington-Baltimore region, it is commendable that CHART can maintain its performance efficiency with diminishing resources. In brief, CHART operations by MDSHA in Year 2012 have yielded significant benefits by assisting drivers, and by reducing delay times and fuel consumption, as well as emissions.” RCRS Integration of Speed and Travel Time Industry Practice #3: Ohio Buckeye Traffic Automated Integration of Travel Time InformationOhio DOT (ODOT) receives speed and travel time information from a network of sensors deployed by SpeedInfo and from INRIX. The data is integrated with their Buckeye Traffic RCRS15 to provide travelers with automated travel time information in and between key urban areas around the state. The information is also posted to the department’s traveler information web site at OHGO.com. ODOT purchases roadway data from SpeedInfo, third part data provider, and INRIX to provide travel times in and between their major urban areas throughout the state. The department prescribes the format of the data from both sources. The data is polled every minute during the day and every five minutes during the evening hours to conserve energy consumption from the roadside devices that are used to collect some of the data. Before data is transferred to Buckeye Traffic or any of the department’s real-time traveler information services it is quality checked through an ODOT database where systematic quality checks are performed to identify gaps in the data. ODOT also requires both vendors to provide a confidence score on their data. The confidence score is self-reported and this was closely checked by ODOT staff in the early stages of deployment to establish confidence in the quality of the data and self-reporting process. The automation and comprehensiveness of the data available from SpeedInfo and INRIX eliminate the need for the department to operate and maintain its own infrastructure and the quality check conducted on the data ensures a consistent, reliable source of information for travelers. RCRS Integration of Speed and Travel Time Industry Practice #4: Sacramento Integration of Speed Data from PeMSThe Sacramento Area Council of Governments (SACOG) reporting system ingests real-time speed data for freeways in the Sacramento area from the Caltrans Performance Measurement System (PeMS). In California, data is collected from over 25,000 individual detectors on freeways throughout the state. The SACOG RCRS16 includes an automated ingest of detector data for freeways in and around the Sacramento area. The SACOG RCRS ingests speed, volume, and occupancy data for display to the operators. The SACOG RCRS operates a function that analyzes the speed data from PeMS to automatically create events in the RCRS describing slower than normal traffic conditions. An example of an actual slow traffic event automatically created using the speed data is: US 50 westbound: between FOLSOM BLVD (Rosemont) and Exit 15: LINDEN RD (Rancho Cordova). Traffic is slow. The creation of events describing slow traffic allows SACOG to communicate conditions to travelers using multiple approaches (beyond just an Internet map displaying colored road segments). The fact that the slow traffic is described as an event on a road between two locations allows the slow traffic report to be disseminated over the 511 phone system and DMS messages, or sent to travelers using an email alert system or social media outlets. The benefits are described as follows:
RCRS Integration of Speed and Travel Time Industry Practice #5: Texas DOT Integration of Travel Time Data from Various SourcesThe Texas Department of Transportation (TxDOT) calculates travel times in metropolitan areas and these travel times are integrated into the RCRS, allowing for dissemination on various travel information systems. TxDOT fuses together multiple data sources to generate travel time reports. These data sources include loop detectors, radar, blue tooth readers, and 3rd Party data acquired through various agreements. The travel time data sources are denser in the metropolitan areas, and rural areas rely more on 3rd party data. The travel times are fused together to create travel time reports. Practices for Transit Information AssemblyTravelers who are planning or considering transit for commute or leisure trips benefit from information dissemination describing planned departure times and real-time information reporting transit delays. It is common that transit systems are operated by a metropolitan planning organization (MPO) or a local or regional transit agency, and subsequently the information dissemination is often the responsibility of these agencies. As a result, it is not uncommon for transit information to be separate from DOT operated traveler information systems. Initiatives such as Integrated Corridor Management (ICM) that encourage real-time comparisons of freeway, arterial, and transit travel times benefit from integration of transit updates with other events impacting the road network. This project’s survey did not ask questions about the inclusion of transit information in the RCRS, however the research identified industry practices related to this integration. 23 CFR 511 Requirements for Information AssemblyThere are no current requirements in the 23 CFR 511 for transit information. Industry Practices to Address the Challenges of Transit Information AssemblyOne of the most prominent challenges with assembling transit information in an RCRS is that transit services are often managed by an agency other than the DOT operating the RCRS. As a result of the outreach efforts in this project, the following two examples of state DOTs integrating transit information into their RCRS were identified.
These industry practices are summarized as follows: RCRS Integration of Transit Information Industry Practice #1: Sacramento transit routes and bus arrival integration into RCRSThe Sacramento Area Council of Governments (SACOG) operates a comprehensive RCRS that supports manual and automated data entry into one central system for the use of operators managing traffic and incidents as well as dissemination to the traveling public. One aspect of the SACOG RCRS is the integration of transit routes and transit vehicle status into the RCRS. The SACOG RCRS includes transit routes operated by local transit agencies. Transit agency staff can use the RCRS (with additional transit module) to enter descriptions of events impacting transit service. This might be a bus running behind schedule, a bus stop closed because the road is closed, or a change in service. These changes entered to the bus route to update the actual progress of buses is stored in the RCRS and output to the traveler information website. In addition, the RCRS generates a General Transit Feed Standard (GTFS) XML output that is delivered to Google Transit. This allows riders who use the Google Transit Trip Planner to receive not only static route schedule information, but also updated information based on actual conditions. Therefore, if one bus is running behind schedule and a rider were to miss a connection, the transit trip planner can describe alternate routes or transit plans. SACOG is working on the integration of automated vehicle location (AVL) data. Once integrated, this will increase the frequency of vehicle delay entry and further improve. SACOG identified the following benefits of including transit information in the RCRS:
RCRS Integration of Transit Information Industry Practice #2: Idaho integration of transit information into RCRSThe Idaho Transportation Department (ITD) has implemented a module to their RCRS to enable transit agencies to enter their transit route information. Using this RCRS enhancement, ITD has worked with 9-10 transit systems in Idaho and in neighboring states if routes extend into Idaho. Their approach was to include as many transit providers as possible to support trips that involve connecting transit systems. ITD has included the large transit provider in Boise (operating approximately 50 buses) and small transit providers with as few as one bus. The fact that transit routes and schedules are created inside the RCRS module allows ITD to publish the route information using the GTFS protocol, which is sent to Google for inclusion in the Google Transit Trip Planner. The RCRS inclusion of transit routes also enables the transit agencies to enter updated reports describing the transit services (e.g., delays, closed bus stops, etc.). ITD is planning to integrate AVL data from the buses, and related schedule adherence information, as a next step in expanding the functionality. ITD identified the following benefits of including transit information in the RCRS:
Practices for Regional Integration and InteroperabilityTravelers regularly make trips that cross jurisdictional borders and involve combinations of US, state, and local highways. To these travelers, they rely on consistent comprehensive information. Regional integration or interoperability between neighboring jurisdiction’s RCRSs contributes to travelers receiving a ‘seamless’ perspective of the travel conditions they will experience. Challenges Facing Regional Integration and InteroperabilityFor transportation agencies, there are several challenges to assembling regional information that describes roadways operated by multiple jurisdictions. These challenges include: Challenge #1: Nomenclature Consistency. While standards exist for phrases describing conditions on the highways, the use of these phrases is not consistent. For example, describing a roadway as “icy” as compare to “patches of ice” may be a matter of opinion or preference. To a traveler, these different uses of nomenclature could imply a change in conditions from one highway to the next. Challenge #2: Consolidation of Data from Different Sources. There are a number of examples of metropolitan areas where commuters cross multiple state or local jurisdictions. Consolidating the data allows commuters to view a comprehensive trip report. The consolidation of data can be challenging if the systems are not able to exchange ITS standards based phrases using common protocols. These challenges may include different approaches for describing locations, different phrases to describe conditions. Industry Practices Assisting Regional Integration and InteroperabilityAs a result of the outreach efforts in this project, the following three examples of DOTs achieving regional integration and interoperability of RCRSs were identified.
These industry practices are summarized as follows: RCRS Regional Integration and Interoperability Industry Practice #1: TRANSCOM Common RCRSThe Transportation Operations Coordinating Committee (TRANSCOM) is a coalition of 16 transportation and public safety agencies in the New York – New Jersey – Connecticut metropolitan region. It was created in 1986 to provide a cooperative, coordinated approach to regional transportation management. The three state agencies all use a common RCRS system, providing economies of scale and facilitating total integration of data between the three state agencies. A key best practice of the three states using the common RCRS is that the system allows users in any TRANSCOM state to have a seamless view of incidents in all three states. The common RCRS also allows coordination of incidents across jurisdictions. RCRS Regional Integration and Interoperability Industry Practice #2: Lake Michigan Interstate Gateway AllianceThe Lake Michigan Interstate Gateway Alliance (LMIGA) originally developed the Gateway Traveler Information System (GTIS) that ingests reports from the partner agencies, consolidates them into one overall database and displays them on the Travelmidwest website to benefit travelers throughout the Great Lakes region. Today, LMIGA and the Great Lakes Regional Transportation Operations Coalition (GLRTOC) operate the GTIS to integrate incidents, events, and construction reports from the RCRSs of participating agencies (including Minnesota, Wisconsin, Illinois, Northwest Indiana, and Michigan). RCRS Regional Integration and Interoperability Industry Practice #3: Sacramento RCRS Integration of Neighboring Jurisdiction InformationThe Sacramento Area Council of Governments (SACOG) RCRS integrates traffic, access to Closed Circuit Television (CCTV) camera images, and DMS messages from surrounding transportation agencies. This gives RCRS operators a more universal view on conditions affecting the Sacramento area. The SACOG RCRS acquires data and information describing traffic and events on surrounding roads and highways (outside SACOG control). This enables the SACOG operators to view and understand the traffic volumes and events that are on roads operated by neighboring agencies to better understand and plan for events and incidents on the SACOG operated roads. This approach benefits the operators using the RCRS and gives them a more universal view of the events and incidents impacting travelers on their highways. Practices for Data Reliability, Accuracy, and TimelinessWhile there are a number of examples of automated data collection and creation of RCRS events, a large portion of the data describing events is manually entered into the RCRS. As such, the RCRS information is only as timely, accurate, and useful as the data entered into the RCRS. Challenges Related to Assembling Timely, Reliable, and Accurate InformationAgencies operating RCRSs face numerous challenges as they strive for timely, accurate, reliable data entry, including: Challenge #1: Consistency. Different operators may interpret observed events or conditions differently, and/or may select different phrases to describe them. Challenge #2: Time Constraints. Often the times that incidents occur or conditions change are busy times for TOC operators. Entry into the RCRS competes with many additional activities that operators must perform, especially if the RCRS entry process is time consuming. Challenge #3: Operator Judgment. Often the decision about what events to enter into the RCRS or what priority to assign them is assigned to operators, and different operators might reach different decisions regarding the value of publishing events. Industry Practices that Promote Timely, Reliable and Accurate Information AssemblyThe following industry practices were identified as existing practices used to promote effective data assembly in the RCRS.
These industry practices are summarized as follows: RCRS Data Reliability, Accuracy, and Timeliness Industry Practice #1: Iowa DOT RCRS Training to Promote Consistent Data EntryThe Iowa DOT (IADOT) RCRS17 includes considerable flexibility in allowing operators to select from multiple phrases when creating an event description. The first phrase selected is the key phrase and determines the icon for display on websites, and sets the default priority. Beyond the key phrase selected, operators may also choose multiple phrases to describe an event. This is critical because the impacts vary for every event. For example, roadwork may cause no impact to travelers or it may close a lane or seriously delay travel. Using this example, operators might select two phrases to describe an event: “roadwork”, “right lane close”. With the option of being able to select the order that the phrases appear when disseminated, operators have great flexibility. However, this can contribute to inconsistencies in the way events are reported. IADOT has developed a policy that the first phrase selected should always be a description of the impact. Therefore, in this example, the operator would have ordered the phrases as follows: “Right lane closed, due to Roadwork”. Through training and a procedures manual, IADOT has achieved consistency in reporting. As a result, a quick glance at the map display on http://511ia.org displays various icons, some representing lane closures, some representing traffic slowdowns, and some roadwork. Visitors can easily understand which roadwork events are causing impacts to the travelers. Figure 7 was shared by IADOT to illustrate how web visitors can view the impacts of different events simply by observing the icons, rather than a map displaying all roadwork events using a roadwork icon, those events that cause lane closures have a lane closure icon, and those that close the road have a road closed icon.
RCRS Data Reliability, Accuracy, and Timeliness Industry Practice #2: Oregon Automated Creation of RCRS Messages to Achieve ConsistencyThe creation of the messages that are generated by the Oregon DOT (ODOT) RCRS when a user enters information is controlled by internal rules and procedures in the RCRS. Therefore, regardless of the order that users select the phrases, the RCRS will generate the message and order the phrases and information according to the design of the program. ODOT believes this helps to ensure that the reports from their RCRS are consistent regardless of the user who created the event. Similarly, since the ODOT RCRS is also the software used for radio log entry and DOT maintenance dispatch, all events communicated to one of the ODOT TOCs is entered (regardless of how much or little impact the report has). Therefore, the operator does not use their own judgment about whether or not to enter the event or to publish the event to traveler information systems. Again, internal rules and logic in the RCRS decides which events have enough impact for the RCRS to publish out to information dissemination systems and other public and private subscribers. RCRS Data Reliability, Accuracy, and Timeliness Industry Practice #3: Washington State Streamlined RCRS EntryThe current Washington State DOT (WSDOT) RCRS has been in operation since 2008. This system replaced an earlier RCRS that had been used by WSDOT since 2000. Feedback from users who used the previous (First Generation) RCRS was that it was too complex and since they have a lot of tasks to perform in the center, they needed a simple and quick tool for entry of incidents and events. The current WSDOT RCRS is a single web page, allowing entry of all aspects of the incidents and events without the need for multiple pages. Users of the WSDOT RCRS cited the following benefits:
Practices for Funding and Managing Development and System ChangesThe use of RCRSs allows the consolidation of many types of information and supports multiple information delivery mechanisms. However, there are costs associated with the development, management, and operations of the systems. Challenges with Funding and Managing RCRS Development and System ChangesAgencies developing or operating RCRSs face a series of challenges. Challenge #1: Multiple Opinions. The fact that RCRSs typically have multiple users from multiple groups within the DOT creates a challenge to manage the multiple opinions on the changes needed and/or software enhancements. Challenge #2: Internet Compatibility. The Internet has been a great catalyst in the expansion of RCRSs, and offers users the ability to access on-line RCRSs from any computer with Internet access. However a challenge this introduces is the continuously changing browser versions and/or on-line mapping options and user expectations. As a result, agencies tend to develop upgrades to their RCRSs regularly, in order to take advantage of new capabilities or to support the new browsers that users operate. Challenge #3: Local Configurations. Users in different groups within the DOT (or geographic regions) may request local configurations to meet their specific needs that may contradict with statewide standards. Managing such requests can be challenging when budgets or software development staff time is limited. Industry Practices that Address Funding and Managing RCRS Development and System ChangesResearch in this project identified the following six industry practices that agencies use to manage RCRS development and modifications.
These industry practices are summarized as follows: Funding and Management for RCRS Development and System Changes Industry Practice #1: Collaboration in RCRS Development, Maintenance, and OperationsThe Transportation Operations Coordinating Committee (TRANSCOM) is a coalition of 16 transportation and public safety agencies in the New York – New Jersey – Connecticut metropolitan region. It was created in 1986 to provide a cooperative, coordinated approach to regional transportation management. The three state agencies all use a common RCRS system, providing economies of scale and facilitating total integration of data between the three state agencies. A key best practice of the three states using the common RCRS is that the system allows users in any TRANSCOM state to have a seamless view of incidents in all three states. The common RCRS also allows coordination of incidents across jurisdictions. The TRANSCOM member states use the OpenReach RCRS developed by CoVal. The Condition Acquisition and Reporting System (CARS) was initially created through a Transportation Pooled Fund that began in 1998 with a consortium of transportation agencies in North America. Member states drive the ongoing improvement and extension of CARS based on their needs and budgets. Currently, seventeen transportation agencies have deployed and are still using the CARS system, have deployed and operated the system but no long operate it, or are currently in the process of deploying the CARS system. These seventeen agencies include (or have included in the past) the City of Calgary, Idaho, Indiana, Iowa, Kentucky, Louisiana, Maine, Minnesota, New Hampshire, New York, the New York State Thruway Authority, Rhode Island, Sacramento (through the Sacramento Area Council of Governments), Vermont, and Washington State. The members of the consortium cited the following benefits of collaboration:
The software system that is now used in both Texas and Florida as an RCRS was originally developed by the SouthWest Research Institute (SWRI) for the Texas Department of Transportation (TxDOT). Recognizing the portability of the software, TxDOT made the software available to the Florida Department of Transportation (FDOT) at no charge. While there were no restrictions on the use of the software, FDOT contracted with SWRI to customize the software to meet FDOT’s needs and also to add functionality to the software system. TxDOT has received any software additions that FDOT has added to the software. Therefore, while there is no formal consortium linking the two states, there continues to be a sharing of software development and benefits are acknowledged by both agencies. Funding and Management for RCRS Development and System Changes Industry Practice #2: Internal DOT Staff Developing RCRS SoftwareAll aspects of software development and hosting of the Washington State DOT (WSDOT) RCRS (ROADS) are performed in-house. WSDOT believes they have been successful in keeping software developers and IT staff because of the flexibility they offer to developers allowing them to be creative when solving problems and developing software. The advantages and disadvantages of in-house staff performing the programming described by WSDOT include:
In summary, WSDOT has had a good experience with in-house DOT staff developing and supporting the RCRS. They recognize they are in a somewhat unique situation, and are fortunate that their situation has resulted in some long-term employees working on software systems for the DOT for a long time. Funding and Management for RCRS Development and System Changes Industry Practice #3: University Development and Support of RCRS SoftwareThe modular RCRS used in Wisconsin includes one module that is a vendor supplied ATMS product and two modules that were developed by the University of Wisconsin TOPS Lab. Wisconsin DOT (WisDOT) and the University of Wisconsin-Madison TOPS Laboratory have an ongoing relationship that includes the TOPS Lab developing and supporting software used by WisDOT. The Lane Closure System (LCS) and Winter Roads System (WRS) are two modules of the RCRS developed by the University. The benefits of university development of the RCRS include:
Funding and Management for RCRS Development and System Changes Industry Practice #4: RCRS Templates Used for Local ConfigurationTexas DOT (TxDOT) and FDOT have collaborated together, both contributing to the event management system that is now referred to as the SunGuide Software System in Florida and the Lonestar System in Texas. The systems perform the functions of an RCRS as well as a TMC/TOC event management software system. Several functions of the software system were developed to allow DOT administrators to configure the system to meet unique needs of the various users, without the need for software programming changes (both Florida and Texas have multiple TOCs using their respective systems). For example, the software system automatically generates recommended DMS messages in response to current conditions and incidents. This supports the operators and allows for quick consideration of all conditions when deciding which messages to post to multiple DMS. DOT operators have the capability of customizing how they want different types of events to be described on DMS. For example, operators can configure a template describing how major crashes should be described in a DMS message, and another template modification can describe how minor crashes should be defined. Another example relates to performance measure reporting. The FDOT deployment of the software system includes a comprehensive performance measure creation function. The performance measures are built using SAP® Crystal Reports. An administrator screen allows operators to create templates for the performance measure reports, and to make any changes to the configurations (either for calculations or reporting descriptions). Funding and Management for RCRS Development and System Changes Industry Practice #5: Modularity in RCRS DesignWisconsin DOT (WisDOT) operates separate ‘modular’ components that function together as a comprehensive RCRS. The RCRS comprises three separate systems, developed independently, and each operates an XML output to feed traveler information systems. The Wisconsin Lane Closure System (WisLCS) – An entry tool and related database that is used to perform entry and updates describing current and future lane closures. The Winter Roads System (WRS) – an entry tool and related database that is to enter driving condition reports. Finally, an ATMS system used to modify or enter incident information (also performs all standard ATMS functionality). Together, these three modular systems accomplish the functionality needed from an RCRS. The ATMS system is a vendor supplied system, and the WisLCS and WRS were developed by the TOPS Lab at the University of Wisconsin-Madison. Each ‘module’ of the WisDOT RCRS has a different set of users who primarily use the system. For example, the WisLCS is an Internal Business Process & Approval system that is used to enter and eventually approve road closures. Therefore, this is used by planning, construction, and maintenance groups, as well as Statewide TOC operators. The WRS is used by the Wisconsin State Patrol to describe driving conditions. Finally, the ATMS is used by the Statewide TOC users to manage events and traffic, controlling DMS and other field devices. Because each system is modular, each can be custom built to meet the users’ unique needs, while maintaining standards-based interfaces to other systems. Collectively, all systems generate data using XML feeds that meet the reporting needs of WisDOT. The benefits of the modular design of the WisDOT RCRS are:
Funding and Management for RCRS Development and System Changes Industry Practice #6: User Group Managing RCRS Software ChangesThere are six Washington State DOT (WSDOT) Regions all using the common RCRS to create reports of incidents, events, driving conditions, and roadwork on the state maintained highways. Each Region has multiple users, all with different perspectives on features and functions in the RCRS. WSDOT faced the challenge of how to manage multiple, competing requests for changes to the system. WSDOT created an Applications User Group that consists of:
Collectively, the Application User Group meets monthly, just prior to the monthly TMC managers meeting to discuss requested changes from each District. The IT support member is able to offer insight regarding the amount of time and costs that would be required for changes (e.g., they may comment that one change being discussed is a simple configuration change and would require little programmer time, while another change might require a major database restructure and therefore considerably more time and resources). The WSDOT Headquarters staff is able to comment on the resources available (WSDOT has developed and supports the RCRS software using in-house software programmers with a certain amount of time dedicated to supporting the RCRS each month). The Application User Group elects one member to chair the group (from one of the Regions represented, not the HQ staff), and they must resolve any conflicting opinions about changes. They reach decisions about how to dedicate the WSDOT software programming resources to make enhancements or changes to the RCRS. As a result of this user group, the users of the RCRS now feel like they have ownership in the system, and decision making authority. Funding and Management for RCRS Development and System Changes Industry Practice #7: Alaska DOT&PF Using DOT Geodatabase for RCRSThe Alaska DOT and Public Facilities (AKDOT&PF) RCRS18 defines the locations of events as either single points on the road network (e.g., a crash at an intersection) or segments of a roadway (e.g., packed snow occurring from point A to point B). A map display and a set of roadway attributes are used to allow operators to select the location of events. This can be done by either selecting the exact milepoint, an intersection, or other landmarks. The source for the features used to define the AK RCRS road network (and therefore describe events in the RCRS) is the AKDOT&PF Geodatabase. As a result, events entered in the RCRS and disseminated on the public website are displayed on high quality, accurate maps that represent the true roadway network as defined by AKDOT&PF. AKDOT&PF is currently operating an ESRI Spatial Database Engine/Oracle Geodatabase. The Geodatabase was designed to store and manage the linear reference based centerline network and associated roadway features and attributes. The AKDOT&PF linear referenced enterprise geodatabase is built on ESRI technology using ArcGIS and ArcSDE, and uses an Oracle database. The linear reference system uses a unique CDS number (CDS_NUM field) to identify each route. Locations along a route are designated using a milepoint, or offset in miles, from the beginning of the route. Point features (such as signs and intersections) are stored in point event tables and related to a specific route with a single milepoint value (MPT field). Line features or attributes (such as guardrails or functional classification) are stored in line event tables and related a specific route with both from and to milepoint values (FROM_MPT and TO_MPT fields). The LRS design simplifies data management by automatically ensuring that a change to the centerline network (e.g., when a roadway is realigned) is reflected in the associated point and line events. AKDOT&PF wanted to use their Geodatabase for all maps displaying incidents and events to the traveling public through the 511 Website. This was to ensure high quality maps and to avoid dependence on Internet based mapping solutions. Therefore, the RCRS and related public website are all built using the linear referenced centerline network in the Geodatabase. A regular update process is used to port changes to the AKDOT&PF road network directly to the Geodatabase used for the RCRS, thus ensuring the maps are as accurate and up to date as possible. A benefit to this is also the ability to layer event reports over the maps. For example, roadway driving conditions are layered on top of the maps created from the Geodatabase, allowing the system to color the road to reflect driving conditions with great precision. Another benefit is the use of the Geodatabase list of consumer friendly location names. AKDOT&PF has invested time and resources identifying consumer friendly names for landmarks, and as changes are reported or new landmarks identified, these are entered directly into the Geodatabase. Because the RCRS uses this Geodatabase, there is no need to create a separate set of landmark names. Funding and Management for RCRS Development and System Changes Industry Practice #8: CARS Consortium Use of Location CodesThe states using the RCRS developed by the CARS Consortium described the use of location codes to describe the linear attributes of the routes included in the RCRS. In some states, such as Idaho, this layer is separate from the layer used to display RCRS events using Google maps. Events that are entered by an operator or ingested from outside systems must be assigned to geolocated attributes to support map displays or geo-referenced queries. Those member agencies using the CARS RCRS described the approach to mapping events for displays. The RCRS utilizes two different data sources for map creation:
The combination of the background maps and the internal location code database is able to accomplish the user needs for selecting DOT defined attributes while still benefitting from the functionality of high quality map displays. The input for this Best Practice was received from the Idaho Transportation Department (ITD) (a member of the CARS Consortium), however the Best Practice is a benefit of the software product recognized by all members. Practices for Balancing Possible and PracticableThe introduction and expansion of the Internet has fostered an increase in the dissemination of information. The potential for traveler information dissemination on the Internet includes a vast number of creative mechanisms to disseminate incredible amounts of information. Challenges with Balancing Possible and PracticableThe following challenge was identified for the decision of what to include in the RCRS and related information dissemination systems. Challenge #1: RCRS Scope. A challenge all agencies must face is the decision of what to include in the RCRS, and ultimately how to disseminate the data that is in the RCRS. The more information included, the more complex the interfaces become and the more expensive operations and enhancements are. Similarly, the RCRS users and the travelers who ultimately benefit from the system have increasing expectations. Industry Practices for Balancing Possible and PracticableThe outreach in this project asked operators of RCRSs to describe how they consider all that is possible and ultimately decide what is practical and affordable to include in the RCRS. The following four examples were identified.
These industry practices are summarized as follows: Balancing Possible and Practicable Industry Practice #1: Sacramento Area Council of Governments Insight into selecting RCRS contentWhen asked about how they maintain a balance between all the possibilities of an RCRS and consideration of information overload to travelers and available budget, Sacramento Area Council of Governments (SACOG) acknowledged that information overload of the travelers is a serious concern of theirs, but they also recognize that different travelers benefit from different information types and display types. They believe the architecture of their information dissemination systems enables them to offer various levels of information (e.g., extremely detailed information about incidents for those who seek to understand it, but also high level ‘glance’ summaries of the information. One example of these multiple layers of details is found on the website. A recent event was displayed on the SACOG Traveler Information Website reporting ‘slow traffic’, as follows:
This is just one example of the concept that they are able to provide a variety of information types and detail level using the design of the website to allow visitors to select what they want, and ignore the rest. For reference, the SACOG traveler information website is http://www.sacregion511.org/. Balancing Possible and Practicable Industry Practice #2: Idaho’s Insight into selecting RSRS contentThe Idaho Transportation Department (ITD) commented on the topic of information overload to travelers and available budget. They noted that the department has had an adequate budget to dedicate to technology development that has allowed them to keep up with the mediums of information dissemination that travelers expect. ITD is also concerned about information overload, but feel their contractor has done a good job engineering the user interface to allow multiple approaches to traveler information, while allowing website visitors to find and focus on their specific needs. They relayed that the cooperative development of their RCRS (CARS) with other states has contributed to these well engineered user interfaces, as lessons have been learned from multiple state deployments. For reference, the ITD website is http://511.idaho.gov/. Balancing Possible and Practicable Industry Practice #3: New York State Thruway Authority’s Insight into selecting RCRS contentWhen asked the question about the balance of all the available data and balancing information overload and budgets, the New York State Thruway Authority (NYSTA) responded by describing that their approach is to only include “actionable” information on their information dissemination systems. They cited the example of weather information and their decision not to include weather data from RWIS sites. They describe that if there were weather events causing alerts or advice to travelers, those would be entered as events through the RCRS, but they do not wish to overload the system with any information that is not considered ‘actionable’. For reference, their traveler information website is: http://www.thruway.ny.gov/travelers/index.html. Balancing Possible and Practicable Industry Practice #4: Oregon DOT’s insight into selecting RCRS contentThe representative from Oregon DOT (ODOT) described their overall approach towards avoiding information overload by noting that ODOT has never had a policy that ‘more is better’ in regards to information dissemination. For example, they recognize that they could show DMS locations on the public website together with the message displayed on the DMS, but they would prefer that the website visitors access information about events through the clickable icons. Therefore, they opt for a more streamlined approach to the information dissemination, rather than multiple mechanisms for displaying the same information. For reference, their traveler information website is: http://www.tripcheck.com. You may need the Adobe® Reader® to view the PDFs on this page. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
||
 |
United States Department of Transportation - Federal Highway Administration |
|
The research conducted through this project identified a number of practices in use by the industry to enter and update data within the RCRS, and to develop, manage and maintain RCRSs. This chapter presents a set of industry practices for RCRS operations and use. The industry practices have been arranged into two categories to allow readers to better focus on their specific interests.
