During the 2014 ITS World Congress a demonstration of the connected vehicle infrastructure in the City of Detroit was conducted. The test site included approximately 14 intersections around Detroit’s COBO convention center and involved 9 equipped vehicles.Intersection Situation Data (ISD) data set communicates MAP and signal phase and timing (SPaT) information. MAP information communicates an intersection’s location (latitude and longitude), elevation, and geometric features such as approaches and lane configuration. SPaT data communicates the (current) state of the intersection’s signal indication(s). The data is composed of discrete Row Groups. A Row Group is a collection of (approximately 3-4) consecutive rows with common attribute. NOTE: All Extra Files are attached in 2014 ITS World Congress Connected Vehicle Test Bed Demonstration Vehicle Situation Data

During the 2014 ITS World Congress a demonstration of the connected vehicle infrastructure in the City of Detroit was conducted. The test site included approximately 14 intersections around Detroit’s COBO convention center and involved 9 equipped vehicles.Intersection Situation Data (ISD) data set communicates MAP and signal phase and timing (SPaT) information. MAP information communicates an intersection’s location (latitude and longitude), elevation, and geometric features such as approaches and lane configuration. SPaT data communicates the (current) state of the intersection’s signal indication(s). The data is composed of discrete Row Groups. A Row Group is a collection of (approximately 3-4) consecutive rows with common attribute. NOTE: All Extra Files are attached in 2014 ITS World Congress Connected Vehicle Test Bed Demonstration Vehicle Situation Data

During the 2014 ITS World Congress a demonstration of the connected vehicle infrastructure in the City of Detroit was conducted. The test site included approximately 14 intersections around Detroit’s COBO convention center and involved 9 equipped vehicles. Traveler Situation Data (TSD) was obtained from the data warehouse, and not the data clearinghouse. Only 19 messages were obtained from our query as the current mode of operation of the Test Bed is that the warehouse only contains a few static messages, which are meant to serve as a proxy for future operation in which query submissions will only return message(s) relevant to the context in which the query was submitted. The messages that returned per a query submission communicates a pertinent advisor message which is in part contextualized by location and content. NOTE: All Extra Files are attached in 2014 ITS World Congress Connected Vehicle Test Bed Demonstration Vehicle Situation Data

During the 2014 ITS World Congress a demonstration of the connected vehicle infrastructure in the City of Detroit was conducted. The test site included approximately 14 intersections around Detroit’s COBO convention center and involved 9 equipped vehicles. Traveler Situation Data (TSD) was obtained from the data warehouse, and not the data clearinghouse. Only 19 messages were obtained from our query as the current mode of operation of the Test Bed is that the warehouse only contains a few static messages, which are meant to serve as a proxy for future operation in which query submissions will only return message(s) relevant to the context in which the query was submitted. The messages that returned per a query submission communicates a pertinent advisor message which is in part contextualized by location and content. NOTE: All Extra Files are attached in 2014 ITS World Congress Connected Vehicle Test Bed Demonstration Vehicle Situation Data

During the 2014 ITS World Congress a demonstration of the connected vehicle infrastructure in the City of Detroit was conducted. The test site included approximately 14 intersections around Detroit’s COBO convention center and involved 9 equipped vehicles. The Vehicle Situation Data (VSD) data set includes a series of data files that recorded vehicle situational data that were generated by an equipped vehicle. During the ITS World Congress, VSDs were encoded with one of two schemas. The dataset contains decoded data using both 2.0 and 2.1 ASN.1 schemas.

During the 2014 ITS World Congress a demonstration of the connected vehicle infrastructure in the City of Detroit was conducted. The test site included approximately 14 intersections around Detroit’s COBO convention center and involved 9 equipped vehicles. The Vehicle Situation Data (VSD) data set includes a series of data files that recorded vehicle situational data that were generated by an equipped vehicle. During the ITS World Congress, VSDs were encoded with one of two schemas. The dataset contains decoded data using both 2.0 and 2.1 ASN.1 schemas.

The data in this data environment was collected from the Pasadena, California testbed, namely I-210, SR 134, and nearby arterials. The source of these data is from the Caltrans – Performance Measurement System (PeMS). Speed data from this dataset were used to derive the freeway travel time. There are three separate text files with one for each operational condition.

