521B-26.pdf

Rev. 05/27/2025 1

Ohio Department of Transportation

Request for Proposal No. 521B-26 Speed Data Services

Table of Contents I. Requirements/Specifications

1. Background

1.1 Proposal Purpose

1.2 Data Collection

1.3 Data Coverage

2. Prequalification Questionnaire

3. Required Data and Services

3.1 Data and Services

3.2 Data Application Programming Interface (API) Requirements

3.3 Data Querying/Download Tool Requirements

3.4 Initial Data and Services Load Schedule

4. Required Analytics Tools and Services

4.1 Speed Data Analytics Tools

4.2 Analytics Application Programming Interface (API) Requirements

4.3 Initial Analytics Tools Load Schedule

5. Optional Data, Services, and Tools

5.1 Traffic Signal Analytics Tools/Platform

5.2 Additional Data, Services, and Tools

5.3 Initial Load Schedule for Optional Data, Services, and Tools

6. Availability and Accuracy

6.1 Data Availability

6.2 Data Accuracy

6.3 Data Quality

7. Support

7.1 Technical Support

7.2 Ongoing Support

8. Training

9. Qualifications and Experience

9.1 Qualifications

9.2 Experience with Transportation Use Cases

Rev. 05/27/2025 2

II. Contract Information

1. Duration

2. Pricing

3. Invoicing

4. Deductions

III. RFP Process

1. Schedule

2. Proposal Submission Requirements

2.1 Proposal Submission

2.2 Inquiries

2.3 Uploading of Requested Files

3. Demonstration Period

IV. RFP Scoring

1. Scoring of Technical Proposal

2. Scoring of Cost Proposal

3. Final Score

Appendix A: Data and Tools Response Templates

1. Speed Data Templates

TABLE A1-1: METADATA FIELDS

TABLE A1-2: REAL-TIME SPEED DATA FIELDS

TABLE A1-3: HISTORICAL SPEED DATA FIELDS

TABLE A1-4: HISTORICAL DATA QUERYING TOOL FIELDS

2. Dangerous Queueing Template

TABLE A2: DANGEROUS QUEUEING FIELDS

3. Bottleneck Data Template

TABLE A3: BOTTLENECK DATA FIELDS

4. Speed Data Analytics Tools Templates

TABLE A4-1: PERFORMANCE REPORT SUMMARY FIELDS

TABLE A4-2: USER DELAY FIELDS

(the remainder of this page has been left intentionally blank)

Rev. 05/27/2025 3

I. Requirements/Specifications

1. Background

1.1 Proposal Purpose

The Ohio Department of Transportation (ODOT) Office of Transportation Systems Management and Operations (TSMO) is seeking the services of a qualified data services vendor (hereby known as the Proposer) to provide the following three (3) distinct Data Services for the State of Ohio:

1. Real-Time speed data,

2. Historical speed data , and

3. Analytics Tools.

The proposed data solution must be responsive to the following key usages:

• Real-Time o Speed and Travel Time information

▪ OHGO inSIGHT: ODOT’s Advanced Traffic Management System (ATMS),

▪ OHGO: ODOT’s Traveler Information System (TIS) website and mobile application,

▪ Dynamic Message Signs (DMS), etc.

o Map Tile Service, including traffic speeds,

▪ Used for ATMS and TIS o Dangerous Queueing

▪ Used for ATMS and TIS

• Historical Data o Key Performance metrics

▪ Traffic Operations Assessment Systems Tool (TOAST)

▪ ODOT Critical Success Factors (CSF): System Performance

• Snow & Ice Control

• Travel Time Performance o Performance Dashboards (Data & Applications | Ohio Department of Transportation)

• Analytics Tools o Before and After Studies o Project Prioritization o Traffic Incident Management

▪ After Action Reviews

▪ Time to return to normal o Arterial Management

▪ Signal retiming analysis

▪ Travel time performance o Work Zone Management o System-wide traffic impact prediction for roadway closures and detours

Access to the data, API, and analytics tool(s) shall be granted to all users from the approved agencies listed in Table 1.

TABLE 1: APPROVED AGENCIES

Ohio Department of Transportation (ODOT) Ohio Turnpike and Infrastructure Commission (OTIC) https://www.transportation.ohio.gov/wps/portal/gov/odot/working/data-tools/resources/toast https://www.transportation.ohio.gov/programs/tsmo/data/data

Rev. 05/27/2025 4

Other State of Ohio Agencies Ohio Local Governments Metropolitan Planning Organizations (MPOs) Regional Transportation Planning Organizations (RTPOs)

While account access will not generally be given to private/university entities, ODOT or an approved agency account holder shall be able to provide the speed data and/or temporary access to analytics and data querying tools to a consultant(s), university, or a similar entity working on their projects solely for use in that project. At the conclusion of the project, access to the analytics and querying tools will be withdrawn from the entity. ODOT may distribute and/or grant access to the Proposer data to third-party vendors responsible for maintaining ODOT systems, such as the Advanced Traffic Management Systems (ATMS), GPS/AVL system, Traveler Information System (TIS), etc. The third-party vendor shall be prohibited from using or distributing the data for any purpose other than the approved ODOT system.

1.2 Data Collection

Speed data may be collected in any non-intrusive method that represents data along a segment of roadway.

