521-22.pdf

Invitation No.: 521-22 Location: Statewide Commodity: Real-time Traffic Speed Data Collection Pricing: http://www.dot.state.oh.us/Divisions/ContractAdmin/Contracts/PurchDocs/521pricing.xls

REQUEST FOR PROPOSAL (RFP)

State of Ohio, Department of Transportation

Office of Contract Sales, Purchasing Services Jack Marchbanks, Ph. D., Director

Response Submission Deadline (Bid Opening Date):

August 17, 2021 at 2:00 p.m. eastern time

Submitted by:

Company Name:

Federal Tax ID No.:

Physical/Mailing Address: Remit to Payment Address:

Street Address:

P.O. Box:

City:

St:

Zip:

Contact Person and Phone Number:

(authorized to answer questions about your company’s bid)

E-Mail Address (required):

(person who f illed out bid)

E-Mail Address (required):

(for notif ication of future bid opportunities)

Telephone Number 800 Number Fax Number

Return Properly Marked, Complete Responses To:

contracts.purchasing@dot.ohio.gov - Paper bids will NOT be accepted.

VENDORS MUST SUBMIT ANY QUESTIONS, CLARIFICATIONS, OR INQUIRIES REGARDING THIS

PROCUREMENT VIA THE FOLLOWING WEBSITE:

https://www.dot.state.oh.us/Divisions/ContractAdmin/Contracts/Pages/PurchasePBQ1.aspx mailto:contracts.purchasing@dot.ohio.gov

Attachments to be submitted in the emailed bid response:

Completed Front Page (Separate Attachment)

Completed Signature Page (Separate Attachment)

Completed Excel Pricing Page (Separate Attachment)

Anything Else You wish to Submit (Separate Attachments)

Send multiple emails, as needed, to complete your submission to contracts.purchasing@dot.ohio.gov - Paper bids will NOT be accepted.

Zip files CANNOT be sent.

RFP No. 521-22

Ohio Department of Transportation Request for Proposal No. 521-22

Speed Data Services

Requirements/Specifications

1. Proposal Purpose The Ohio Department of Transportation (ODOT) Office of Traffic Management is seeking the services of a qualified Proposer to provide the following two (2) distinct Speed Data Services:

1. Real-Time speed data coverage in Ohio, and

2. Historical speed data and analytics.

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

• Real-Time o Speed and Travel Time information

ODOT’s Advanced Traffic Management System (ATMS), OHGO inSIGHT, ODOT’s Traveler Information System (TIS), OHGO (mobile application and website), Dynamic Message Signs (DMS), etc.

o Dangerous Queueing o Map Tile Service

• Historical Data and Analytics o Key Performance metrics

Snow & Ice recovery Traffic Operations Assessment Systems Tool (TOAST) Travel Time Performance o Performance Dashboards (OhioTSMO.com) o Analytics Tools

Before and After Studies Project Prioritization Traffic Incident Management

• After Action Reviews

• Time to return to normal

Arterial Management

• Signal retiming analysis

• Travel time performance

Work Zone Management System-wide traffic impact prediction for roadway closures and detours

Access to the data, API, and analytics tool(s) shall be granted to all employees of ODOT, Local Governments, Metropolitan Planning Organizations (MPO’s), Transit Agencies, the Ohio Turnpike and Infrastructure Commission, Universities, and Other State of Ohio Agencies, etc. While account access will not generally be given to private entities, ODOT or an approved Ohio public 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) or a similar private entity working on their projects solely for use in that project. At the conclusion of the project work that requires the data, access to the analytics and querying tools will be withdrawn from the private entity. ODOT may distribute the Proposer data to third-party vendors https://www.transportation.ohio.gov/wps/portal/gov/odot/about-us/odot-strategic-plan/csf/snow-and-ice-csf https://www.transportation.ohio.gov/wps/portal/gov/odot/working/data-tools/resources/toast https://www.transportation.ohio.gov/wps/portal/gov/odot/about-us/odot-strategic-plan/csf/congestion-csf https://ohiotsmo.com/ responsible for maintaining ODOT systems, such as ATMS, GPS/AVL, OHGO, IMRCP, etc. The third-party vendor shall be prohibited from using or distributing the data for any other (non-ODOT system) purpose.

The Proposer may sell or otherwise provide the speed data provided through this agreement to any other public or private entity.

2. Data The awarded Proposer shall adhere to Supplement S, regarding data protection and privacy.

2.1 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. 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.

