1 / 61

Travel Information Services Program Track Committee Meeting

Travel Information Services Program Track Committee Meeting. January 30, 2007 Delaware Valley Regional Planning Commission Philadelphia, PA. Agenda. Welcome and Agenda Purchasing a Travel Time Data Service Are You Ready? Vehicle Probe Project Update

gezana
Download Presentation

Travel Information Services Program Track Committee Meeting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Travel Information ServicesProgram Track Committee Meeting January 30, 2007 Delaware Valley Regional Planning Commission Philadelphia, PA www.i95coalition.org

  2. Agenda • Welcome and Agenda • Purchasing a Travel Time Data Service Are You Ready? • Vehicle Probe Project Update • Passenger Information Program Demonstration • Project Updates • 2007 Information Exchange Forum • ISN • 511 Support Project • Year 15 Work Plan – Committee Report & Discussion • Coalition Calendar/Next Meeting www.i95coalition.org

  3. Purchasing Travel Time Data: An Investigation of Travel Time Data Service Requirements Brian Lee Smith www.i95coalition.org

  4. Purchasing a Travel Time Data Service Are You Ready? Brian L. Smith Associate Professor I-95 Corridor Coalition Travel Information Services Program Track Committee January 30, 2007

  5. Presentation Overview • Topic Introduction • How Did We Get Here? • Public Sector • Private Sector • Guidance - NCHRP 70-01 • Feasibility Conclusions • Procurement Suggestions • Draft Requirements • Conclusions

  6. Travel Time Data Service • A travel time data service provides “near-term” estimates of travel times for defined roadway links over defined measurement intervals to paying subscribers (may be a public sector agency or a private company) • May take on different forms • “Packaged” with a map user interface • “Raw” data stream

  7. Traffic Alert Generator (ITIS Holdings)

  8. Data Stream(Airsage)

  9. How Did We Get Here?Public Sector • Transportation agencies have a clear need for measured travel time data • Operations • Basic Traveler Information • Performance Measurement • Analyses • Data currently available to most agencies come from agency-owned “point” sensors installed on relatively few facilities • Point sensors can be used to estimate travel time – but not measure it

  10. How Did We Get Here?Private Sector • Technologies have emerged that allow for probe vehicle data collection without requiring equipment installation or maintenance on right-of-way • Cellular phone signaling data • GPS • Using probe data – travel time measurements may be derived • Private sector perceives market for travel time data • Private information delivery firms • Public agencies

  11. Point Detector Off-ramp On-ramp = Probe Sample What Are Probes?

  12. OK … sounds good, right? • There are two huge questions that stand in the way of agencies moving forward with this approach to travel time data acquisition: • Can travel time data service firms provide data of acceptable quality and availability for public sector needs? • Can the public sector afford to purchase a data service?

  13. Experience to Date • CAPITAL Project • US Wireless • “Modern” Era • Baltimore • Hampton Roads • Missouri • Kansas City • Atlanta • Tampa • Others

  14. TRB 2007 Session #473Traffic Probes: How Well Do They Work? If Not Now, When? • Panel of evaluators and service providers • Consensus • Data quality is acceptable on heavily traveled freeways • Not all roads and regions are created equally • Arterials – not yet • Costs • Still largely a question mark

  15. What to Do? • Difficult environment in which to make decisions • Significant risks still involved with purchasing a travel time data service • No competitive alternatives to acquire wide area travel time data

  16. NCHRP 70-01 • Private-Sector Provision of Congestion Data • Final Draft Report submitted to the panel in early November 2006 Project Objectives • Critically examine the ability of deployed probe-based monitoring to produce accurate and reliable traffic condition data. • Assess “lessons learned” from past and ongoing deployments of this technology • Determine potential legal barriers to utilizing this technology for traffic data collection • Develop guidance that transportation agencies may use to assist in entering into agreements with firms selling traffic data services

  17. UVA CTS Experience • Probe Demonstration System Evaluators • US Wireless • Hampton Roads (Airsage) • Simulation Modeling • VDOT Technical Support • Travel Time Data Service Requirements • Travel Time Data Collection Plan

  18. Technology • Cellular • Mining call hand-off data from cellular networks • GPS Fleets • Mining GPS data from fleet management systems • Combination Systems • Use both cellular and GPS data

  19. Business Environment • Small number of firms positioned to provide traffic data services • In general: • Firms are small • Obtain “raw” data under agreements with larger, “source” firms • Cellular carriers • Fleet management service firms • Nearly all projects to date with public sector clients have been demonstration or research projects

  20. Data Provided • Average link travel time and speed data • Link sizes vary – but generally on the order of 1-2 miles • Measure time intervals are usually on the order of 5 minutes • A measured estimate of travel time on a link can not be provided for every time interval/link combination with certainty

  21. Data Accuracy/Availability • Simulation modeling indicates that the method can feasibly provide sound quality data • Most current deployments are still in evaluation phase: • Atlanta • Airsage • Cellint • Kansas City • Baltimore • Missouri • Hampton Roads

  22. Moving Forward • It is feasible to collect freeway traffic data of reasonable accuracy and availability using probe-based systems. • There are no obvious legal barriers to using this technology to produce link condition estimates • There are significant risks involved with this approach, most notably: • Lack of maturity of technology • Involvement of multiple companies in the “data stream” • Numerous demonstration projects have been undertaken. At this stage, agencies interested in acquiring such data should seek to enter into well-defined data service agreements with vendors. • Transportation agencies must have a clear understanding of their requirements before entering into any further agreements

  23. Guidance • NCHRP 70-01 provides concrete guidance to aide agencies in moving forward with procuring a traffic data service • Guidance intended to allow agencies to move forward aggressively, while mitigating risks

  24. Competitive Demonstration Procurement Approach • Issue RFP • 1 year agreement with option for annual renewal up to 3 years • Short-List • References • Cost Structure • Demonstrated ability to meet requirements • Demonstrated ability to provide long-term, stable service • Competitive Demonstration • 1 month • Negotiate Agreement

  25. Requirements • Probe-based monitoring is significantly different than traditional point-sensor networks traditionally used by agencies. • Requirements for point-sensors (i.e. very short polling intervals, high accuracy requirements at the “point”, etc.) are not appropriate for probe-based systems. • Clear requirements are needed to drive acceptance testing and on-going lifecycle testing. • Traffic data service providers must have a clear idea as to agency expectations in order to make an informed decision as to whether or not to invest in a demonstration phase of the procurement method.

  26. Key Assumptions and Limitations • Defining requirements for a new service involves risk • Two schools of thought: • We don’t know what to ask for – we’ve never seen a service like this before. • If you don’t know what you’re asking for, you certainly won’t get it. • Key Assumptions: • Purchasers of traffic data should define minimal data requirements to meet planned uses of the data. • Purchasers of traffic data should not dictate the technology or approach used to collect the data.

  27. Methodology • Define Data Consumers • Define Travel Time Measures Requirements • What will be purchased • Define Requirements for Data Acceptability

  28. Expected Travel Time Data Applications • Real-time Operations • High-level Traveler Information Provision • Transportation Operations Performance Measures

  29. Requirement Categories • Spatial coverage requirements • Temporal requirements • Measurement requirements • Data quality requirements • Service availability requirements • Data quality validation requirements • Data usage requirements

  30. Spatial Coverage Requirements • Travel time shall be measured by direction for the following functional systems: • Interstate Highways • Other Limited Access Highways • Links shall be defined from interchange to interchange • Possible criteria for link selection • AADT thresholds • SAFETEA-LU 1201

  31. Temporal Requirements • Travel time measures shall be provided at regular measurement time intervals. • The measures for each interval shall be provided to the data purchaser within 10-seconds of the end of the measurement interval. • Required measurement time intervals may vary based on the time-of-day and type of facility monitored. • The default measurement time interval shall be 5 minutes • Traffic data shall be provided from 6:00 am – 7:00 pm

  32. Measurement Requirements • The following data shall be provided for each link monitored in the system at each measurement time interval. Note that the units for travel time shall be minutes. • Mean travel time • Standard deviation of travel time • Number of samples used to calculate the statistics • Maximum travel time measured during the interval • Minimum travel time measured during the interval

  33. Data Quality Requirements • Link travel time measures provided by the private sector shall have a maximum of 20% average absolute percentage error when compared to ground truth data. This requirement is applicable on a link-by-link basis (i.e. the error measured at each link shall meet this requirement). • An aggregate of link travel time measures provided by the private sector shall have a maximum of 10% average percentage error when compared to ground truth data. This requirement is applicable on average to all links monitored by the system. • Travel time measures shall be provided for 90% of all measurement time intervals for all links.

  34. Service Availability Requirements • The agency shall be provided with documentation to prove that the traffic data service will remain available throughout the life of the agreement. • Documentation may include: • Copies of agreements with “core” data providers • Commitment letters from “core” data providers • Contingency plans for replacement of probe data when “core” data source is lost

  35. Data Quality Validation Requirements • Annual Data Quality Validation Testing • Quarterly Self-Reporting of Data Quality

  36. Annual Data Quality Validation Testing • The data service provider shall be provided with a written annual baseline data collection and data quality analysis plan one month prior to the annual validation testing. This plan will be negotiated and agreed-upon by both parties. In the event that the parties cannot come to an agreement, the purchaser shall have the right to terminate the agreement. • The annual service acceptance testing effort shall consist of baseline data collection over the period of 2 consecutive weekdays. The data service provider shall provide all travel time measures to the purchaser during this testing period. The purchaser will collect baseline data as outlined in the plan using either its own forces or a 3rd party independent organization. • In the event that the data analysis demonstrates that the travel time data does not meet requirements, the purchaser shall have the right to terminate the agreement.

  37. Quarterly Self-Reporting of Data Quality • The data service provider shall provide the purchaser with a quarterly data validation plan. This plan shall document the data collection method and sampling approach that will be used, the time period of data collection, and the links to be tested. Note that part of this plan shall be documentation of the format in which data availability for the previous quarter will be reported. This plan will be negotiated and agreed-upon by both parties. In the event that the parties cannot come to an agreement, the purchaser shall have the right to terminate the agreement. • On a quarterly basis, the data service provider shall deliver the results of their self-assessment of data quality for the previous quarter, using the quarterly test plan agreed upon at the outset of the agreement. The data service provider shall also deliver the “raw” baseline data collected. • In the event that the data analysis demonstrates that the travel time data does not meet requirements, the purchaser shall have the right to terminate the agreement.

  38. Data Usage Requirements • The purchaser shall have the right to use travel time data purchased from the data service provider for all internal agency applications. This includes the right to archive the data and use it for an unlimited period of time. • The agency shall have the right to use travel time data to provide direct traveler information using the following means: • 511 • Variable Message Signs • Highway Advisory Radio • The purchaser shall not share the data directly with other organizations. This, however, excludes the purchaser’s right to create visualizations of the data (i.e. maps, graphs, etc.) for presentation and distribution.

  39. Conclusions • Based on results from early system deployments and from simulation studies, it can be concluded that probe-based traffic monitoring is a feasible approach to collecting traffic data on heavily traveled freeways. • It is important to note that there has yet to be a long-term, “production-level” deployment of this technology in the United States. • It is recommended that agencies move from a “demonstration” mentality to a services contracting approach in which • Agencies clearly state their requirements • Agreements established to mitigate risks • NCHRP 70-01 provides specific guidance to assist agencies

  40. For More Information Brian L. Smith briansmith@virginia.edu http://cts.virginia.edu

  41. Multi-State Vehicle-Probe Based Traffic MonitoringUpdate Bill Stoeckert www.i95coalition.org

  42. Vehicle Probe Project Status • Multiple briefings to Coalition members • Request for Information (RFI) issued 10/1/06 • RFI responses received 11/10/06 • Analysis of responses completed • Conference call with the project team 11/29/06 • Executive Board briefing 12/11/06 • Distributed questionnaire to Coalition members regarding interest, funding and ability to use data www.i95coalition.org

  43. Vehicle Probe ProjectNext Steps • Continue preparation of RFP • With approval of project team, release RFP mid March 2007 • Estimated contract award date December 2007 www.i95coalition.org

  44. Passenger Information Projects- Live DemonstrationMatt Coogan www.i95coalition.org

  45. WORKINGLUNCH www.i95coalition.org

  46. Project Updates • 2007 Information Exchange Forum • ISN • 511 Support Project www.i95coalition.org

  47. Traffic Data to Travel Information – How do I get there?Information Exchange Forum • Location: Raleigh, NC • Date: June 21, 2007 • Project Team: Hubert Clay, Scott Cowherd, Gene Glotzbach, Bob Rupert www.i95coalition.org

  48. Traffic Data to Travel Information – How do I get there? • Speakers: • Don Cooke • FHWA • International speaker • Information needs www.i95coalition.org

  49. What the Coalition is Planning – The ISN • Information Systems Network (ISN) • ISN emphasizes moving data/info, not operational response • Currently, developing functional requirements to enable sharing of real-time information to support long-distance travel and system management needs www.i95coalition.org

  50. ISN Development Features • ISN will work with existing systems • Automated interfaces will be developed • No duplicate, manual data entry • Existing systems, including the Web-IEN, will be assessed relative to requirements • Candidate locations/pilot states will be identified for initial deployment www.i95coalition.org

More Related