Proposer(s) must clearly indicate the method(s) and technology being used to collect the data. For example, speed may be collected using probe-based collection methods such as GPS, mobile devices, connected vehicle sensors, etc. The data shall be representative of vehicle mixtures (i.e., passenger vehicles and commercial vehicles/trucks) utilizing Ohio’s roadway system. As part of their response, the Proposer should indicate the average penetration rate within Ohio and include the percent of data from passenger vehicles versus commercial vehicles/trucks. While not required, additional data that differentiates between passenger vehicles and commercial vehicles/trucks should be cited in this section as potentially exceeding the minimum RFP requirements. Speed data shall not include an upper-limit cap to the averaged speeds that were captured along the roadway.

1.3 Data Coverage

1.3.1 Routes

Data shall be provided for, at a minimum:

• 100% of Interstate route centerline mileage;

• 99% of non-Interstate National Highway System1 (NHS) route centerline mileage; and,

• 95% of all remaining State Highway System2 (SHS) route centerline mileage.3

The required coverage percentages will be calculated as follows:

The Department will overlay in geospatial software (e.g., ArcGIS Pro) the Proposer-provided shapefile with the National Highway System shapefile maintained by ODOT (see footnote 1) and the State Highway Priority System shapefile maintained by ODOT (see footnote 2). All shapefiles will have their geometry re-projected to the NAD83/Ohio South (EPSG:32123) coordinate reference system. ODOT-

1 View the National Highway System on TIMS map:

https://tims.dot.state.oh.us/tims/map/sid/gxBAzY Note: The Intermodal Connector routes are not required as part of the National Highway System requirement.

2 View the State Highway System on TIMS map (may need to zoom to see active layer):

https://tims.dot.state.oh.us/tims/map/sid/JRrpEY Note: Route types of IR, US, and SR are considered part of the State Highway System.

3 Shapefiles of the specified route systems may be downloaded via TIMS using the attributes table for each dataset:

https://tims.dot.state.oh.us/tims/data https://tims.dot.state.oh.us/tims/map/sid/gxBAzY https://tims.dot.state.oh.us/tims/map/sid/JRrpEY https://tims.dot.state.oh.us/tims/data

Rev. 05/27/2025 5 maintained shapefiles may be modified to ensure only centerline miles are captured. If the Proposer-provided segmentation overlaps the respective category above without any visible gaps (at a scale of 1:1,500,000) between the ODOT-maintained and Proposer-provided shapefiles (excluding the Lake Erie Islands), as determined in ODOT’s sole discretion, the Department will accept the submittal as prima facie evidence that the required coverage percentages have been met. If the overlap reveals gaps in required coverage, the Department will perform a geospatial intersection of the two data sources using geospatial software (e.g., ArcMap) with a buffer of 35 meters. The coverage percent will be calculated as the total sum of covered centerline miles4 divided by the total centerline miles for each category5.

Data shall be provided in each direction for all routes. Additionally, for areas where parallel roadways (i.e., Express Lanes and Collector/Distributor sections) exist, additional data segments are required. The Proposer shall provide speed data to ODOT for every route in Ohio for which they have coverage. In the future, any additional Ohio coverage the Proposer adds shall be included at no additional cost for the duration of this contract. In addition to the Ohio routes, data shall be provided for any Interstate, US, and State Routes for adjacent states one county deep.

The Proposer shall provide a shapefile of their available data segments by uploading the file with their submission in Ohio Buys. The coverage requirement will be scored based on the following ranges of coverage percent:

TABLE 2: COVERAGE PERCENT RANGES FOR SCORING

DNM Partial Meets Exceeds Interstate Non-Responsive 100% n/a Non-Interstate NHS Non-Responsive 99-100% n/a All other SHS Non-Responsive 95-97.99% 98-100%

Failure to meet the required coverage percentages for ALL categories will result in the Proposer being considered non-responsive. Non-responsive Proposers will be disqualified from further consideration, and their cost proposal will neither be opened or considered.

1.3.2 Segmentation

Data shall be provided by the vendor in the most granular/high resolution segmentation, shorter than Traffic Message Channel (TMC), available (hereby called high-resolution segments/segmentation”).

Segmentation must be fixed except for regularly scheduled segmentation updates. ODOT shall be notified at least 30 days in advance of any regularly scheduled segmentation updates. Any applicable files pertaining to the regularly scheduled segmentation update shall be received by ODOT at least 10 business days in advance of the release. Data shall be provided for each segment representing the average speed of

4 The total sum of covered centerline miles is defined as the sum of the length in miles of each feature in the intersected feature class.

5 For the purpose of this RFP, the total centerline miles for each category are:

• Interstate Routes: 1,340

• Non-Interstate NHS routes: 3,924

• All other SHS routes: 14,018

Rev. 05/27/2025 6 the entire segment across all directional lanes. Proposers shall discuss the granularity, segmentation, and type and frequency of regularly scheduled segmentation updates for their data as part of this response. If by-lane data is also available, this should be discussed as part of the Proposer’s response.

Failure to meet the high-resolution segmentation requirements will result in the Proposer being and their cost proposal will neither be opened or considered.

2. Prequalification Questionnaire Failure to provide an affirmative response to all the pre-qualifying questions in this section will result in the Proposer being considered non-responsive. Non-responsive Proposers will be disqualified from further consideration, and their cost proposal will neither be opened or considered.

1. Does the Proposer’s product offer data at a high-resolution granularity, smaller than Traffic Message Channel (TMC) standard segmentation (see Section I.1.3.2 Segmentation)?

2. Does the Proposer’s product offer data at a minimum frequency (see Section I.3.2.1 Speed Data APIs) of:

a. 1-minute intervals for Real-Time, and

b. 5-minute intervals for Historic?

3. Can the Proposer supply historic Bottleneck data (see Section I.3.1.3 Bottleneck Data) on all State