2.2 Coverage

Data shall be provided for, at a minimum:

• 100% of Interstate routes;

• 98% of non-Interstate National Highway Systema (NHS) routes; and,

• 85% of all remaining State Highway Systemb (SHS) routes.c

The required coverage percentages will be calculated as follows:

The Department will overlay in geospatial software (e.g., ArcMap) 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. If the Proposer-provided segmentation overlaps the respective category above without any visible gaps (at a scale of 1:3,000,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) a View the National Highway System on TIMS map:

https://gis.dot.state.oh.us/tims/map?center=- 81.91299167618523,40.25864202316735&level=8&visiblelayers=Roadway%20Information:11%7CProjects:- 1%7CEnvironmental:-1%7CBoundaries:-1%7CAssets:-1 Note: The Intermodal Connector routes are not required as part of the National Highway System requirement.

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

https://gis.dot.state.oh.us/tims/map?center=- 81.6644260023572,40.38114764473271&level=8&visiblelayers=Roadway%20Information:12%7CProjects:- 1%7CEnvironmental:-1%7CBoundaries:-1%7CAssets:-1 Note: All categories (P, U, and G) are considered part of the State Highway System.

c Shapefiles of the specified route systems may be downloaded via TIMS: https://gis.dot.state.oh.us/tims/Data/Download https://gis.dot.state.oh.us/tims/map?center=-81.91299167618523,40.25864202316735&level=8&visiblelayers=Roadway%20Information:11%7CProjects:-1%7CEnvironmental:-1%7CBoundaries:-1%7CAssets:-1 https://gis.dot.state.oh.us/tims/map?center=-81.91299167618523,40.25864202316735&level=8&visiblelayers=Roadway%20Information:11%7CProjects:-1%7CEnvironmental:-1%7CBoundaries:-1%7CAssets:-1 https://gis.dot.state.oh.us/tims/map?center=-81.91299167618523,40.25864202316735&level=8&visiblelayers=Roadway%20Information:11%7CProjects:-1%7CEnvironmental:-1%7CBoundaries:-1%7CAssets:-1 https://gis.dot.state.oh.us/tims/map?center=-81.6644260023572,40.38114764473271&level=8&visiblelayers=Roadway%20Information:12%7CProjects:-1%7CEnvironmental:-1%7CBoundaries:-1%7CAssets:-1 https://gis.dot.state.oh.us/tims/map?center=-81.6644260023572,40.38114764473271&level=8&visiblelayers=Roadway%20Information:12%7CProjects:-1%7CEnvironmental:-1%7CBoundaries:-1%7CAssets:-1 https://gis.dot.state.oh.us/tims/map?center=-81.6644260023572,40.38114764473271&level=8&visiblelayers=Roadway%20Information:12%7CProjects:-1%7CEnvironmental:-1%7CBoundaries:-1%7CAssets:-1 https://gis.dot.state.oh.us/tims/Data/Download with a tolerance of 35 meters. The coverage percent will be calculated as the total sum of covered centerline milesd divided by the total centerline miles for each categorye.

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 information, data will also be provided for any Interstate, US, and State Routes for adjacent states one county deep. Data shall be provided in each direction for all routes. Each data segment shall provide an average speed representing an average across all directional lanes. Data should be provided by the vendor in the most granular/high resolution, non-TMC, segmentation available that also meets the other requirements specified in this RFP.

Proposer shall provide a shapefile of their available data segments via a ShareFile link that will be provided by the Department after initial bids are submitted. See ShareFile Process section below for more details. The coverage requirement will be scored based on the following ranges of coverage percent:

TABLE 1: COVERAGE PERCENT RANGES FOR SCORING

DNM Partial Meets Exceeds Interstate Non-Responsive 100% n/a Non-Interstate NHS Non-Responsive 98-100% n/a All other SHS Non-Responsive 85-92.99% 93-100%

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

Proposers shall also discuss the granularity of their segmentation as part of this response.

2.3 Data and Services Required

2.3.1 Speed Data

The following data elements must be provided at a minimum:

TABLE 2: REQUIRED ELEMENTS

Metadata Element ID Element Description M1 Segment ID Unique segment identifier M2 Road Name(s) One or multiple common names for the roadway M3 Road Number Number associated with the roadway (i.e. Interstate or State

Route number) d 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.

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

• Interstate Routes: 1,334

• Non-Interstate NHS routes: 3,845

• All other SHS routes: 13,500