The data in this data environment was collected from the Pasadena, California testbed, namely I-210, SR 134, and nearby arterials. The source of these data is from the Caltrans – Performance Measurement System (PeMS). Speed data from this dataset were used to derive the freeway travel time. There are three separate text files with one for each operational condition.

The data in this data environment was collected from the Pasadena, California testbed, namely I-210, SR 134, and nearby arterials. The source of these data is from the National Center for Environmental Information – National Oceanic and Atmospheric Administration. Precipitation information from this data source is used in the cluster analysis.

The data in this data environment was collected from the Pasadena, California testbed, namely I-210, SR 134, and nearby arterials. The source of these data is from the National Center for Environmental Information – National Oceanic and Atmospheric Administration. Precipitation information from this data source is used in the cluster analysis.

Contains all Basic Mobility Control Message (BMCMs) generated during the Advanced Messaging Concept Development (AMCD) field testing program. While there is no specific standard in existence that addresses the content of a BMCM, the following format was derived to control the configuration and content of BMMs requested from the vehicle. All BMCMs are generated by the VCC Cloud server and transmitted to OBU clients through either a DSRC or cellular communications channel.

Contains all Basic Mobility Control Message (BMCMs) generated during the Advanced Messaging Concept Development (AMCD) field testing program. While there is no specific standard in existence that addresses the content of a BMCM, the following format was derived to control the configuration and content of BMMs requested from the vehicle. All BMCMs are generated by the VCC Cloud server and transmitted to OBU clients through either a DSRC or cellular communications channel.

Contains all Basic Mobility Control Message (BMCMs) generated during the Advanced Messaging Concept Development (AMCD) field testing program. While there is no specific standard in existence that addresses the content of a BMCM, the following format was derived to control the configuration and content of BMMs requested from the vehicle. All BMCMs are generated by the VCC Cloud server and transmitted to OBU clients through either a DSRC or cellular communications channel.

Contains all Basic Safety Messages (BSMs) collected during the Advanced Messaging Concept Development (AMCD) field testing program. For this project, all of the Part I BSM message fields were populated. Additional data fields were also added to the row to identify sender, time of communication, mode of communication, etc., allowing the consumer of this data set to accurately track messages through the system. All BSMs are generated by OBUs and ultimately received by the VCC Cloud server.

Contains all Basic Safety Messages (BSMs) collected during the Advanced Messaging Concept Development (AMCD) field testing program. For this project, all of the Part I BSM message fields were populated. Additional data fields were also added to the row to identify sender, time of communication, mode of communication, etc., allowing the consumer of this data set to accurately track messages through the system. All BSMs are generated by OBUs and ultimately received by the VCC Cloud server.

Contains all Basic Mobility Messages (BMMs) collected during the Advanced Messaging Concept Development (AMCD) field testing program. While there is no specific standard in existence that addresses the content of a BMM, the descriptive definitions of the variables were derived from the J2735 standard where applicable. All BMMs are generated by OBUs and ultimately received by the VCC Cloud server.

Contains all Basic Mobility Messages (BMMs) collected during the Advanced Messaging Concept Development (AMCD) field testing program. While there is no specific standard in existence that addresses the content of a BMM, the descriptive definitions of the variables were derived from the J2735 standard where applicable. All BMMs are generated by OBUs and ultimately received by the VCC Cloud server.

Contains all PDCMs generated during the AMCD field testing program. The PDCM is a control message sent from the server to OBUs to customize a request for Probe Vehicle Data (PVD) from the receiving OBU. All PDCMs are generated by the VCC Cloud server and transmitted to OBU clients through either a DSRC or cellular communications channel.

Contains all PDCMs generated during the AMCD field testing program. The PDCM is a control message sent from the server to OBUs to customize a request for Probe Vehicle Data (PVD) from the receiving OBU. All PDCMs are generated by the VCC Cloud server and transmitted to OBU clients through either a DSRC or cellular communications channel.