Highway System routes (see Section I.1.3.1 Routes)?

4. Does the Proposer offer a Map Tile service meeting the specifications of Section I.3.1.4?

3. Required Data and Services

3.1 Data and Services

3.1.1 Speed Data

The following data elements must be provided at a minimum:

TABLE 3: REQUIRED METADATA ELEMENTS

Element ID Element Description M1 Segment ID Unique segment identifier M2 Road Number Number associated with the roadway (i.e. Interstate or

State Route number) M3 Travel Direction Direction of traffic on the roadway M4 Segment Length Length in miles M5 Start Latitude/

Longitude The beginning geometric latitude and longitude of the segment (Note: this may be split into multiple fields)

M6 End Latitude/ longitude

The ending geometric latitude and longitude of the segment (Note: this may be split into multiple fields)

TABLE 4: REQUIRED SPEED DATA ELEMENTS

Element ID Element Description

Rev. 05/27/2025 7

S1 Segment ID Unique segment identifier S2 Date/Time Date and Time of data point collection (specify time zone in response) S3 Recorded Speed Average speed across all directional lanes for the stated time period S4 Expected Speed Normal expected speed based on, at a minimum, time of day, day of week, month, season

S5 Freeflow Speed Speed motorists can travel when unobstructed from weather, congestion, incidents, etc.

S6 Confidence Value The likelihood that a data point reported is from real speeds, historical, or a combination thereof

The selected Proposer shall provide a shapefile, and optionally a GeoJSON file, with the metadata and linear geometry for all data segments upon contract award and for any subsequent coverage updates and/or map version edits throughout the life of contract.

The Proposer's response shall include, at a minimum, a listing of all data fields, a description of the fields, data type for each field, an example value for each field, and the corresponding Element ID (e.g., M1, S1, etc.) for the following data sets:

• segmentation metadata;

• real-time speed data API;

• historical speed data API; and,

• historical data querying/download tool (if it varies from historical data API).

Additionally, as part of the response, the Proposer shall include their definition of expected speed, freeflow speed, and confidence value.

The Proposer shall use the response templates in Appendix A - Speed Data Templates as part of the above response.

Failure to provide ALL required data elements for metadata (Table 3) and BOTH real-time and historical speed data (Table 4) will result in the Proposer being considered non-responsive. Non-responsive Proposers will be disqualified from further consideration, and their cost proposal will neither be opened nor considered.

Additional data elements may be provided in the feed as long as the required data elements from Table 3 and Table 4 are included. The following are not required, but would provide value to the Department if available:

TABLE 5: ADDITIONAL METADATA ELEMENTS (OPTIONAL)

Element Description Road Name(s) One or multiple common names for the roadway County County of Roadway segment State State of Roadway segment Number of Lanes Average number of lanes across the segment (in one direction)

Rev. 05/27/2025 8

Routing Information One or more fields indicating the order of segment(s) adjacent to the current (Next/Previous Segments)

Functional Class The class or group of roads to which the segment belongs

TABLE 6: ADDITIONAL SPEED DATA ELEMENTS (OPTIONAL)

Element Description

Travel Time The time to travel across the length of the segment based on current speed

Sample Size Number of probes or a representation thereof that were used in the calculation of speed data on a given segment for a given timestamp

85th Percentile Speed The speed at or below which 85 percent of all vehicles are observed to travel on a given segment for a given timestamp

50th Percentile Speed The speed at or below which 50 percent of all vehicles are observed to travel on a given segment for a given timestamp

Congestion Percent Measured speed as a percentage of the free flow speed Accuracy Value The assessed accuracy of the data point Speed by Lane Average travel speed per each lane

If the Proposer has other fields beyond the minimum, they should be discussed as part of the response.

Optional Data Elements can be included in the response templates found in Appendix A - Speed Data Templates.

3.1.2 Dangerous Queueing

The Department requires real-time dangerous queueing event data on the entire National Highway System (as defined above in Section I.1.3.1 Routes) for the purpose of effective traffic management and the safety of the traveling public. Dangerous queueing events, for the purpose of this requirement, are defined as a location where the speed of one segment differs from the speed of the adjoining segment by an established threshold (at least 20 mph difference), resulting in a potentially hazardous speed drop that may require hard braking.

The following dangerous queueing elements must be provided at a minimum:

TABLE 7: REQUIRED DANGEROUS QUEUEING ELEMENTS

Element ID Element Description

Q1 Id Unique identifier of the dangerous queue instance Q2 Date/Time Date and Time of occurrence (specify time zone in response) Q3 Segment 1 Speed Speed of the segment representing the end of queue Q4 Segment 2 Speed Speed of the segment prior to the end of queue Q5 Speed Difference Change in speed between the end of queue and adjoining segment Q6 Latitude Latitude of the end of dangerous queue Q7 Longitude Longitude of the end of dangerous queue

Rev. 05/27/2025 9

The Proposer’s response shall include, at a minimum, discussion on the methodology for identifying dangerous queueing events, including the threshold used for identification, the frequency and latency of the feed, a listing of all data fields, a description of the fields, data type for each field, an example value for each field, and the corresponding Element ID (e.g., Q1, Q2, etc.). If the Proposer has other fields beyond the minimum, they should be discussed as part of the response..

The Proposer shall use the response template in Appendix A - Dangerous Queueing Template as part of the above response.

Failure to provide ALL required data elements for Dangerous Queueing (Table 7) will result in the Proposer being considered non-responsive. Non-responsive Proposers will be disqualified from further consideration, and their cost proposal will neither be opened nor considered.