M4 Travel Direction Direction of traffic on the roadway M5 County County of Roadway segment M6 State State of Roadway segment M7 Segment Length Length in miles M8 Start

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

M9 End Latitude/longitude

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

Speed Data Element ID Element Description S1 Segment ID Unique segment identifier S2 Date/Time Date and Time of data point collection S3 Recorded Speed Average speed across all directional lanes for the stated time period S4 Historical Speed Normal expected speed based on, at a minimum, time of day, day of week, month, season, etc.

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 or GeoJSON file with the metadata and linear geometry for all data segments upon contract award and for any subsequent coverage updates throughout the life of contract.

Proposer's response shall include, at a minimum, a listing of all data fields, a description of the fields, 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 data API;

• historical data API; and,

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

Proposer shall use the response templates in Appendix A for the above response.

Failure to provide ALL required data elements (Table 2) for metadata and BOTH real-time and historical speed data will result in 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 2 are included. The following are not required, but would provide value to the Department if available:

TABLE 3: OPTIONAL ELEMENTS OF INTEREST

Metadata Element ID Element Description OM1 Number of Lanes Average number of lanes across the segment (in one direction)

OM2 Next/Previous Segment(s)

One or more fields indicating the order of segment(s) adjacent to the current

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

Speed Data Element ID Element Description OS1 Travel Time The time to travel across the length of the segment based on current speed OS2 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

OS3 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

OS4 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

OS5 Congestion Percent

Measured speed as a percentage of the free flow speed

OS6 Accuracy Value The assessed accuracy of the data point OS7 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.

2.3.2 Bottlenecks

The Department requires bottlenecks data on the entire State Highway System for the purposes of TOAST and its Performance Dashboards. Bottlenecks 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 selected Proposer shall make available a web-based API for historical bottlenecks data no later than April 1, 2022. 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. The following bottlenecks elements are required:

TABLE 4: REQUIRED HISTORICAL BOTTLENECKS ELEMENTS

Historical API Element ID Element Description B1 Start Date/Time First date and time that the bottleneck was identified B2 Duration Length of time bottleneck impacted the roadway B3 Start Latitude Latitude of the head of the bottleneck B4 Start Longitude Longitude of the head of the bottleneck B5 End Latitude Latitude of the tail of the bottleneck B6 End Longitude Longitude of the tail of the bottleneck B7 Max Length (mi) Maximum length of roadway impacted by bottleneck in miles

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

ODOT will require historical bottleneck data from January 1, 2021 forward. This data must be accessible via the API no later than April 1, 2022.

The Proposer shall include in their response whether a Historical Bottlenecks API currently exists that meets the specifications above. If a current API does not exist, the Proposer shall discuss their ability to make an API meeting the specifications above operational by April 1, 2022. If a current API exists, the Proposer shall specify the format of their API response, the fields available, a description of the fields, an example value for each field, and the corresponding element ID (e.g., B1). If the Proposer has other fields beyond the minimum, they should be discussed as part of the response. Additionally, the Proposer’s response shall discuss methodology for identifying bottlenecks, including the percent threshold used for identification.

Failure to provide a bottlenecks API that meets the requirements above by April 1, 2022 may result in ODOT finding an awarded Proposer in material breach of contract.

2.3.3 Dangerous Queueing

The Department requires dangerous queueing event data on the entire National Highway System for the purposes 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 speeds differ from the speed of the adjoining segment by a threshold, resulting in a potentially hazardous speed drop that may require hard braking.

Dangerous queueing event data shall be provided through a web-based API in either JSON or XML format.

As part of their response, the Proposer shall specify the format of their API response, the fields available, a description of the fields, and an example value for each field. Additionally, the Proposer’s response shall discuss methodology for identifying dangerous queueing events, including the threshold used for identification.

2.3.4 Map Tile Service

The Proposer shall make available by October 1, 2021 a tile service that returns images containing traffic graphics. The tile service shall allow for:

• the creation of graphics spanning the geographic boundaries of the state of Ohio, in their entirety, or any smaller portion thereof;

• 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 by October 1, 2021 may result in ODOT finding an awarded Proposer in material breach of contract.

2.4 Data Transfer and Update Rate

Real-time data shall be provided through a web-based API in either JSON or XML format. 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. Additionally, historical data shall be available for download through a data querying tool.

Real-time data shall be updated and provided at a maximum interval of 1 minute. Proposer’s real-time API must be capable of supporting at least 15 requests per minute from ODOT. 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 API response and discuss the update intervals for both real-time and historical data as part of their response.