Contains all PVDs generated during the AMCD field testing program. The probe vehicle message is used to exchange status about a vehicle with other DSRC readers to allow the collection of information about a typical vehicle’s traveling behaviors along a segment of road. The exchanges of this message as well as the event which caused the collection of various elements defined in the messages are in Annex B of the SAE J2735 standard.

Contains all PVDs generated during the AMCD field testing program. The probe vehicle message is used to exchange status about a vehicle with other DSRC readers to allow the collection of information about a typical vehicle’s traveling behaviors along a segment of road. The exchanges of this message as well as the event which caused the collection of various elements defined in the messages are in Annex B of the SAE J2735 standard.

Data is from the small-scale demonstration of the Intelligent Network Flow Optimization (INFLO) Prototype System and applications in Seattle, Washington. Connected vehicle systems were deployed in 21 vehicles in a scripted driving scenario circuiting this I-5 corridor northbound and southbound during morning rush hour. Basic Safety Messages (BSM) sent by connected vehicles (CVs) through either the cellular network or Dedicated Short Range Communication (DSRC) when the vehicle is in the range of Roadside Units (RSU). These messages were received by the traffic management center (TMC).

Data is from the small-scale demonstration of the Intelligent Network Flow Optimization (INFLO) Prototype System and applications in Seattle, Washington. Connected vehicle systems were deployed in 21 vehicles in a scripted driving scenario circuiting this I-5 corridor northbound and southbound during morning rush hour. Basic Safety Messages (BSM) sent by connected vehicles (CVs) through either the cellular network or Dedicated Short Range Communication (DSRC) when the vehicle is in the range of Roadside Units (RSU). These messages were received by the traffic management center (TMC).

Data is from the small-scale demonstration of the Intelligent Network Flow Optimization (INFLO) Prototype System and applications in Seattle, Washington. Connected vehicle systems were deployed in 21 vehicles in a scripted driving scenario circuiting this I-5 corridor northbound and southbound during morning rush hour. This data set contains queue warning messages that were recommended by the INFLO Q-WARN algorithm and sent by the traffic management center to vehicles to warn drivers upstream of the queue. The objective of queue warning is to provide a vehicle operator sufficient warning of impending queue backup in order to brake safely, change lanes, or modify route such that secondary collisions can be minimized or even eliminated.

Data is from the small-scale demonstration of the Intelligent Network Flow Optimization (INFLO) Prototype System and applications in Seattle, Washington. Connected vehicle systems were deployed in 21 vehicles in a scripted driving scenario circuiting this I-5 corridor northbound and southbound during morning rush hour. This data set contains queue warning messages that were recommended by the INFLO Q-WARN algorithm and sent by the traffic management center to vehicles to warn drivers upstream of the queue. The objective of queue warning is to provide a vehicle operator sufficient warning of impending queue backup in order to brake safely, change lanes, or modify route such that secondary collisions can be minimized or even eliminated.

Data is from the small-scale demonstration of the Intelligent Network Flow Optimization (INFLO) Prototype System and applications in Seattle, Washington. Connected vehicle systems were deployed in 21 vehicles in a scripted driving scenario circuiting this I-5 corridor northbound and southbound during morning rush hour. This data set contains speed harmonization messages that were recommended by the INFLO SPD-HARM algorithm and sent by the traffic management center to the connected vehicles, which provided drivers with the suggested speed while driving on the segment of I-5 that was included in the test. The objective of speed harmonization is to dynamically adjust and coordinate maximum appropriate vehicle speeds in response to downstream congestion, incidents, and weather or road conditions in order to maximize traffic throughput and reduce crashes.

Data is from the small-scale demonstration of the Intelligent Network Flow Optimization (INFLO) Prototype System and applications in Seattle, Washington. Connected vehicle systems were deployed in 21 vehicles in a scripted driving scenario circuiting this I-5 corridor northbound and southbound during morning rush hour. This data set contains speed harmonization messages that were recommended by the INFLO SPD-HARM algorithm and sent by the traffic management center to the connected vehicles, which provided drivers with the suggested speed while driving on the segment of I-5 that was included in the test. The objective of speed harmonization is to dynamically adjust and coordinate maximum appropriate vehicle speeds in response to downstream congestion, incidents, and weather or road conditions in order to maximize traffic throughput and reduce crashes.