3.1.3 Bottleneck Data

The Department requires historic bottleneck data utilizing high-resolution segmentation on the entire State Highway System (as defined above in Section I.1.3.1 Routes) for the purposes of TOAST and its Performance Dashboards. Real-time bottleneck data is optional. Bottleneck data, for the purpose of this requirement, is defined as a location where speeds differ from the reference speed by a percent threshold for a certain amount of time, resulting in a queue of traffic.

The following bottleneck data elements must be provided at a minimum:

TABLE 8: REQUIRED BOTTLENECK DATA ELEMENTS

Element ID Element Description

B1 Id Unique identifier of the bottleneck occurrence B2 Start Date/Time First date and time that the bottleneck was identified B3 Duration Length of time bottleneck impacted the roadway B4 Start Latitude Latitude of the head of the bottleneck B5 Start Longitude Longitude of the head of the bottleneck B6 End Latitude Latitude of the tail of the bottleneck B7 End Longitude Longitude of the tail of the bottleneck B8 Max Length (mi) Maximum length of roadway impacted by bottleneck in miles

The Proposer’s response shall include, at a minimum, discussion on the methodology for identifying bottlenecks, including the percent threshold used for identification, a listing of all data fields, a description of the fields, data type for each field, an example value for each field, and the corresponding Element ID (e.g., B1, B2, etc.). If the Proposer has other fields beyond the minimum, they should be discussed as part of the response.

The Proposer shall use the response template in Appendix A - Bottleneck Data Template as part of the above response.

Failure to provide ALL required data elements for Bottleneck Data (Table 8) will result in the Proposer being considered non-responsive. Non-responsive Proposers will be disqualified from further consideration, and their cost proposal will neither be opened nor considered.

Rev. 05/27/2025 10

3.1.4 Map Tile Service

The Proposer shall make available a tile service that returns images containing traffic graphics. The tile service shall allow for:

• the ingestion of map tile images encompassing the state of Ohio in its entirety, with routes visible at appropriate, progressive scales;

• custom line/segment widths and opacity on the resulting map tile image for each request;

• custom speed/congestion ranges with custom corresponding colors for each request; and,

• the use of Bing Maps Tile System quadkeys to describe the geographic area for which a map tile image is to be returned, or a mechanism for converting Bing Maps Tile System quadkeys to a format supported by the Proposer.

The returned image shall have a transparent background that will allow it to be overlaid on top of other basemaps with only the requested data visible.

The proposer shall discuss their map tile service and their ability to meet the above requirements as part of this response.

Failure to provide a tile service that meets the requirements above will result in the Proposer being and their cost proposal will neither be opened nor considered.

3.2 Data Application Programming Interface (API) Requirements Failure to provide ALL required API feeds in this section will result in the Proposer being considered non-responsive. Non-responsive Proposers will be disqualified from further consideration, and their cost proposal will neither be opened nor considered.

3.2.1 Speed Data APIs

3.2.1.1 Real-time Data API

High-resolution segmented, real-time data shall be provided through a web-based API in either JSON or XML format. Data shall be provided from the API meeting the specifications of Section I.3.1.1 Speed Data for all timestamps and available according to the requirements in Section I.6 Availability and Accuracy.

Real-time data shall be updated and provided at a maximum interval of 1 minute. The Proposer’s real-time API must be capable of supporting at least 15 requests per minute from ODOT.

The Proposer should specify the format of their Real-time API response and discuss the update intervals as part of their response.

The real-time API must be immediately ingestible by the OHGO inSIGHT ATMS to support travel time calculations for Intelligent Transportation System (ITS) devices, such as Dynamic Message Signs. The Proposer must demonstrate that their real-time API is currently being ingested by existing inSIGHT ATMS platforms and is fully compatible for integration into the OHGO inSIGHT ATMS upon contract award.

Solutions that require development or configuration post-award will be considered non-responsive.

Failure to demonstrate past performance in an inSIGHT ATMS and ability to immediately deploy to OHGO inSIGHT ATMS will result in the Proposer being considered non-responsive. Non-responsive

Rev. 05/27/2025 11

Proposers will be disqualified from further consideration, and their cost proposal will neither be opened nor considered.

3.2.1.2 Historic Data API

Historical data shall be provided through a web-based API in JSON, XML, or CSV format; or a compressed data file containing any of the four previous data formats. Data shall be provided from the API meeting the specifications of Section I.3.1.1 Speed Data for all timestamps and available according to the requirements in Section I.6 Availability and Accuracy.

Historical speed data shall be provided and accessible for time periods as recent as two days (48 hours) old, as a minimum. Historical speed data must be available in 5-minute, 15-minute, and 1-hour time granularity intervals.

The Proposer should specify the format of their Historic API response and discuss the update intervals as part of their response.

3.2.2 Dangerous Queueing API

Dangerous queueing event data shall be provided through a real-time, web-based API in either JSON or XML format. Data shall be provided from the API meeting the specifications of Section I.3.1.2 Dangerous Queueing for all timestamps and available according to the requirements in Section I.6 Availability and Accuracy.

Real-time data shall be updated and provided at a maximum interval of 1 minute. The Proposer’s real-time API must be capable of supporting at least 15 requests per minute from ODOT.

The Proposer must specify the format of the Dangerous Queuing API response and describe the update intervals as part of their submission. The API feed must be fully developed, currently operational, and have a demonstrated history of delivering data to customers. The Proposer must also provide real-world sample data that reflects actual traffic conditions involving dangerous queuing scenarios. This data should illustrate the API’s ability to detect, report, and update queuing events with sufficient accuracy and timeliness to support operational decision-making.