2.5 Initial Data Load Schedule

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

ODOT shall begin receiving historical speed and travel time data from January 1, 2019 to the present, no later than October 1, 2021 and shall be able to query data using an analytics platform as explained in Section 2.2. The Proposer shall also supply ODOT with historical speed and travel time data from January 1, 2014 to December 31, 2019 and this data shall be provided and available in the system by January 1, 2022.

The Proposer shall not start billing for the data within these areas at the contract price until after a final selection has been made and not before October 31, 2021.

Failure to provide speed data by the dates indicated above for real-time, or historical data, may result in ODOT finding an awarded Proposer in material breach of contract.

2.6 Demonstration Period

A Demonstration Period will be performed by the conditionally selected Proposer, upon ODOT request.

The Demonstration Period will provide an opportunity to show the Proposer can successfully send data to ODOT via both a real-time and a historical API, the data meets all current ODOT system requirements for continued functionality, and the analytics tools proposed meet the needs of the Department.

The goals of the Demonstration Period shall be to evaluate technical capabilities of the Proposer’s data services to ensure all RFP requirements are met and to demonstrate how the speed data service solution meets ODOT’s business needs.

The timeline for the Demonstration Period may have a duration of up to several weeks. At the conclusion of the Demonstration Period, ODOT will conduct a final evaluation of the Proposer’s technical capabilities and proposed solution. Based upon the results of this evaluation, ODOT may opt to make the selection final. Alternatively, based upon the results of the evaluation, if in the sole opinion of the Department the Proposer’s solution does not fit the Department’s needs and/or the Proposer’s solution does not conform to the requirements of this RFP or their provided responses, ODOT may opt to continue the selection process with the next best scoring Proposer. After the completion of the Demonstration Period, any data collected from the Proposer as well as any documentation completed by the Proposer during the Demonstration Period, shall be retained by

ODOT.

3. Analytics Tools

3.1 Required Tools

The following analytics tools, at a minimum, must be accessible by all approved Ohio users:

TABLE 5: REQUIRED ANALYTICS TOOLS

ID Tool Type Description T1 Real-time speed and incidents map Map displaying speed, incidents, bottlenecks, etc. for real-time data

T2 Congestion Visualization Visualizes congestion conditions overtime along a roadway T3 Trend Maps Animated map visualizing traffic conditions over time T4 Performance Charts Charts visualizing summary data and performance metrics T5 Performance Report Report summarizing performance metrics such as travel time, speed, buffer index, etc.

T6 Bottlenecks Information Determine top bottlenecks for a region or roadway T7 User Delay Cost Analysis Analyzes the impact of delay using speed and volume data and assigns a cost T8 Travel Time Distribution Visualizes traffic conditions along a corridor and helps to analyze travel time reliability T9 Travel Time Change

Performance Compares the change in performance of a corridor from one time period to another

Proposer's response shall include, at a minimum, a listing of analytics tools provided, a description of the tool, and the corresponding ID (e.g., T1). The Proposer may include as part of their response sample images/screenshots of the tool, analysis output, user interface, etc.

If the Proposer’s offer includes additional analytics tools beyond the minimum, they should be discussed as part of the response.

3.2 Data Update Rate

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

The Proposer should discuss the update intervals for the analytics tools as part of their response.

4. Availability and Accuracy ODOT may apply a pricing deduction (see Contract Pricing, Invoicing, and Deductions Section 3 for more details) and/or find the Proposer in breach of contract if data availability and accuracy requirements outlined in this section are not met.

4.1 Data Availability

4.1.1 Real-Time Availability

The real-time data feed 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 feed 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 feed 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 4.2; or,

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

• the data returned by the API 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 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.

4.1.2 Historical API Availability

The historical data feed should be available 24 hours per day, seven days a week via the API. The data feed 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 feed 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 4.2; or,

• the API 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.

4.1.3 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.

4.1.4 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.

4.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 the section above.

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:

TABLE 6: SAMPLE SPEED DATA REQUESTED

Req.

ID

Start Date/Time

(ET)

End Date/Time

(ET)

Latitude Longitude Description

1-1 06/07/2021 15:00 06/07/2021 15:30 39.980871 -82.9457 I-670EB @ W of Nelson Rd.

1-2 06/07/2021 15:00 06/07/2021 15:30 39.992447 -82.9355 I-670EB @ E of 5th Ave.