The WZDx Specification enables infrastructure owners and operators (IOOs) to make harmonized work zone data available for third party use. The intent is to make travel on public roads safer and more efficient through ubiquitous access to data on work zone activity. Specifically, the project aims to get data on work zones into vehicles to help automated driving systems (ADS) and human drivers navigate more safely. MCDOT leads the effort to aggregate and collect work zone data from the AZTech Regional Partners. A continuously updating archive of the WZDx feed data can be found at ITS WorkZone Data Sandbox. The live feed is currently compliant with WZDx specification version 1.1.

The WZDx Specification enables infrastructure owners and operators (IOOs) to make harmonized work zone data available for third party use. The intent is to make travel on public roads safer and more efficient through ubiquitous access to data on work zone activity. Specifically, the project aims to get data on work zones into vehicles to help automated driving systems (ADS) and human drivers navigate more safely. MCDOT leads the effort to aggregate and collect work zone data from the AZTech Regional Partners. A continuously updating archive of the WZDx feed data can be found at ITS WorkZone Data Sandbox. The live feed is currently compliant with WZDx specification version 1.1.

The WZDx Specification enables infrastructure owners and operators (IOOs) to make harmonized work zone data available for third party use. The intent is to make travel on public roads safer and more efficient through ubiquitous access to data on work zone activity. Specifically, the project aims to get data on work zones into vehicles to help automated driving systems (ADS) and human drivers navigate more safely. MCDOT leads the effort to aggregate and collect work zone data from the AZTech Regional Partners. A continuously updating archive of the WZDx feed data can be found at ITS WorkZone Data Sandbox. The live feed is currently compliant with WZDx specification version 3.0.

The WZDx Specification enables infrastructure owners and operators (IOOs) to make harmonized work zone data available for third party use. The intent is to make travel on public roads safer and more efficient through ubiquitous access to data on work zone activity. Specifically, the project aims to get data on work zones into vehicles to help automated driving systems (ADS) and human drivers navigate more safely. MCDOT leads the effort to aggregate and collect work zone data from the AZTech Regional Partners. A continuously updating archive of the WZDx feed data can be found at ITS WorkZone Data Sandbox. The live feed is currently compliant with WZDx specification version 3.0.

This is the EVENT data captured from the New York City CV Pilot project that was processed by the independent evaluators at Volpe. Additional data collected and data dictionary are in the attachments. Each EVENT record documents the details of one application warning that occurred on an Aftermarket Safety Device (ASD) in an equipped host vehicle and includes CV messages from a defined recording time both before and after the warning was generated by the host ASD. Messages in the recording time window include the Basic Safety Messages (BSM) of the host vehicle that received the warning, as well as other BSMs received from the warning target equipped vehicle (for V2V applications) or other nearby equipped vehicles. Depending on the application warning type, MAP messages, Signal Phase and Timing (SPaT) messages, and Traveler Information Messages (TIM) that were heard by the host vehicle may also be included in the event record.

This is the EVENT data captured from the New York City CV Pilot project that was processed by the independent evaluators at Volpe. Additional data collected and data dictionary are in the attachments. Each EVENT record documents the details of one application warning that occurred on an Aftermarket Safety Device (ASD) in an equipped host vehicle and includes CV messages from a defined recording time both before and after the warning was generated by the host ASD. Messages in the recording time window include the Basic Safety Messages (BSM) of the host vehicle that received the warning, as well as other BSMs received from the warning target equipped vehicle (for V2V applications) or other nearby equipped vehicles. Depending on the application warning type, MAP messages, Signal Phase and Timing (SPaT) messages, and Traveler Information Messages (TIM) that were heard by the host vehicle may also be included in the event record.