Failure to provide specifications for an existing Dangerous Queueing API will result in the Proposer

3.2.3 Bottlenecks API

3.2.3.1 Historic Bottlenecks API

The selected Proposer shall make available a web-based API for historic bottlenecks data. Historical data shall be provided through a web-based API in JSON, XML, or CSV format; or a compressed data file containing any of the four previous data formats.

Historical bottlenecks data shall be provided from the API meeting the specifications of Section I.3.1.3 Bottleneck Data and accessible for time periods as recent as two days (48 hours) old, as a minimum.

Rev. 05/27/2025 12

The Proposer must specify the format of the Historic Bottlenecks API response and include real-world sample data as part of their submission. The API feed must be fully developed, currently operational, and have a demonstrated history of delivering data to customers. Proposals that include plans to build or launch the feed after award will not be considered. All sample data must reflect actual traffic conditions, and the Proposer must also describe the update intervals of their feed.

Failure to provide specifications for an existing Historic Bottlenecks API will result in the Proposer

3.2.3.2 Real-time Bottlenecks API

The Proposer may optionally make available a real-time bottlenecks API.

The Proposer should discuss availability of a real-time bottleneck API, including the format of the API response and update intervals as part of their response.

3.3 Data Querying/Download Tool Requirements

Historical speed data shall be available for download through a data querying tool with a web-based user interface. Data shall be provided from the data querying/download tool meeting the specifications of Section I.3.1.1 Speed Data for all timestamps and available according to the requirements in Section I.6 Availability and Accuracy.

Historical speed data shall be provided and accessible for time periods as recent as two days (48 hours) old, as a minimum. Historical speed data must be available in 5-minute, 15-minute, and 1-hour time granularity intervals.

The Proposer should discuss the availability, format, specifications, and update intervals of the data querying/download tool as part of their response.

3.4 Initial Data and Services Load Schedule

The Proposer shall not start billing for the data within this section at the contract price until after a final selection has been made and not before the start of the contract, October 1, 2025.

Failure to provide the specified data by the dates indicated in this section may result in ODOT finding an awarded Proposer in material breach of contract.

3.4.1 Speed Data Load Schedule

ODOT shall begin receiving real-time speed data by 12:01 AM ET on October 1, 2025.

ODOT shall begin receiving historical speed and travel time data from January 1, 2022 to the present, no later than October 1, 2025 via API and the querying/download tool. The Proposer shall also supply ODOT with historical speed and travel time data from January 1, 2018 to December 31, 2021 via the querying/download tool, no later than January 1, 2026.

3.4.2 Dangerous Queueing Load Schedule

ODOT shall begin receiving real-time dangerous queueing data by 12:01 AM ET on October 1, 2025.

Rev. 05/27/2025 13

3.4.3 Bottlenecks Load Schedule

ODOT shall begin receiving historical bottleneck data from October 1, 2025 forward no later than October 3, 2025 via API as per the required update intervals specified in Section I.3.2.3 Bottlenecks API.

Additionally, ODOT will require historical bottleneck data from January 1, 2025 through September 30, 2025. This data must be accessible via the API no later than April 1, 2026.

3.4.4 Map Tile Service Load Schedule

ODOT shall begin receiving the map tile service by 12:01 AM ET on October 1, 2025.

4. Required Analytics Tools and Services

4.1 Speed Data Analytics Tools

The Department requires speed data analytics tools to aid users in analyzing and visualizing trends via a web-based user interface without the need for complicated formulas or coding. All analytics tools proposed in this section must be accessible by all approved Ohio users.

Historical data shall be accessible within the analytics tools for time periods as recent as two days (48 hours) old, as a minimum.

The Proposer's response shall include, at a minimum, a listing of analytics tools provided, a description of the tool, and the granularity of data available. The Proposer may include as part of their response sample images/screenshots of the tool, analysis output, user interface, etc. The Proposer should discuss the update intervals for the analytics tools as part of their response. If the Proposer’s offer includes additional analytics tools beyond the minimum, they should be discussed as part of the response.

The following analytics tools are required at a minimum; however, if the Proposer’s offer includes additional analytics tools beyond the minimum, they should be discussed as part of the response.

4.1.1 Performance Report

Summarized performance metrics such as travel time, speed, buffer index, etc. over a specified period of time for a selected roadway.

The following performance report summary data elements must be provided at a minimum:

TABLE 9: REQUIRED PERFORMANCE REPORT SUMMARY DATA

Element

ID

Element Description

P1 ID Unique identifier of the summarized data request P2 Date/Time Date and Time of occurrence (specify time zone in response) P3 Speed Aggregated speed P4 Comparative Speed Measured speed as a percentage of the historical average speed for the corresponding time of day and day of week.

P5 Congestion Percent Measured speed as a percentage of the free flow speed.

Rev. 05/27/2025 14

P6 Travel Time Aggregated time to travel the selected roadway (Distance traveled/speed)

P7 Travel Time Index Travel time represented as a percentage of the ideal travel time (Travel Time / Free-flow Travel Time).

P8 Buffer Time The extra time (or time cushion) that travelers must add to their average travel time when planning trips to ensure on-time arrival (95% Travel Time - Average Travel Time).

P9 Buffer Time Index The Buffer Time's percentage value of the Average Travel Time ((95% Travel Time - Average Travel Time) / Average Travel Time).

P10 Planning Time The total time a traveler should plan for to ensure on-time arrival (95% Travel Time).