1-3 06/07/2021 15:00 06/07/2021 15:30 40.001471 -82.9233 I-670EB @ Airport Dr.

1-4 06/07/2021 15:00 06/07/2021 15:30 40.005824 -82.9155 I-670EB @ W of Stelzer Rd.

2-1 06/10/2021 07:30 06/10/2021 08:30 39.978554 -82.9793 I-670EB @ E of I-71 2-2 06/10/2021 07:30 06/10/2021 08:30 39.978986 -82.9709 I-670EB @ W of Joyce Ave.

Note that the locations given in Table 6 represent points. 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, Proposer may include both segments, provided they indicate this with their response. If two or more of ODOT’s requested locations fall within a single Proposer segment, this should be indicated in the response as well.

At a minimum, Proposer’s sample data shall include the following information:

• Metadata o Request # o Segment ID o Start Latitude/Longitude o End Latitude/Longitude o Segment Length

• Speed Data o Request # o Segment ID o Date/Time o Speed

Proposer shall submit their sample data in a csv file format (i.e., .csv) via a ShareFile link that will be provided by the Department after initial bids are submitted. See ShareFile Process section below for more details. Files submitted in any other format, including Excel, (e.g., .xlsx, .xls, .xlsm, .zip, etc.) will not be reviewed nor opened and may result in a scoring of “Does Not Meet” for this technical proposal criteria.

For the purpose of scoring the data accuracy of the Proposer’s solution for this RFP, ODOT will assess the Proposer’s sample data as it compares to static speed sensor devices located along one (or more) of Ohio’s freeways. The following method will be used in the data comparison:

ODOT will calculate its sensor speed by using the weighted average (by number of samples) of speed data recorded for each available lane at a given time for a given location. ODOT may adjust the sensor data to convert between units (e.g., kilometers per hour to miles per hour).

ODOT’s weighted average will be compared to the data sample provided by the Proposer for the same time and location; if the proposer submits more than one segment because the indicated sample location sits within 250 ft of the intersection of two segments, the Proposer's speed will be calculated as the average between the two segments. In the event that two or more of ODOT’s point locations fall within one Proposer segment, the ODOT weighted average will be calculated using all lanes for all corresponding points at the given time. ODOT will calculate the absolute value of the speed difference (hereafter absolute speed difference) between the Proposer's speed and ODOT's calculated speed at each time stamp for each location. The average absolute speed difference will be determined using the arithmetic mean across all data points rounded to one decimal place for the purpose of scoring this section.

The average data accuracy will be scored based on the following speed difference (+/-) ranges in miles per hour (mph):

TABLE 7: SPEED DIFFERENCE RANGES FOR SCORING

DNM Partial Meets Exceeds Average Speed Difference (mph) 9.1+ 9.0-6.1 6.0-3.1 ≤ 3.0

4.3 Data Quality Inspection

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. ODOT, in its sole discretion, may perform annual, unannounced data quality inspections. Methods for data quality 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.

5. Support

5.1 Technical Support

For real-time speed data, the Proposer shall provide, as a minimum, technical support via a monitored email/inbox account or phone number to verify/acknowledge issues within the appropriate timeframe from the chart below and begin resolution of the issue.

TABLE 8: TECHNICAL SUPPORT RESPONSE TIME REQUIREMENTS

Days Hours Response Time Weekdays (M-F) 5 AM – 9 PM ET (Peak) 30 minutes

Weekdays (M-F) 9 PM – 5 AM ET (Off Peak) 2 hours* Weekends (Sa-Su) All 2 hours* *Note: If the issue occurs within two (2) hours before the start of a Weekday Peak Period (5 AM ET M- F), the response time should occur no later than 5:30 AM ET.

Automated detection & alert generation of real-time speed issues are not required but would be a beneficial offering beyond the minimum requirements. The Proposer shall describe how technical support will be provided as part of this contract.

For historical speed data, the Proposer shall provide technical support to all Ohio account holders that ODOT approves to use and query the data set and analytics proposed in this RFP. The Proposer shall describe how technical support will be provided as part of this contract. As a minimum, Technical Support shall be available to any licensed user via web page/email.

The Proposer shall provide information with their RFP response describing their offered technical support. Any additional technical support offered beyond the minimum should be noted.

5.2 Ongoing Support