This dataset contains a one-month sample of flattened EVENT data records from the New York City (NYC) Connected Vehicle (CV) Pilot that have undergone obfuscation of precise time and location details as well as other vehicle identifiers. The full unflattened event data from NYC CV pilot can be found in the ITS Sandbox. Each EVENT record documents the details of one application warning that occurred on an Aftermarket Safety Device (ASD) in an equipped host vehicle and includes CV messages from a defined recording time both before and after the warning was generated by the host ASD. Messages in the recording time window include the Basic Safety Messages (BSM) of the host vehicle that received the warning, as well as other BSMs received from the warning target equipped vehicle (for V2V applications) or other nearby equipped vehicles. Depending on the application warning type, MAP messages, Signal Phase and Timing (SPaT) messages, and Traveler Information Messages (TIM) that were heard by the host vehicle may also be included in the event record.

This dataset contains a one-month sample of flattened EVENT data records from the New York City (NYC) Connected Vehicle (CV) Pilot that have undergone obfuscation of precise time and location details as well as other vehicle identifiers. The full unflattened event data from NYC CV pilot can be found in the ITS Sandbox. Each EVENT record documents the details of one application warning that occurred on an Aftermarket Safety Device (ASD) in an equipped host vehicle and includes CV messages from a defined recording time both before and after the warning was generated by the host ASD. Messages in the recording time window include the Basic Safety Messages (BSM) of the host vehicle that received the warning, as well as other BSMs received from the warning target equipped vehicle (for V2V applications) or other nearby equipped vehicles. Depending on the application warning type, MAP messages, Signal Phase and Timing (SPaT) messages, and Traveler Information Messages (TIM) that were heard by the host vehicle may also be included in the event record.

Click “Export” on the right to download the vehicle trajectory data. The associated metadata and additional data can be downloaded below under "Attachments". Researchers for the Next Generation Simulation (NGSIM) program collected detailed vehicle trajectory data on southbound US 101 and Lankershim Boulevard in Los Angeles, CA, eastbound I-80 in Emeryville, CA and Peachtree Street in Atlanta, Georgia. Data was collected through a network of synchronized digital video cameras. NGVIDEO, a customized software application developed for the NGSIM program, transcribed the vehicle trajectory data from the video. This vehicle trajectory data provided the precise location of each vehicle within the study area every one-tenth of a second, resulting in detailed lane positions and locations relative to other vehicles. Click the "Show More" button below to find additional contextual data and metadata for this dataset. For site-specific NGSIM video file datasets, please see the following: - NGSIM I-80 Videos: https://data.transportation.gov/Automobiles/Next-Generation-Simulation-NGSIM-Program-I-80-Vide/2577-gpny - NGSIM US-101 Videos: https://data.transportation.gov/Automobiles/Next-Generation-Simulation-NGSIM-Program-US-101-Vi/4qzi-thur - NGSIM Lankershim Boulevard Videos: https://data.transportation.gov/Automobiles/Next-Generation-Simulation-NGSIM-Program-Lankershi/uv3e-y54k - NGSIM Peachtree Street Videos: https://data.transportation.gov/Automobiles/Next-Generation-Simulation-NGSIM-Program-Peachtree/mupt-aksf

Click “Export” on the right to download the vehicle trajectory data. The associated metadata and additional data can be downloaded below under "Attachments". Researchers for the Next Generation Simulation (NGSIM) program collected detailed vehicle trajectory data on southbound US 101 and Lankershim Boulevard in Los Angeles, CA, eastbound I-80 in Emeryville, CA and Peachtree Street in Atlanta, Georgia. Data was collected through a network of synchronized digital video cameras. NGVIDEO, a customized software application developed for the NGSIM program, transcribed the vehicle trajectory data from the video. This vehicle trajectory data provided the precise location of each vehicle within the study area every one-tenth of a second, resulting in detailed lane positions and locations relative to other vehicles. Click the "Show More" button below to find additional contextual data and metadata for this dataset. For site-specific NGSIM video file datasets, please see the following: - NGSIM I-80 Videos: https://data.transportation.gov/Automobiles/Next-Generation-Simulation-NGSIM-Program-I-80-Vide/2577-gpny - NGSIM US-101 Videos: https://data.transportation.gov/Automobiles/Next-Generation-Simulation-NGSIM-Program-US-101-Vi/4qzi-thur - NGSIM Lankershim Boulevard Videos: https://data.transportation.gov/Automobiles/Next-Generation-Simulation-NGSIM-Program-Lankershi/uv3e-y54k - NGSIM Peachtree Street Videos: https://data.transportation.gov/Automobiles/Next-Generation-Simulation-NGSIM-Program-Peachtree/mupt-aksf