P11 Planning Time Index The total travel time that should be planned when an adequate buffer time is included (95% Travel Time / Free-flow Travel Time).

The Proposer's response shall include, at a minimum, the available time bins for summarizing data (e.g., 5 minutes, 15 minutes, 60 minutes, etc.), a listing of all performance report summary data fields, a description of the fields, data type for each field, an example value for each field, and the corresponding Element ID (e.g., P1, P2, etc.). If the Proposer has other fields beyond the minimum, they should be discussed as part of the response.

The Proposer shall use the response template in Appendix A - Speed Data Analytics Tools Templates as part of the above response.

4.1.2 User Delay Cost

Analysis of the impact of delay using speed, volume, and delay cost data. User Delay analysis should be available for passenger vehicles, commercial vehicles, and a combination of the two.

The following performance report summary data elements must be provided at a minimum:

TABLE 10: REQUIRED USER DELAY DATA

Element

ID

Element Description

U1 ID Unique identifier of the user delay query request U2 Date/Time Date and Time of occurrence (specify time zone in response) U3 Vehicle Type Type of vehicle: Passenger vehicle, commercial vehicle, or combination U4 Volume Volume of vehicles U5 Delay Vehicle Hours Calculated vehicle delay based on congestion U6 Delay Cost Cost of delay U7 Vehicle Miles Traveled Total amount of driving that occurred for the timespan

Rev. 05/27/2025 15

The Proposer's response shall include, at a minimum, discussion on the methodology for calculating user delay, including the available time bins for summarizing data (e.g., 5 minutes, 15 minutes, 60 minutes, etc.), a listing of all user delay data fields, a description of the fields, data type for each field, an example value for each field, and the corresponding Element ID (e.g., U1, U2, etc.). If the Proposer has other fields beyond the minimum, they should be discussed as part of the response.

The Proposer shall use the response template in Appendix A - Speed Data Analytics Tools Templates as part of the above response.

4.1.3 Performance Charts

Charts visualizing aggregated data (speed, travel time, congestion, etc.) for a selected roadway.

4.1.4 Space-Time Congestion Visualization

A graph representing visualizing speeds and/or congestion conditions over time and space along a roadway.

4.1.5 Bottleneck Visualization

Visualization of locations, frequency, and impact of top bottlenecks for a region or roadway.

4.1.6 Trend Map

An animated map visualizing historic roadway traffic conditions over time.

4.1.7 Real-Time Speed and Incidents Map

An interactive map displaying real-time conditions such as speeds, incidents, bottlenecks, etc.

4.2 Analytics Application Programming Interface (API) Requirements Failure to provide ALL required API feeds in this section will result in the Proposer being considered non-responsive. Non-responsive Proposers will be disqualified from further consideration, and their cost proposal will neither be opened nor considered.

4.2.1 Performance Report API

The selected Proposer shall make available a web-based API for historical performance report summary data. Historical data shall be provided through a web-based API in JSON, XML, CSV, or Excel format; or a compressed data file containing any of the four previous data formats.

Historical performance report summary data shall be provided from the API meeting the specifications of Section I.4.1.1 Performance Report and accessible for time periods as recent as two days (48 hours) old, as a minimum.

The Proposer should specify the format of their Performance Report API response and discuss the update intervals as part of their response.

Rev. 05/27/2025 16

4.2.2 User Delay Cost API

The selected Proposer shall make available a web-based API for historical user delay cost data. Historical data shall be provided through a web-based API in JSON, XML, CSV, or Excel format; or a compressed data file containing any of the four previous data formats.

Historical user delay cost data shall be provided from the API meeting the specifications of Section I.4.1.2 User Delay Cost and accessible for time periods as recent as two days (48 hours) old, as a minimum.

The Proposer should specify the format of their User Delay Cost API response and discuss the update intervals as part of their response.

4.3 Initial Analytics Tools Load Schedule

Failure to provide the specified data by the dates indicated in this section may result in ODOT finding an awarded Proposer in material breach of contract.

4.3.1 Speed Data Analytics Load Schedule

ODOT shall be able to utilize speed data analytics tools with historical data from January 1, 2022 to the present and query the corresponding APIs, no later than October 1, 2025. Additionally, ODOT shall be able to utilize speed data analytics tools with historical data from January 1, 2018 to December 31, 2021 and query the corresponding APIs, no later than January 1, 2026.

The Proposer shall not start billing for the analytics tools within Section I.4 Required Analytics Tools and Services at the contract price until after a final selection has been made and not before the start of the contract, October 1, 2026.

5. Optional Data, Services, and Tools

5.1 Traffic Signal Analytics Tools/Platform

To operate signalized intersections and corridors safely and efficiently, ODOT utilizes Traffic Signal Analytics Tools/Platform to monitor and analyze key metrics. The following are not required, but would provide value to the Department if available:

TABLE 11: KEY TRAFFIC SIGNAL METRICS

Metric Description Intersection Delay Intersection delay represents the additional travel time experienced by a vehicle due to the presence of a traffic signal. It quantifies the time lost while waiting in a queue or decelerating and accelerating due to the signal's operation.

Level of Service (LOS) Level of Service is a qualitative measure describing the operational conditions within a traffic stream and their perception by drivers. It ranges from LOS A (free flow) to LOS F (forced flow or breakdown).

Arrival on Green Arrival on Green is the percentage of vehicles arriving at an intersection during the green phase of the traffic signal for their movement.

Rev. 05/27/2025 17

Split Failures A split failure occurs when the green time allocated to a particular movement at an intersection is insufficient to clear the queue of vehicles that formed during the preceding red phase.