Proposer shall provide, at a minimum, a single point of contact available to address business use-cases, contract management aspects, and other high priority issues filtered through ODOT Office of Traffic Management. This person must be available for recurring monthly status meetings with Office of Traffic Management technical staff to discuss upcoming data/product updates, current issues or concerns, and business use-cases. The meetings should typically last no more than 30 minutes and may be rescheduled by agreement if needs arise.

User analytics reporting must be provided to the Department twice annually upon request. The analytics reports may include information such as total number of API calls, list of users calling the APIs, total number of subscribers to analytics platform, top users, percent use by tool, etc.

The Proposer shall provide information with their RFP response describing their offered ongoing support and user analytics reporting available.

6. Training The Proposer shall provide as a minimum the following training for historical speed data:

1. Once a year, in person, one day (4-6 hours as necessary) training class and/or workshop on the data set including how to create queries, interpret analyses, and showcase specific Ohio use cases. Dates and location of the training classes/workshops will be by mutual agreement.

2. Webinars and/or online training videos that can be viewed internally and external to ODOT. It is anticipated that these webinars/videos will be the primary means of providing training to other Ohio public agencies.

The Proposer shall provide information with their RFP response describing their offered training. Any additional training opportunities offered beyond the minimum training described above should be noted.

7. Qualifications and Experience

7.1 Qualifications

The Proposer shall include a description of their qualifications, experience and any other reasons why they believe they are the most qualified to provide the data services described in this RFP. The response should include key staff, including brief resumes, identified by name and position. If partner vendors are used to meet one or more of the requirements in the response, their key staff and qualifications should also be included in this section. Response shall be limited to two pages.

7.2 Experience with Transportation Use Cases

It is ODOT’s desire to purchase a data set that has been successfully used for transportation related use cases as described in Section 1 Proposal Purpose. The Proposer’s data set shall have been used in a minimum of three (3) completed transportation-based use case projects that were sponsored by a public agency. At least one use case will demonstrate the Proposer’s real-time data set was used successfully for Traffic Management purposes. The proposal shall summarize these three projects. With each cited project include a brief project description highlighting the use case along with public agency references.

Additional completed projects beyond the three minimum required may also be provided in this section.

Contract Pricing, Invoicing, and Deductions

1. Pricing Pricing for real-time data shall be per the contract bid price per month. The price for real-time data must include all overhead, devices, labor, equipment, materials and any incidentals necessary to establish pricing to meet or exceed the bid requirements.

Pricing for historical data and access to analytics tools shall be per the contract bid price per month.

The price provided by the Proposer shall be all inclusive including technical support, training and shall include all updates to the data set, API, and/or the query and analytics tools.

2. Invoicing Invoicing for real-time and/or historical data must be monthly and must be submitted at or after the end of the month.

3. Deductions

3.1 Availability Deduction

If the data does not meet the availability requirements set forth in Section 4.1 above, a deduction to the monthly billing will be made by taking the percent of time the data feed was unavailable from the monthly price. Deductions for real-time data and historical data may be applied separately as applicable.

3.2 Data Quality Inspection Deduction

If the data fails a quality inspection set forth in Section 4.3 above, the Department will notify the Proposer. From the time of notification, the Proposer will have ten days to remedy the data quality to the satisfaction of the Department. If the data quality is not improved to the satisfaction of the Department, a 20% deduction will be applied to the applicable portion(s) of payment (i.e., real-time and/or historical), beginning in the month of notification from the day of notice forward. Until the Proposer has improved the data quality to the satisfaction of ODOT, the rate of deduction will increase by 5% each month, not to exceed 100%, after the month of notification. If Proposer repeatedly fails data quality inspections, the Department, at its sole discretion, may find the Proposer in breach of contract.

Contract Duration Contract shall expire September 30, 2023. Both parties may mutually agree to extend the contract two times for one year each (i.e., maximum of four years if both parties agree to execute both one-year extensions).

Additional Offerings ODOT has interest in additional traffic related data and performance products that may improve the Department’s response to congestion and incidents and enrich analyses of data and performance measures. Types of products include, but are not limited to:

• Signal Performance Measures

• Traffic Incident Management (TIM) Performance Measures and Timeline

• Emergency Alerts

• Vehicle trip/flow data

• Connected car sensor data

• Weather data

• Routing API

The Proposer may include an appendix with additional offerings above and beyond the scope of the Speed Data proposal. Additionally, the pricing sheet incudes a section for monthly costs associated with each additional offering.

Additional offerings 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, the additional offerings will be reviewed. ODOT, in its sole discretion, may choose to include one or more of the additional offerings provided by the successful proposer. ODOT does not guarantee that any additional offerings will be selected for implementation.