This set of data files was acquired under USDOT FHWA cooperative agreement DTFH61-11-H-00025 as one of the four test data sets acquired by the USDOT Data Capture and Management program. This is the primary loop detector data table. It contains one-minute volume, occupancy, and data quality flags for the arterial loop detector data.

This set of data files was acquired under USDOT FHWA cooperative agreement DTFH61-11-H-00025 as one of the four test data sets acquired by the USDOT Data Capture and Management program. This is the primary loop detector data table. It contains one-minute volume, occupancy, and data quality flags for the arterial loop detector data.

The Belle Isle data was collected between May 1st, 2014 and September 16th, 2014 on the Belle Isle Park in Michigan. However, within the data file provided as part of this data environment, only data during the World Congress demonstration period from September 5, 2014 to September 11, 2014 is included. Several vehicles equipped with multiple sensors drove around the island collecting 572,030 readings of multiple variables. The uploaded data file lists all those observations and the pertaining details about the sensor equipment, the sensor platform and the status of quality checking performed for each observation.

The Belle Isle data was collected between May 1st, 2014 and September 16th, 2014 on the Belle Isle Park in Michigan. However, within the data file provided as part of this data environment, only data during the World Congress demonstration period from September 5, 2014 to September 11, 2014 is included. Several vehicles equipped with multiple sensors drove around the island collecting 572,030 readings of multiple variables. The uploaded data file lists all those observations and the pertaining details about the sensor equipment, the sensor platform and the status of quality checking performed for each observation.

The Tampa CV Pilot generates data from the interaction between vehicles and between vehicles and infrastructure. This dataset consists of Basic Safety Messages (BSMs) generated by participant and public transportation vehicles onboard units (OBU) and transmitted to road-side units (RSU) located throughout the Tampa CV Pilot Study area. The full set of raw, BSM data from Tampa CV Pilot can be found in the ITS Sandbox. The data fields follow SAE J2735 and J2945/1 standards and adopted units of measure. This dataset holds a flattened sample of the BSM data from Tampa CV Pilot. An extra geo column (coreData_position) was added to this dataset to allow for mapping of the geocoded BSM data within Socrata, and a column of random numbers (randomNum) was added to allow for random sampling of data points within Socrata.

The Tampa CV Pilot generates data from the interaction between vehicles and between vehicles and infrastructure. This dataset consists of Basic Safety Messages (BSMs) generated by participant and public transportation vehicles onboard units (OBU) and transmitted to road-side units (RSU) located throughout the Tampa CV Pilot Study area. The full set of raw, BSM data from Tampa CV Pilot can be found in the ITS Sandbox. The data fields follow SAE J2735 and J2945/1 standards and adopted units of measure. This dataset holds a flattened sample of the BSM data from Tampa CV Pilot. An extra geo column (coreData_position) was added to this dataset to allow for mapping of the geocoded BSM data within Socrata, and a column of random numbers (randomNum) was added to allow for random sampling of data points within Socrata.

The Tampa CV Pilot generates data from the interaction between vehicles and between vehicles and infrastructure. This dataset consists of Signal Phasing and Timing Message (SPaT) Messages transmitted by road-side units (RSU) located throughout the Tampa CV Pilot Study area. The full set of raw, SPaT data from Tampa CV Pilot can be found in the ITS Sandbox. The data fields follow SAE J2735 data frames (Section 6) and structure (Section 7). This dataset holds a flattened sample of the SPaT data from Tampa CV Pilot. A column of random numbers (randomNum) was added to allow for random sampling of data points within Socrata.

The Tampa CV Pilot generates data from the interaction between vehicles and between vehicles and infrastructure. This dataset consists of Signal Phasing and Timing Message (SPaT) Messages transmitted by road-side units (RSU) located throughout the Tampa CV Pilot Study area. The full set of raw, SPaT data from Tampa CV Pilot can be found in the ITS Sandbox. The data fields follow SAE J2735 data frames (Section 6) and structure (Section 7). This dataset holds a flattened sample of the SPaT data from Tampa CV Pilot. A column of random numbers (randomNum) was added to allow for random sampling of data points within Socrata.