Queue Length Queue length refers to the number of vehicles stopped in a lane or lane group waiting to proceed through the intersection. It can be measured as the instantaneous queue length (at a specific point in time) or the average or maximum queue length over a period.

Travel Time Travel time is the total time taken by a vehicle to travel between two specific points, including any delays encountered. For signalized corridors, this includes the time spent moving and the time spent stopped at traffic signals. Calculations may include:

• Travel Time Index (TTI):

TTI is the ratio of the actual travel time to the ideal or free-flow travel time. A TTI of 1.0 indicates free-flow conditions, while a higher TTI indicates increased congestion.

• Planning Time Index (PTI):

The PTI represents the ratio of the 95th percentile travel time to the free-flow travel time. It indicates the extra time a traveler should budget to ensure on-time arrival for 95 out of 100 trips.

• Level of Travel Time Reliability (LOTTR):

LOTTR is a measure of the consistency of travel times on a roadway or corridor. It often uses percentile measures of travel time to quantify the variability experienced by travelers. A common metric is the ratio of the 80th percentile travel time to the 50th percentile travel time, or the percentage of trips that exceed a certain travel time threshold. Unlike TTI and PTI which are indices, LOTTR often describes a range or a probability.

As part of the response, the Proposer should discuss all metrics available as part of their traffic signal analytics offering, including any metrics beyond those listed in Table 11. Additionally, the response should highlight key functionality for the traffic signal analytics tools/platform (e.g., Notification alert methods, performance dashboards, etc.).

The proposer should also discuss the pricing structure of the traffic signal analytics tools/platform (e.g., cost per signal, monthly cost for all ODOT signals, etc.) as part of the response. ODOT does not guarantee that the Proposed traffic signal analytics tools/platform will be selected for implementation. If the pricing structure is based on a per signal basis, ODOT, in its sole discretion, may choose to include as many or as few signals as will benefit the Department. Additional signal locations may be added after the initial set-

up. While not a frequent occurrence, if ODOT finds that a signal location(s) no longer provides value via monitoring, the signal(s) may be substituted for a new location.

Rev. 05/27/2025 18

If the Traffic Signal Analytics Tools/Platform proposed as part of this section is deemed beneficial to ODOT, it may receive additional scoring considerations. The Traffic Signal Analytics Tools/Platform will NOT be considered as part of the cost scoring criteria.

5.2 Additional Data, Services, and Tools

If the Proposer offers additional data, services, and/or tools that may improve ODOT’s response to congestion and incidents and enrich analyses of data and performance measures, they may be included in appendices and listed on the pricing sheet as individual line items.

Additional data, services, and/or tools proposed as part of this section will NOT be considered as part of the technical or cost scoring criteria.

After the successful proposer is chosen based on the RFP Scoring procedure outlined below in Section V, the additional data, services, and/or tools will be reviewed. ODOT, in its sole discretion, may choose to include one or more of the additional data, services, and/or tools provided by the successful proposer.

ODOT does not guarantee that any additional data, services, and/or tools will be selected for implementation.

5.3 Initial Load Schedule for Optional Data, Services, and Tools

5.3.1 Traffic Signal Analytics Tools/Platform Load Schedule

Historical signal data shall be available from January 1, 2024 to the present. Initial set-up of the selected traffic signal locations and historical data for those locations shall be available in the analytics tools/platform no later than Jan 1, 2026.

The Proposer shall not start billing for the traffic signal analytics tools within this section at the contract price until after a final selection has been made, all initial set-up of signal locations is completed within the analytics tools/platform, and not before the start of the contract, October 1, 2026.

5.3.2 Additional Data, Services, and Tools Load Schedule

If the proposer offers additional data, services, or tools that ODOT decides to procure, the initial data load schedule will be determined based on multiple factors such as: procurement date, amount of data/services procured, etc.

6. Availability and Accuracy ODOT may apply a pricing deduction in accordance with Section II.4 Deductions and/or find the Proposer in breach of contract if data availability and accuracy requirements outlined in this section are not met.

6.1 Data Availability

6.1.1 Real-Time Availability

The real-time data feeds should be continuously available 24 hours per day, seven days a week. Uptime is crucial to providing Ohio Travelers with the highest level of responsiveness. The data feeds must be available for a minimum of 99% of the time in each monthly billing cycle. Availability will be calculated as total monthly available hours, rounded to the nearest quarter hour, divided by the total number of hours in the month. The data feeds will be considered unavailable when:

Rev. 05/27/2025 19

• ODOT does not receive data for at least 97% of segments on the State Highway System when retrieving data;

• the data fails to meet ODOT’s accuracy requirements as specified in Section I.6.2 Data Accuracy;

• the data fails to meet ODOT’s quality requirements as specified in Section I.6.3 Data Quality; or,

• the API cannot be contacted to retrieve data; or,

• the data returned by the APIs is more than 5 minutes past the collection time of the data.

The Proposer must provide details regarding average uptime for the past 6 months for their proposed real-time APIs as part of their response. For the purposes of this response only, "uptime" is defined as the total monthly hours, rounded to the nearest quarter hour, during which all components of the system are operational and all functions of the system are available to its users, divided by the total number of hours in the month.

6.1.2 Map Tile Services Availability

The map tile service should be continuously available 24 hours per day, seven days a week. Uptime is crucial to providing Ohio Travelers with the highest level of responsiveness. The service must be available for a minimum of 99% of the time in each monthly billing cycle. Availability will be calculated as total monthly available hours, rounded to the nearest quarter hour, divided by the total number of hours in the month.