ShareFiles Process Proposer shall submit their complete proposal package on the due date specified below except for the requested shapefile and sample data files from Sections 2.2 and 4.2 respectively. After the submittal deadline, once ODOT’s Office of Contracts verifies Proposer’s successful submittal, a separate ShareFile link will be created for each Proposer. The Proposer’s unique ShareFile link will be emailed to the point of contact, inviting them to upload the requested shapefile and sample data files. The Proposer shall complete the file uploads by the due date specified below. Failure to provide the file uploads by the due date may result in the respective sections not being scored as part of the technical proposal score.

Should the Proposer have technical difficulties with the ShareFile link, the Proposer should reach out to the Office of Contract’s employee as soon as possible to remedy the issue.

RFP Scoring

1. Scoring of Technical Proposal Technical Proposals will be collectively scored by a Proposal Review Team (PRT) appointed by ODOT. For each of the evaluation criteria given in the score sheet, reviewers will collectively judge whether the technical proposal does not meet, partially meets, meets or exceeds each criterion, and assign the appropriate point value. The scoring definitions are as follows:

TABLE 10: SCORING EVALUATION DEFINITIONS

Evaluation Definition Value Does Not Meet (DNM) A particular requirement was not addressed in the response 0 Partially Meets Response demonstrates some attempt at meeting the requirements, but that attempt falls below acceptable level

Meets Response fulfills the requirements in all material respects, potentially with only minor, non-substantial deviation

Exceeds Response fulfills the requirements in all material respects, and offers, at the sole discretion of the Department, some additional level of quality in excess of expectations

The scoring is by consensus and one official score sheet will be completed for each technical proposal that is scored.

A proposal’s total technical score will be the sum of the point values for all the evaluation criteria.

Technical proposals must demonstrate that the selected Proposer has the capability to successfully perform the services required. Proposers who do not meet or exceed the following criteria will be disqualified from further consideration, and their cost proposal will neither be opened nor considered:

• Section 2.2 Coverage

• Section 2.3.1 Speed Data

• Minimum Required Technical Score (Table 11)

TABLE 11: MIN/MAX POTENTIAL TECHNICAL SCORES

Minimum Required Technical Score 525 Maximum Possible Technical Score 1100

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

TABLE 12: TECHNICAL PROPOSAL SCORE SHEET

2. Scoring of Cost Proposal The cost proposal will be reviewed by the PRT. The total of the monthly cost proposal will be divided by the Proposer’s final technical proposal score. This compares the cost with the quality of the technical proposal, which will provide an average cost-per-quality point earned on the technical proposal.

ODOT may, at its sole discretion, negotiate with all technically qualifying vendors for a revised cost proposal. Vendors may then:

1. submit one last and best offer;

2. request that ODOT view its original cost proposal as its last and best offer; or,

3. may formally withdraw from further consideration.

The vendor shall formally indicate its choice according to directions provided by ODOT at that time.

Upon receipt of all last and best offers, ODOT will then consider those vendors’ revised cost proposals.

TABLE 13: PRICING SHEET

Speed Data Monthly Cost

Real-Time Real-Time Data (including API)

Historical Historical Data (including API) Querying and Analytics Tools

Total Historical Monthly Total

3. Final Score Cost per Quality Point = (Proposer’s Total Submitted Monthly Cost/ Total Technical Score)

The Technical Proposal with the lowest cost per quality point will be conditionally selected, pending successful Demonstration Period. Based upon the results of the Demonstration Period, ODOT may opt to make the selection final, or may opt to continue the selection process with the Proposer with the next lowest cost per quality point.

Appendix A: Required Fields Templates Failure to provide ALL required elements for metadata and BOTH real-time and historical speed data will result in Proposer being considered non-responsive. Non-responsive Proposers will be disqualified from further consideration, and their cost proposal will neither be opened nor considered.

TABLE I: METADATA

Element

ID

ODOT Required Element

Proposer Field Name

Description Example Value

Required Fields M1 Segment ID M2 Road Name(s) M3 Road Number M4 Travel Direction M5 County M6 State M7 Segment Length M8 Start Lat/Long M8 End Lat/Long

Additional Fields

(Add additional lines as necessary)

TABLE II: REAL-TIME SPEED DATA

ID

ODOT Required Element

Proposer Field Name

Description Example Value