The Tampa CV Pilot generates data from the interaction between vehicles and between vehicles and infrastructure. This dataset consists of Traveler Information Messages (TIMs) transmitted by road-side units (RSU) located throughout the Tampa CV Pilot Study area. The full set of raw, TIM data from Tampa CV Pilot can be found in the ITS Sandbox. The data fields follow a SAE J2735 TIM message structure to convey important traffic information to onboard units (OBU) of equipped vehicles. Refer to SAE J2735 Section 5.16 Message: MSG_TravelerInformation Message (TIM). This dataset holds a flattened sample of the TIM data from Tampa CV Pilot. Three additional fields were added to this Socrata dataset during ETL: a geo column (travelerdataframe_msgId_position) to allow for mapping of the geocoded TIM data within Socrata, a random number column (randomNum) to allow for random sampling of data points within Socrata, and a time of day generated column (metadata_generatedAt_timeOfDay) to allow for filtering of data by generated time.

The Tampa CV Pilot generates data from the interaction between vehicles and between vehicles and infrastructure. This dataset consists of Traveler Information Messages (TIMs) transmitted by road-side units (RSU) located throughout the Tampa CV Pilot Study area. The full set of raw, TIM data from Tampa CV Pilot can be found in the ITS Sandbox. The data fields follow a SAE J2735 TIM message structure to convey important traffic information to onboard units (OBU) of equipped vehicles. Refer to SAE J2735 Section 5.16 Message: MSG_TravelerInformation Message (TIM). This dataset holds a flattened sample of the TIM data from Tampa CV Pilot. Three additional fields were added to this Socrata dataset during ETL: a geo column (travelerdataframe_msgId_position) to allow for mapping of the geocoded TIM data within Socrata, a random number column (randomNum) to allow for random sampling of data points within Socrata, and a time of day generated column (metadata_generatedAt_timeOfDay) to allow for filtering of data by generated time.

The Tampa CV Pilot generates data from the interaction between vehicles and between vehicles and infrastructure. This dataset consists of Traveler Information Messages (TIMs) transmitted by road-side units (RSU) located throughout the Tampa CV Pilot Study area. The full set of raw, TIM data from Tampa CV Pilot can be found in the ITS Sandbox. The data fields follow a SAE J2735 TIM message structure to convey important traffic information to onboard units (OBU) of equipped vehicles. Refer to SAE J2735 Section 5.16 Message: MSG_TravelerInformation Message (TIM). This dataset holds a flattened sample of the TIM data from Tampa CV Pilot. Three additional fields were added to this Socrata dataset during ETL: a geo column (travelerdataframe_msgId_position) to allow for mapping of the geocoded TIM data within Socrata, a random number column (randomNum) to allow for random sampling of data points within Socrata, and a time of day generated column (metadata_generatedAt_timeOfDay) to allow for filtering of data by generated time.

This dataset contains the up-to-date metadata on Work Zone feeds that meet the Work Zone Data Exchange (WZDx) specifications and is registered with USDOT ITS DataHub. The current work zone data from each feed can be accessed through their respective API links. Some links provide direct access, while others require a user to create their own API access key first. Please see the attached API Key Instructions document to learn how to sign up for API keys for the requisite feeds. The ITS Work Zone Sandbox, contains an archive of work zone data collected from each feed at a rate of at least every 15 minutes. This is not intended as a replacement for the work zone feeds and in many cases does not update as frequently as the feed does.

This dataset contains the up-to-date metadata on Work Zone feeds that meet the Work Zone Data Exchange (WZDx) specifications and is registered with USDOT ITS DataHub. The current work zone data from each feed can be accessed through their respective API links. Some links provide direct access, while others require a user to create their own API access key first. Please see the attached API Key Instructions document to learn how to sign up for API keys for the requisite feeds. The ITS Work Zone Sandbox, contains an archive of work zone data collected from each feed at a rate of at least every 15 minutes. This is not intended as a replacement for the work zone feeds and in many cases does not update as frequently as the feed does.