The Proposer must provide details regarding average uptime for the past 6 months for their proposed map tile service as part of their response. For the purposes of this response only, "uptime" is defined as the total monthly hours, rounded to the nearest quarter hour, during which all components of the system are operational and all functions of the system are available to its users, divided by the total number of hours in the month.

6.1.3 Historical API Availability

The historical data feeds should be available 24 hours per day, seven days a week via the APIs. The data feeds must be available for a minimum of 90% of the time in each monthly billing cycle. Availability will be calculated as total monthly available hours, rounded to the nearest quarter hour, divided by the total number of hours in the month. The data feeds will be considered unavailable when:

• ODOT does not receive data for at least 97% of segments on the State Highway System when retrieving data;

• the data fails to meet ODOT’s accuracy requirements as specified in Section I.6.2 Data Accuracy;

• the data fails to meet ODOT’s quality requirements as specified in Section I.6.3 Data Quality; or,

• the APIs cannot be contacted to retrieve data.

Erroneous and/or missing historical data must be backfilled within three (3) business days of notice. Note:

Backfilled data may not be credited toward the availability percent, and pricing deductions may be applied.

The Proposer must provide details regarding average uptime for the past 6 months for their proposed historical API as part of their response. For the purposes of this response only, "uptime" is defined as the total monthly hours, rounded to the nearest quarter hour, during which all components of the system are operational and all functions of the system are available to its users, divided by the total number of hours in the month.

Rev. 05/27/2025 20

6.1.4 Querying and Analytics Tools Availability

Historical data must be available for download and analysis between the hours of 5 AM and 10 PM ET via the querying and analytics tools. Erroneous and/or missing historical data must be backfilled within three

(3) business days of notice to avoid a pricing deduction. If the data is not backfilled within the specified time, a pricing deduction will be applied for the length of time of the outage.

The Proposer must provide details regarding average uptime for the past 6 months for their proposed querying and analytics tools as part of their response. For the purposes of this response only, "uptime" is defined as the total monthly hours, rounded to the nearest quarter hour, during which all components of the system are operational and all functions of the system are available to its users, divided by the total number of hours in the month.

6.1.5 Scheduled Maintenance

ODOT must be given at least 48 hours advanced notice of scheduled downtime. Scheduled downtime should only occur between the hours of 10 PM and 5 AM ET. Scheduled downtime will be factored into total downtime for the monthly billing cycle.

The Proposer must provide details regarding regularly scheduled maintenance and system upgrades that may impact overall system uptime as part of their response.

6.2 Data Accuracy

ODOT will routinely monitor the accuracy of data. If determined that speed data is clearly inaccurate (for example: based on video footage from existing ODOT ITS cameras for any period of time) ODOT may determine the data to be unavailable for the period of time in which the data is inaccurate, and it shall be subject to requirements for data availability in Section I.6.1 Data Availability.

6.2.1 Periodic Data Accuracy Inspection

ODOT, in its sole discretion, may perform unannounced data accuracy inspections. The speed reported by the Proposer’s solution must be within 6 mph of an ODOT determined speed within 4 minutes of the time that ODOT’s speed was determined, based upon 75% of ODOT-collected samples during the quality inspection. Methods for data accuracy verification may include, but are not limited to:

• Floating car method;

• Traffic devices (e.g. cameras, radar sensors, traffic count stations, etc.); and/or,

• GPS tracking.

6.2.2 Data Sample

As part of the Proposal response, ODOT will assess the accuracy of the Proposer’s data solution by requesting sample speed data, in 1-minute granularity, for the following date/time ranges and locations:

Rev. 05/27/2025 21

TABLE 12: SAMPLE SPEED DATA REQUESTED

Start Date/ Time (ET)

End Date/ Time (ET)

ODOT

ID

Latitude Longitude Description

04/29/2025

07:00

04/29/2025

09:30

275-1 39.24905 -84.30651 I-275 WB at MM 52.0, Hopewell Rd.

275-2 39.252681 -84.321025 I-275 WB at MM 51.2, Weil Rd.

275-3 39.26177 -84.338012 I-275 WB at MM 50.1, Montgomery Rd.

275-4 39.281283 -84.36547 I-275 WB at MM 48.1, Kemper Rd.

275-5 39.286297 -84.371193 I-275 WB at MM 47.7, Reed Hartman Hwy

04/14/2025

15:30 04/14/2025 18:30

670-1 39.978986 -82.97089 I-670 EB at MM 5.6, West of Joyce Ave.

670-2 39.9803 -82.962496 I-670 EB at MM 6.0, West of Leonard Ave.

670-3 39.980591 -82.953241 I-670 EB at MM 6.5, East of Leonard Ave.

670-4 39.980871 -82.945731 I-670 EB at MM 7.0, West of Nelson Rd./

US-62

670-5 39.992447 -82.935507 I-670 EB at MM 8.1, East of 5th Ave.

670-6

40.001471 -82.923274 I-670 EB at MM 8.9, Airport Dr./ International Gtwy

670-7 40.005824 -82.915536 I-670 EB at MM 9.4, West of Stelzer Rd.

Rev. 05/27/2025 22

FIGURE 1: I-275 SMARTLANE SAMPLE LOCATIONS

Rev. 05/27/2025 23

FIGURE 2: I-670 SMARTLANE SAMPLE LOCATIONS

Note that the locations given in Table 12 represent points. The Proposer should provide data for the segment that best encompasses that point. In the event that the requested location falls on the border of two segments (i.e., within 250 ft of the border) or overlaps due to an on/off ramp lane, the Proposer may include both…