Required Fields S1 Segment ID S2 Date/Time S3 Recorded Speed S4 Historical Speed S5 Freeflow Speed S6 Confidence Value

TABLE III: HISTORICAL SPEED DATA

ID

ODOT Required Element

Proposer Field Name

Description Example Value

Required Fields S1 Segment ID

S2 Date/Time S3 Recorded Speed S4 Historical Speed S5 Freeflow Speed

TABLE IV: HISTORICAL DATA QUERYING TOOL

(IF VARIES FROM HISTORICAL TABLE I I I)

Element

ID

ODOT Required Element

Proposer Field Name

Description Example Value

Required Fields S1 Segment ID S2 Date/Time S3 Recorded Speed S4 Historical Speed S5 Freeflow Speed

State of Ohio, Department of Transportation (ODOT) Office of Contract Sales, Purchasing Services

Terms and Conditions for Submitting Excel Pricing File in Bid Package (Last Revised 07/2020)

1. DOWNLOADING THE EXCEL PRICING FILE: Bidders can access and download the most current Excel Pricing File for this procurement by following the hyperlink provided below:

http://www.dot.state.oh.us/Divisions/ContractAdmin/Contracts/PurchDocs/521pricing.xls

2. SUBMISSION OF EXCEL PRICING FILE: Bidders should submit the pricing page in the original excel format.

3. UNAPPROVED ALTERATIONS TO EXCEL PRICING FILE: Bidders who materially alter the original content of the Excel pricing file (e.g. specifications, formulas, etc.) issued by the Department may be found non-responsive and ineligible for award of this procurement.

4. CHANGES TO EXCEL PRICING FILE: The Department will only make modifications to the Excel pricing file by written addendum only. Where changes are necessary to the Excel pricing page, the Department will issue a new Excel pricing page indicating the revisions made and a revision date for the changes.

It is the sole responsibility of the bidder to check for issued addenda prior to submitting a bid package to ensure the most updated Excel pricing file is being utilized.

5. DESCRIPTIVE LITERATURE: Bidders may electronically provide any descriptive literature (e.g. brochures, spec/cut sheets, drawings, MSDS, etc.) regarding the products and/or services offered by the bidder. As this literature may be publicly posted for viewing by purchasers, bidders must not submit any literature electronically in which they consider to be a trade secret, proprietary, or confidential in any way.

http://www.dot.state.oh.us/Divisions/ContractAdmin/Contracts/PurchDocs/521pricing.xls

Office of Contract Sales, Purchasing Services

INSTRUCTIONS, TERMS AND CONDITIONS FOR BIDDING

(Last revised 11/30/2020)

1. BIDDER REGISTRATION: The Department requires awarded bidder(s) to successfully register as a State of Ohio Supplier with the Department of Ohio Shared Services and successfully obtain an OAKS vendor identification number (OAKS ID) within fourteen (14) calendar days from the date of contract award and execution. The Department cannot utilize awarded Contracts to purchase from a bidder who cannot obtain an OAKS ID from Ohio Shared Services. In the event an awarded bidder is unable to obtain an OAKS ID, the Department shall reserve the right to revoke its award to the bidder and immediately cancel any resulting Contract.

A Supplier Information Form and W-9 must be completed and sent back directly to Ohio Shared Services in order to register and apply for an OAKS ID. The following website can be accessed by bidders to obtain both the forms and specific instructions for obtaining an OAKS ID:

http://ohiosharedservices.ohio.gov/SupplierOperations/Forms.aspx

It is strongly recommended that all interested bidders not already registered with Ohio Shared Services submit the above paperwork prior to the bid submission deadline.

2. HOW BIDS MUST BE PACKAGED: All submitted bids in response to this procurement must be emailed to contracts.purchasing@dot.ohio.gov – Paper bids will NOT be accepted.

3. WHAT NEEDS INCLUDED IN BID PACKAGE: Submitted bid packages should include, at a minimum, a completed Signature Page, a completed Excel pricing page, and all necessary supportive documentation, forms, and any other information required herein. The Department may deem a bid non-responsive for failure to submit any of the documents requested above.

4. PREBID QUESTIONS, DISCREPANCIES, AND CLARIFICATIONS: Any discrepancies, omissions, ambiguities, or conflicts in or among the bidding documents or doubts as to the meaning shall be brought to the Department’s attention by the bidder no less than three (3) business days prior to the bid submission deadline. All questions, discrepancies, clarifications, etc. must be submitted electronically (hyperlink below).