6-09. ADX API Document v1.10.pdf
PDF 955 KB Posted
- Solicitation number
- UDOT250259MP-1
- Issued by
- Utah
About this file
This document is the ADX API Documentation (Revision 1.10) for the Utah Department of Transportation (UDOT), developed in collaboration with Mindhop. The document provides a comprehensive technical specification for the ATMS (Advanced Traffic Management System) Data Exchange (ADX) API, which offers transportation data access through REST and GraphQL interfaces. The API is designed to provide current traffic conditions and transportation information for both public and government users, with a submission date of December 19, 2024. The documentation covers multiple data domains including roadway network definition, traffic data, event data, device data, vehicle data, weather data, and Road Weather Information System (RWIS) data.
The API utilizes OAuth authentication and supports two primary access methods: REST and GraphQL, allowing flexible data retrieval. Users can access various types of transportation-related data, including road nodes, links, roadways, route traffic, device information (such as CCTV and variable messaging signs), vehicle positions, weather forecasts and alerts, and detailed road surface and atmospheric observations. The API is structured to provide granular, geospatial-enabled data with timestamp tracking, enabling developers and technical managers to integrate real-time transportation information into their applications. Each data endpoint includes detailed attribute tables specifying data types, nullability, and descriptions, ensuring comprehensive and standardized data access across different transportation information categories.
View the file
Other files
Show all 12
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
ADX API
DOCUMENTATION
Rev 1.10
Submission Date
December 19, 2024 i
ADX API Document
CONTENTS
1 Overview
2 Authentication
3 Access and Requests
3.1 GraphQL
3.2 REST
3.3 Documentation
4 Specification
4.1 Roadway Network Definition
4.1.1 Road Nodes
4.1.2 Nodes by Geometry
4.1.3 Links
4.1.4 Links by Geometry
4.1.5 Roadways
4.1.6 Route Links
4.1.7 Roadway Links
4.1.8 Routes
4.1.9 Routes by Geometry
4.2 Traffic Data
4.2.1 Link Traffic
4.2.2 Link Traffic by Geometry
4.2.3 Route Traffic
4.2.4 Route Traffic by Geometry
4.3 Event Data
4.3.1 Events
4.3.2 Event Schedules
4.3.3 Event Messages Current
4.3.4 Event Messages Historic
4.4 Device Data
4.4.1 Devices
4.4.2 CCTV
4.4.3 VMS
4.4.4 Traffic Monitoring Stations Inventory
4.4.5 Current Traffic Monitoring Stations Data
4.4.6 Historic Traffic Monitoring Stations Data
4.5 Vehicle Data
4.5.1 Vehicles
4.5.2 Vehicle Positions
4.6 Weather Data
4.6.1 Weather
4.6.2 Weather Alerts
ii
4.6.3 Weather Hourly
4.7 RWIS Data
4.7.1 RWIS Surface Observations
4.7.2 RWIS Atmospheric Observations
4.7.3 Mountain Pass
LIST OF TABLES
Table 1 - Document Revision ........................................................................................................... iii Table 2 - Possible Filtering Operators Table 3 - Road Nodes Data Attributes Table 4 - Nodes by Geom Input Variable(s) Table 5 - Links Data Attributes Table 6 - Links by Geom Input Variables Table 7 - Roadways Data Attributes Table 8 - Route Links Data Attributes Table 9 - Roadway Links Data Attributes Table 10 - Routes Data Attributes Table 11 - Routes by Geom Input Variable(s) Table 12 - Link Traffic Data Attributes Table 13 - Link Traffic Data by Geom Input Variable(s) Table 14 - Route Traffic Data Attributes Table 15 - Route Traffic Data by Geom Input Variable(s) Table 16 - Events Data Attributes Table 17 - Event Schedules Data Attributes Table 18 - Event Messages Current Data Attributes Table 19 - Event Messages Historic Data Attributes Table 20 - Devices Data Attributes Table 21 - CCTV Data Attributes Table 22 - VMS Data Attributes Table 23 - TMS Inventory Data Attributes Table 24 - TMS Data Current Data Attributes Table 25 - TMS Data Historic Data Attributes Table 26 - Vehicle Data Attributes Table 27 - Vehicle Positions Data Attributes Table 28 - Weather Data Attributes Table 29 - Weather Alert Data Attributes Table 30 - Weather Hourly Data Attributes Table 31 - RWIS Surface Observations Data Attributes Table 32 - RWIS Atmospheric Observations Data Attributes Table 33 - Mountain Pass Data Attributes iii
Document Revisions
Version Date Comments
1.01 7/17/2023 General API specifications for Traffic Data
1.02 7/28/2023 - Corrected endpoints for routes and roadways
- Corrected ingeom example input geometry
- Changed example requests to link data
- Added further explanation for REST API
1.03 8/23/2023 - Adjusted Authorization section to reflect implementation of OAuth
- Corrected several data types to properly reflect the data received from the API
- Added documentation for further API endpoints (events, devices, weather, vehicles)
1.04 - Added routelinks and roadwaylinks endpoints
1.05 12/6/2023 - Modified and renamed tms_inventory endpoint (previously detector_inventory)
- Modified and renamed tms_data_current endpoint (previously detector_data)
- Added tms_data_historic endpoint
- Various corrections, additional acronym definitions
1.05.1 12/19/2023 - Various corrections and formatting modifications
1.06 12/20/2023 - Removed roadwaysbygeom section
- Various corrections and formatting modifications
1.07 6/17/2024 - Numerous updates for AT testing
1.08 10/16/2024 - Updated tms_inventory, tms_data_current, and tms_data_historic endpoint data attribute tables
1.09 10/23/2024 - Corrections to tms_inventory endpoint data attribute table
- Updated ActiveITS name to ARCH
1.10 12/19/2024 - Updated /events, /tms_inventory, /tms_data_current, /tms_data_historic, /vms, and /vehicle_positions endpoints
Table 1 - Document Revision iv cronyms
ADR ATMS Data Repository
ADX ATMS Data Exchange
API Application Programming Interface
ATMS Advanced Traffic Management System
API Application Programming Interface
HTTPS Secure Hypertext Transfer Protocol
IDE Integrated Development Environment
JSON JavaScript Object Notation
REST Representational State Transfer
RWIS Road Weather Information System
TMDD Traffic Management Data Dictionary
TMS Traffic Monitoring Station
UDOT Utah Department of Transportation
URI Uniform Resource Identifier
URL Uniform Resource Locator
1 OVERVIEW
The purpose of this document is to provide a detailed specification for the UDOT ADX API with includes current traffic conditions. The ADR/ADX API will provide an accessible interface for both the public and government employees, utilizing two industry standard approaches: REST and GraphQL. All resources will be available in either form.
The intended audience for this document is:
- Software developers who wish to make use of UDOT’s transportation information for their own applications.
- Technical managers who wish to evaluate the information specification for use in their applications.
- The general public, interested in accessing the data for their own use.
2 AUTHENTICATION
The client authentication process utilizes OAuth and follows the flow shown below.
Each step in the authentication process is detailed below:
1. The first step in the Authentication process involves the client sending credentials to the OAuth server via a POST request to the URL with the body (both shown below):
URL: https://udot-adr-adx.us.auth0.com/oauth/token
Body:
“client_id”: <client_id>, “client_secret”: <client_secret>, “audience”: “https://adr-adx.at.udot.utah.gov/”, “grant_type”: “client_credentials”
2. A successful request will result in a response with a status of 200 and a body with the following format:
Body:
“access_token”: <access_token>, “expires_in”: <expiration_in_seconds>, “token_type”: “Bearer”
The default expiration for the token will be 24 hours (86400 seconds). This will be the value assigned to the “expires_in” field, and it can be used within client applications to determine when a new access token should be requested.
3. At this point, the client no longer has to make requests to the OAuth server until their token expires. The client will include the access token to authorize itself to the ADX API. Each request to the ADX API needs to include the following header:
“Authorization”: “Bearer <access_token>”
4. If a valid and authorized access token was included under the authorization header, the ADX
API will respond with the desired data.
3 ACCESS AND REQUESTS
The UDOT Traffic Data can be accessed using two API frameworks: GraphQL and REST. All data types can be accessed through either method; the choice of the method is left to the user.
All requests will be made over secure https:
• For REST, GET requests will be made to the appropriate endpoint (i.e., “/api/v1/links).
Suitable for traditional and general-purpose API Access
• For GraphQL, requests will be made in the form of a POST request to a single GraphQL endpoint (“/graphql”); the body of the request will provide the information necessary to retrieve the requested information.
Suitable for applications that need to minimize the data fetching over the network, for example mobile applications.
3.1 GRAPHQL
A standard GraphQL POST request should use the “application/json” content type, and include a JSON encoded body of the following form:
“query”: “...”
“operationName”: “...”, “variables” : { “someVariable”: “someValue”}
Here, OperationName and variables are optional fields. OperationName is only required if multiple operations are present in the query.
Here’s an example of what a query may look like:
“query”: “query GetLinkData($linkId: String!) { links(id: $id) { nodes { id linkName linkType lengthInMeters lastUpdate
“operationName”: “GetLinkData”, “variables” : { “id”: “10” }
And an example response.
"data": { "links": { “nodes”: [ "id": 10, "linkName": "I-84", "linkType": 1, "lengthInMeters": 185.4357, "lastUpdate": “2023-07-26 13:04:02.831”
Note: The information is provided in the same format as requested. GraphQL allows the user to only request data that they need; if only the type of event and the description was desired, the request should only include those values, and only those values would be returned.
3.2 REST
A REST request should be sent to a specific endpoint where the data is located. To access the same link data as described in the example above, a GET request can be sent to the example URI below containing the necessary authentication information (see section “Authentication” above).
Request URI format: /api/v1/<resource_name>?<attribute>=<operator>.<value>
Example request URI: /api/v1/links?id=eq.10
This request would yield the following response:
"id": 10, "link_name": "I-84", "link_type": 1, "length_in_meters": 185.4357, "last_update": “2023-07-26 13:04:02.831”, ...more fields...
Each endpoint begins with “/api/v1/<resource_name>”, with <resource_name> being the name of the desired resource. As detailed in the specifications in section 4, <resource_name> is also prefixed by
“/rpc” when querying any of the “_bygeom” endpoints. For example, “/api/v1/rpc/linksbygeom?...” is used to query links by geometry.
Optionally, the <resource_name> is followed by “?” and filter parameters if any sort of filtering is desired. The REST API supports both vertical and horizontal filtering (on rows and columns) with the syntax described below.
In the example above, <resource_name> is “links”. The desired link has an id of 10, so <attribute> is
“id”, <operator> is “eq” (equals), and <value> is “10”. A list of some possible operators for horizontal filtering are:
Operator eq gt gte lt lte neq in
Meaning Equals Greater than
Greater than or equal to
Less than
Less than or equal to
Not equal to
In a list of values i.e. “?a=in.(1,2,3)”
Table 2 - Possible Filtering Operators
Vertical filtering can be achieved with the “select” parameter. In the example above, including
“select=id,link_name,link_type” in the request would return only those fields in the response.
Multiple filters can be combined with an ampersand “&”.
3.3 DOCUMENTATION
The GraphQL endpoint will have documentation available in static form and through a GraphQL IDE that allows for interactive composition of queries.
The REST endpoint is OpenAPI compliant and will have documentation generated from its specification.
4 SPECIFICATION
4.1 ROADWAY NETWORK DEFINITION
A traffic network represents a collection of roadways, nodes, links, and routes. A node is the smallest data element that is unique within a network. Nodes provide a geographic location that can represent the beginning and end points of a link, location of a device, intersection, or location of an incident.
Roadways and routes are a collection of links.
4.1.1 Road Nodes
A road_node is a point within a network. Road nodes provide a geographic location that can represent the beginning and end points of a link, location of a device, intersection, or location of an event.
4.1.1.1 Retrieve
/api/v1/road_nodes?<PARAMS> query{ roadNodes(condition:{<PARAMS>}) { nodes {
<FIELDS>
Attribute Type Nullable Description id
Integer
No Unique identifier for the node.
node_name String
Yes Name of the node direction String
Yes The direction, as per TMDD specification intersection_type String Yes The type of intersection of the node.
geom Object No The physical shape of the node, formatted in
GeoJSON.
status Integer No The status of the node, 1 = active, 0 = disabled.
last_update String No The last time the node definition was updated in the format “yyyy-MM-dd'T’HH:mm:ss.SSSSSS”
Table 3 - Road Nodes Data Attributes
4.1.2 Nodes by Geometry
NodesByGeom allows the API user to specify a geometry comprised of latitudes and longitudes and returns all road nodes and their corresponding information that intersect the geometry. See Route
Traffic below for specifications on the data available for each route.
4.1.2.1 Retrieve
/api/v1/rpc/nodesbygeom?<PARAMS> query { nodesByGeom (condition: {<PARAMS>} { nodes {
<FIELDS>
Attribute Type Required Description Example ingeom string Yes The input geometry, comprised of a geometry type and longitudes and latitudes that define the
“POLYGON
((-77.420 42.580, -
77.422 42.580, -
77.422 42.584, -shape to compare all links against
77.420 42.584, -
77.420 42.580))”
Table 4 - Nodes by Geom Input Variable(s)
4.1.3 Links
A link is defined as a roadway or transit right-of-way between two nodes.
4.1.3.1 Retrieve
/api/v1/links?<PARAMS> links(condition:{<PARAMS>}) { nodes {
<FIELDS>
id Integer No Unique identifier for the link.
owner_org String Yes The “owner” of the link, in terms of its source. For example, can be HERE, Waze, etc.
link_name String Yes The link’s name, serving as a descriptor of the piece of road the link represents.
direction String Yes The link’s direction, as per TMDD specification.
link_type String Yes The link type, representing the functional class of roadway segment covered by the link. Functional class values range from 1-5. See HERE documentation for more information:
1: a road with high volume, maximum speed traffic
2: a road with high volume, high speed traffic
3: a road with high volume traffic
4: a road with high volume traffic at moderate speeds between neighborhoods
5: a road whose volume and traffic flow https://www.here.com/docs/bundle/traffic-api-developer-guide-v6/page/topics/resource-type-functional-class.html https://www.here.com/docs/bundle/traffic-api-developer-guide-v6/page/topics/resource-type-functional-class.html are below the level of any other functional class geom Object Yes The physical shape of the link, formatted in GeoJSON.
length_in_meters Float Yes Length of the link segment in meters.
from_node_id Integer Yes The ID of the node where the link begins.
from_node_name String Yes The name of the node where the link begins.
from_latitude Float Yes The latitude of the node where the link begins.
from_longitude Float Yes The longitude of the node where the link begins.
to_node_id Integer Yes The ID of the node where the link ends.
to_node_name String Yes The name of the node where the link ends.
to_latitude Float Yes The latitude of the node where the link ends.
to_longitude Float Yes The longitude of the node where the link ends.
speed_limit_kph Integer Yes The speed limit, in kilometers per hour.
status Integer Yes The status of the link, 1 = active, 0 = disabled.
last_update String Yes The last time the link definition was updated in the format “yyyy-MM-dd'T’HH:mm:ss.SSSSSS”
Table 5 - Links Data Attributes
4.1.4 Links by Geometry
LinksByGeom allows the API user to specify a geometry comprised of latitudes and longitudes and returns all links and their corresponding information that intersect the geometry. See Route Traffic below for specifications on the data available for each route.
4.1.4.1 Retrieve
/api/v1/rpc/linksbygeom?<PARAMS> linksByGeom (condition: {<PARAMS>} { nodes {
<FIELDS>
comprised of a geometry type and longitudes and latitudes that define the shape to compare all links against
“POLYGON
((-77.420 42.580, -
77.422 42.580, -
77.422 42.584, -
77.420 42.584, -
77.420 42.580))”
Table 6 - Links by Geom Input Variables
4.1.5 Roadways
A roadway is a road, made up of a series of links.
4.1.5.1 Retrieve
/api/v1/roadways?<PARAMS> roadways(condition:{<PARAMS>}) { nodes {
<FIELDS>
id Integer No The unique identifier of the roadway.
roadway_name String No The name of the roadway.
direction String No The direction of the roadway, per TMDD specification.
roadway_type String Yes The type of the roadway (I.e., highway, bridge, etc.)
shape_length Float Yes The length of the roadway, in kilometers.
zip_code_l Integer Yes The zip code of the roadway, facing left.
zip_code_r Integer Yes The zip code of the roadway, facing right.
county_fips_l Integer Yes National FIPS code for the county, facing left.
county_fips_r Integer Yes National FIPS code for the county, facing right.
state_l Integer Yes National FIPS code for the state, facing left.
state_r Integer Yes National FIPS code for the state, facing right.
owner_org Integer No The owning entity of the roadway definition.
status Integer No The status of the roadway in the ADR; 1 = active, 0 = disabled.
last_update String No The last time the road definition was updated in the format “yyyy-MM-dd'T’HH:mm:ss.SSSSSS” Table 7 - Roadways Data Attributes
4.1.6 Route Links
Each route contains several links that it is comprised of. This endpoint returns a list that specifies which links are contained in each route.
4.1.6.1 Retrieve
/api/v1/routelinks?<PARAMS> routelinks(condition:{<PARAMS>}) { nodes {
<FIELDS>
id Integer No The unique identifier of the route/link relationship route_id Integer No The unique identifier for the route link_id Integer No The unique identifier for the link segment_fraction Float No A value ranging from 0 to 1 that specifies the proportion of the link that is contained in the route seq_order Integer No A number starting at 1 and increasing that specifies the order of the links along the route Table 8 - Route Links Data Attributes
4.1.7 Roadway Links
Each roadway contains several links that it is comprised of. This endpoint returns a list that specifies which links are contained in each roadway.
4.1.7.1 Retrieve
/api/v1/roadwaylinks?<PARAMS> roadwaylinks(condition:{<PARAMS>}) { nodes {
<FIELDS>
id Integer No The unique identifier of the roadway/link relationship roadway_id Integer No The unique identifier for the roadway link_id Integer No The unique identifier for the link segment_fraction Float No A value ranging from 0 to 1 that specifies the proportion of the link that is contained in the roadway seq_order Integer Yes A number starting at 1 and increasing that specifies the order of the links along the roadway Table 9 - Roadway Links Data Attributes
4.1.8 Routes
A route is a user defined collection of links. It is assumed that the collection of links are contiguous.
That is, all links except for the first and last link are “joined” by one other link within the collection on both ends.
4.1.8.1 Retrieve
/api/v1/routes?<PARAMS> query{ routes(condition:{<PARAMS>}) { nodes {
<FIELDS>
id Integer No Unique identifier for the route.
route_name String Yes Name of the route direction String Yes The direction, as per TMDD specification route_type String Yes The type of route facility String Yes The facility that the route is associated with.
geom Object No The geospatial representation of the route, formatted in GeoJSON status Integer No Current status of a route. 1 = active, 0 = disabled.
last_update String Yes The last time the route was updated in the format “yyyy-MM-dd'T’HH:mm:ss.SSS”
Table 10 - Routes Data Attributes
4.1.9 Routes by Geometry
RoutesByGeom allows the API user to specify a geometry comprised of latitudes and longitudes and returns all routes and their corresponding information that intersect the geometry. See Route Traffic below for specifications on the data available for each route.
4.1.9.1 Retrieve
/api/v1/rpc/routesbygeom?<PARAMS> routesByGeom (condition: {<PARAMS>} { nodes {
<FIELDS>
comprised of a geometry type and longitudes and latitudes that define the shape to compare all links against
“POLYGON
((-77.420 42.580, -
77.422 42.580, -
77.422 42.584, -
77.420 42.584, -
77.420 42.580))”
Table 11 - Routes by Geom Input Variable(s)
4.2 TRAFFIC DATA
4.2.1 Link Traffic
The traffic flowing through a single link.
4.2.1.1 Requesting Dynamic Link Data
The following query can be used to request link data from the ADX:
/api/v1/link_traffic?<PARAMS> query { linkTraffics (condition: {<PARAMS>} { nodes {
<FIELDS>
Links can be queried using any of the attributes in the table below:
id integer No Unique identifier for the link.
current_speed integer No Current speed of traffic (KPH) travel_time float No Current amount of time in seconds it would take for a driver to traverse the link congestion_level Integer Yes The estimated rate of congestion, represented as an integer between 1 and 4.
freeflow_speed Float Yes Free flow speed for the link in kilometers per hour.
last_update String No The last time the link was updated, as in, the last time new data was provided to potentially alter the amount of traffic displayed, in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm” status Integer No 1 or 0; Whether the link is active.
confidence_level String Yes Data quality score, from the traffic data provider.
Table 12 - Link Traffic Data Attributes
4.2.2 Link Traffic by Geometry
LinkTrafficByGeom allows the API user to specify a geometry comprised of latitudes and longitudes and returns all link traffic and their corresponding information that intersect the geometry. See Link above for specifications on the data available for each link.
4.2.2.1 Retrieve
/api/v1/rpc/linktrafficbygeom?<PARAMS> linktrafficbygeom (condition: {<PARAMS>} { nodes {
<FIELDS>
comprised of a geometry type and longitudes and latitudes that define the shape to compare all links against
“POLYGON
((-77.420 42.580, -
77.422 42.580, -
77.422 42.584, -
77.420 42.584, -
77.420 42.580))”
Table 13 - Link Traffic Data by Geom Input Variable(s)
4.2.3 Route Traffic
The traffic flowing through a single route.
4.2.3.1 Requesting dynamic route information.
/api/v1/route_traffic?<PARAMS> routeTraffics (condition: {<PARAMS>} { nodes {
<FIELDS>
Routes can be queried and retrieved via any of the parameters in the “Fields” category below.
id Integer No Identifier of the route that corresponds to this route traffic.
travel_time Integer Yes Current travel time in seconds.
travel_time_historic Integer Yes Average travel time of the past four weeks for the route.
jam_level Integer Yes Congestion level of the route.
last_update String Yes The last time the route was updated in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm” Table 14 - Route Traffic Data Attributes
4.2.4 Route Traffic by Geometry
RouteTrafficByGeom allows the API user to specify a geometry comprised of latitudes and longitudes and returns all route traffic and their corresponding information that intersect the geometry. See Route
Traffic above for specifications on the data available for each route.
4.2.4.1 Retrieve
/api/v1/rpc/routetrafficbygeom?<PARAMS> routetrafficbygeom (condition: {<PARAMS>} { nodes {
<FIELDS>
comprised of a geometry type and longitudes and latitudes that define the shape to compare all links against
“POLYGON
((-77.420 42.580, -
77.422 42.580, -
77.422 42.584, -
77.420 42.584, -
77.420 42.580))”
Table 15 - Route Traffic Data by Geom Input Variable(s)
4.3 EVENT DATA
4.3.1 Events
Event data can be accessed via the events API endpoint.
4.3.1.1 Requesting Event Data
/api/v1/events?<PARAMS> events (condition: {<PARAMS>} { nodes {
<FIELDS>
id String No Unique identifier for the event source_event_id String No Unique identifier for the event from ARCH owner_org String Yes The owner organization of the event reporting_org_name String Yes Name of the reporting organization for the event event_status String Yes Current status of the event event_category String Yes The category of the event event_type String Yes The type of the event create_time String No The create time of the event in the format
“yyyy-MM-dd'T’HH:mm:ss+hh.mm” last_update String No The last update of the event data in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm” close_time String Yes The close time of the event in the format
“yyyy-MM-dd'T’HH:mm:ss+hh.mm” facility_id Integer Yes ID of the facility corresponding to the event facility_name String Yes Name of the facility corresponding to the event direction_name String Yes The road direction that the event occurs on article String Yes Article corresponding to the event from_node_id Integer Yes The ID of the node where the event begins from_node_name String Yes The name of the node where the event begins to_node_id Integer Yes The ID of the node where the event ends to_node_name String Yes The name of the node where the event ends event_description String Yes Description of the event event_severity String Yes Severity of the event event_impact String Yes Impact of the event from_latitude Float Yes Latitude where the event begins from_longitude Float Yes Longitude where the event begins to_latitude Float Yes Latitude where the event ends to_longitude Float Yes Longitude where the event ends estimated_duration Integer Yes Estimated duration of the event extra_info String Yes Extra information about the event city String Yes City where the event occurs county String Yes County where the event occurs state String Yes State where the event occurs num_affected_lanes Integer Yes Number of lanes affected by the event num_total_lanes Integer Yes Number of total lanes where the event occurs lane_type String Yes Type of lane where the event occurs lane_status String Yes Status of the lanes where the event occurs start_date_time String Yes The start time of the event in the format
“yyyy-MM-dd'T’HH:mm:ss+hh.mm” end_date_time String Yes The end time of the event in the format
“yyyy-MM-dd'T’HH:mm:ss+hh.mm” update_count Integer Yes The number of updates to the event data geom Object Yes The geospatial representation of the event, formatted in GeoJSON facility_name_alt String Yes Alternate name of the facility where the event occurs roadway_condition String Yes Condition of the roadway where the event occurs weather_condition String Yes Condition of the weather where the event occurs event_owner String Yes Username of operator who last updated the event reported_date_time String Yes Timestamp specifying when the incident was reported in the format “yyyy-MM-dd'T’HH:mm:ss.SSSSSS”. All following timestamps have this format. This field will only be populated for incidents when the data is available.
created_date_time String Yes Timestamp specifying when the incident was created in the system. This field will only be populated for incidents when the data is available.
verified_date_time String Yes Timestamp specifying when the incident was verified. This field will only be populated for incidents when the data is available.
initial_response_date_time String Yes Timestamp specifying when the initial response occurred. This field will only be populated for incidents when the data is available. This field will only be populated for incidents when the data is available.
response_arrival_date_time String Yes Timestamp specifying when the responder(s) arrived at the incident. This field will only be populated for incidents when the data is available.
event_cleared_date_time String Yes Timestamp specifying when the event was cleared. This field will only be populated for incidents when the data is available.
response_depart_date_time String Yes Timestamp specifying when the responder(s) departed the incident location.
This field will only be populated for incidents when the data is available.
return_to_normal_date_time String Yes Timestamp specifying when the area of the incident was no longer affected. This field will only be populated for incidents when the data is available.
Table 16 - Events Data Attributes
4.3.2 Event Schedules
Event schedules correspond to events and provide further information about the schedule of the event.
Multiple event schedules can correspond to one event.
4.3.2.1 Requesting Event Schedules Data
/api/v1/eventschedules?<PARAMS> eventschedules (condition: {<PARAMS>} { nodes {
<FIELDS>
id Integer No Unique identifier for the event schedule.
event_id String No The ID of the event that the event schedule corresponds to.
schedule_start String No Timestamp specifying when the incident was reported in the format “yyyy-MM-dd'T’HH:mm:ss.SSSSSS”.
schedule_end String No Timestamp specifying when the incident was reported in the format “yyyy-MM-dd'T’HH:mm:ss.SSSSSS”.
schedule_days String No The days the event is scheduled to take place is_continuous Boolean No Boolean specifying whether the event is continuous total_lane_count Integer Yes The total number of lanes at the location of the event total_lanes_affected Integer Yes The total number of lanes affected by the event lane_type String Yes The type of lane affected lane_status String Yes The status of the lane last_update String No Timestamp specifying when the event schedule was last updated in the format
“yyyy-MM-dd'T’HH:mm:ss.SSSSSS”.
Table 17 - Event Schedules Data Attributes
4.3.3 Event Messages Current
Event messages current provides a list of all messages related to open events.
4.3.3.1 Requesting Current Event Messages Data
/api/v1/event_messages_current?<PARAMS> eventMessagesCurrent (condition: {<PARAMS>} { nodes {
<FIELDS>
event_id String No The ID of the event that the event message corresponds to.
message_id Integer No Sequential ID that specifies the order of messages corresponding to a given event.
event_message String No The full text of the message.
message_group String No The group for which the message is intended. Options:
- Other
- Data
- Exec Notification
- Manager
- Operator
- Public
- Private
- Road Ranger
- Supervisor last_update String No Timestamp specifying when the event message was last updated in the format
“yyyy-MM-dd'T’HH:mm:ss.SSSSSS”.
Table 18 - Event Messages Current Data Attributes
4.3.4 Event Messages Historic
Event messages historic provides a list of all messages published for closed events.
4.3.4.1 Requesting Historic Event Messages Data
/api/v1/event_messages_historic?<PARAMS> eventMessagesHistoric (condition: {<PARAMS>} { nodes {
<FIELDS>
event_id String No The ID of the event that the event message corresponds to.
message_id Integer No Sequential ID that specifies the order of messages corresponding to a given event.
event_message String No The full text of the message.
message_group String No The group for which the message is intended. Options:
- Other
- Data
- Exec Notification
- Manager
- Operator
- Public
- Private
- Road Ranger
- Supervisor last_update String No Timestamp specifying when the event message was last updated in the format “yyyy-MM-dd'T’HH:mm:ss.SSSSSS”.
Table 19 - Event Messages Historic Data Attributes
4.4 DEVICE DATA
4.4.1 Devices
Static device data is available via the devices API endpoint.
4.4.1.1 Requesting Device Data
/api/v1/devices?<PARAMS> devices (condition: {<PARAMS>} { nodes {
<FIELDS>
id Integer No Unique identifier for the device.
device_type String No The type of the device.
device_subtype String No The subtype of the device.
name String Yes Name of the device.
description String Yes Description of the device.
last_update String No Timestamp specifying when the device information was last updated in the format
“yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
geom Object Yes The geospatial representation of the device location, formatted in GeoJSON agency_name String Yes The name of the agency corresponding to the device native_device_id String Yes Unique source identifier for the device roadway String Yes The roadway that the device is located on.
direction String Yes The direction of the roadway where the device is located.
region_name String Yes The name of the region where the device is located Table 20 - Devices Data Attributes
4.4.2 CCTV
Current and historical data for each CCTV camera is available via the CCTV API endpoint.
4.4.2.1 Requesting CCTV Data
/api/v1/cctv?<PARAMS> cctv (condition: {<PARAMS>} { nodes {
<FIELDS>
id Integer No Unique identifier for the CCTV snapshot_url String Yes URL to the current snapshot for the CCTV video_url String Yes URL to the video from the CCTV is_blocked Boolean No Whether the CCTV is blocked status String No Status of the CCTV monitor_id String Yes ID of the CCTV monitor associated with a particular camera last_update String Yes Timestamp specifying when the CCTV information was last updated in the format
“yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
Table 21 - CCTV Data Attributes
4.4.3 VMS
VMS (variable messaging sign) information is available via the vms API endpoint.
4.4.3.1 Requesting VMS Data
/api/v1/vms?<PARAMS> vms (condition: {<PARAMS>} { nodes {
<FIELDS>
Attribute Type Nullable Description id Integer No Unique identifier for the VMS native_device_id String Yes Unique source identifier for the device message String Yes Message displayed on the VMS status String No Current status of the VMS priority_id Integer Yes Priority ID from ARCH remote_msg_id String Yes Remote message ID from ARCH msg_position Integer Yes Message position from ARCH scheduled_end String Yes Scheduled end time of the message from
ARCH
is_blocked Boolean Yes Blocked status last_update String Yes Timestamp specifying when the VMS information was last updated in the format
“yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
Table 22 - VMS Data Attributes
4.4.4 Traffic Monitoring Stations Inventory
hiTThe Traffic Monitoring Station (TMS) inventory is available via the tms_inventory API endpoint. The terminology used for the TMS data attributes follows the UDOT TMS Naming Convention as depicted in
Figure 1.
4.4.4.1 Requesting TMS Inventory
/api/v1/tms_inventory?<PARAMS> tmsInventory (condition: {<PARAMS>} { nodes {
<FIELDS>
"source_controller_id" String No Controller identifier as defined in ARCH
"controller_name" String Yes Controller name as defined in ARCH
"controller_description" String Yes Description of the controller
"controller_type" String Yes Controller type as defined in ARCH
Figure 1 - USDOT TMS Naming Convention
"controller_manufacturer
String Yes Controller manufacturer as defined in ARCH
"controller_model" String Yes Controller model as defined in ARCH
"firmware_version" String Yes Controller firmware version as defined in ARCH
"geom" Object Yes Geospatial representation of the station location, formatted in GeoJSON containing long/lat
"detector_id" Integer Yes Lane identifier as defined in ARCH
"detector_name" String Yes Lane name as defined in ARCH
"detector_type" String Yes
Lane type of the detector. The lane type abbreviation provided by ARCH mapped to the possible APInoutputs (and their descriptions) include the following:
CNTL - Center Lane RTLN - Right Turning Lanes LTLN - Left Turning Lanes RXRP - Right Exit Ramp (off-ramp lanes) RNTP - Right Entrance Ramp (on-ramp lanes) HSHL - Hard Shoulder CNFF - Connecting Lanes (freeway-to-freeway lanes) HOV - HOV Lanes SRVC - Service Road (conventional highway lanes) HWGP - Highways (general purpose lanes) OFC - Off Connecting Lanes (freeway-to-freeway lanes)
"detection_type" String Yes Detection type as defined in ARCH (Radar, Loop, Lidar (future), TRTL (future))
"lane_count" Integer Yes Number of lanes at the controller
"lane_number" Integer Yes Lane number as defined in ARCH
"link_id" String Yes Link identifier as defined in ARCH
"roadway" String Yes Roadway name as defined in ARCH
"milepost" String Yes Milepost of the controller as defined in ARCH
"direction_name" String Yes
Direction of the lane as defined in ARCH. Possible outputs include the following:
NB
SB
EB
WB
"region_name" String Yes Region of the lane
"polling_interval_in_sec onds"
Integer Yes Polling interval as definied in ARCH. This refers to the frequency at which the detector information is polled from the device in seconds
"conventional_highway" Boolea n
Yes Boolean specifying whether the location is on a conventional highway, as definited in ARCH
"detector_geom" Object Yes The geospatial representation of the controller location, formatted in GeoJSON containing long/lat
"last_update" String No Timestamp specifying when the controller information was last updated in the format “yyyy-MM-dd'T’HH
Table 23 - TMS Inventory Data Attributes
4.4.5 Current Traffic Monitoring Stations Data
Dynamic TMS data is available via the tms_data_current API endpoint. Users will be able to retrieve the most recent data point for each detector.
4.4.5.1 Requesting Current TMS Data
/api/v1/tms_data_current?<PARAMS> tmsDataCurrent (condition: {<PARAMS>} { nodes {
<FIELDS>
source_controller_id String No Identifier for the device from ARCH detector_id Integer Yes The lane identifier as defined in ARCH speed_in_mph Integer Yes Vehicle speed in the specified lane volume Integer Yes Traffic volume at the controller in the specified lane occupancy Float Yes Traffic occupancy at the controller in the specified lane vehicle_class_info String Yes String in the format "bin1: 2, bin2: 2, bin3:
2,…" with 8 numbered bins and a count for each bin. Details the number of each vehicle class that passed by the detector in the specified lane during the measurement window.
lane_number Integer Yes The Lane Number as defined in ARCH direction_name String Yes Direction of the lane - possible values (NB, SB, EB, WB ) link_id String Yes The link identifier as defined in ARCH polling_interval_in_ seconds
Integer Yes Polling interval refers to the frequency at which the detector information is polled from the device in seconds.
status String Yes Status of the detector last_update String Yes Timestamp specifying when the controller data was recorded in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
Table 24 - TMS Data Current Data Attributes
4.4.6 Historic Traffic Monitoring Stations Data
Historic TMS data is available via the tms_data_historic API endpoint. Users will be able to retrieve historic TMS data filtered by date/time.
4.4.6.1 Requesting Historic TMS Data
/api/v1/tms_data_historic?<PARAMS> tmsDataHistoric (condition: {<PARAMS>} { nodes {
<FIELDS>
source_controller_id String No Identifier for the device from ARCH detector_id Integer Yes The Lane identifier as defined in ARCH speed_in_mph Integer Yes Vehicle speed in the specified lane volume Integer Yes Traffic volume at the controller in the specified lane occupancy Float Yes Traffic occupancy at the controller in the specified lane vehicle_class_info String Yes String in the format "bin1: 2, bin2: 2, bin3: 2,…" with 8 numbered bins and a count for each bin. Details the number of each vehicle class that passed by the detector in the specified lane during the measurement window.
lane_number Integer Yes The Lane Number as defined in ARCH link_id String Yes The link identifier as defined in ARCH direction_name String Yes Direction of the lane - possible values (NB, SB, EB, WB ) polling_interval_in_ seconds
Integer Yes Polling interval refers to the frequency at which the detector information is polled from the device in seconds.
status String Yes Status of the detector last_update String Yes Timestamp specifying when the controller data was recorded in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
Table 25 - TMS Data Historic Data Attributes
4.5 VEHICLE DATA
4.5.1 Vehicles
Static vehicle data is available for each vehicle via the vehicles endpoint.
4.5.1.1 Requesting Vehicle Data
/api/v1/vehicles?<PARAMS> vehicles (condition: {<PARAMS>} { nodes {
<FIELDS>
id Integer No Unique identifier for the vehicle.
vehicle_type String No The type of the vehicle.
owner_org String No ID specifying where the vehicle data comes from.
description String Yes Description of the vehicle.
vehicle_id_num String Yes ID number for the vehicle source_vehicle_id String Yes Source ID number for the vehicle last_update String No Timestamp specifying when the vehicle information was last updated in the format
“yyyy-MM-dd'T’HH:mm:ss.SSS”.
Table 26 - Vehicle Data Attributes
4.5.2 Vehicle Positions
Vehicle position data is periodically recorded for each vehicle and is available via the vehicle positions
API endpoint. Vehicle positions are published where the last update is within the last 30 minutes and the speed is greater than 10 miles per hour.
4.5.2.1 Requesting Vehicle Position Data
/api/v1/vehicle_positions?<PARAMS> vehiclePositions (condition: {<PARAMS>} { nodes {
<FIELDS>
Attribute Type Nullable Description id Integer No Unique identifier for the vehicle position data.
vehicle_id Integer No ID of the vehicle that the position data corresponds to.
source_vehicle_id String Yes Source ID number for the vehicle speed_in_kph Integer Yes Speed in kilometers per hour of the vehicle heading Integer Yes Degrees clockwise from North that the vehicle was traveling in odometer Float Yes Odometer reading of the vehicle geom Object Yes The geospatial representation of the vehicle location, as a point formatted in GeoJSON last_update String No Timestamp specifying when the vehicle position information was last updated in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
Table 27 - Vehicle Positions Data Attributes
4.6 WEATHER DATA
4.6.1 Weather
Weather forecast data can be accessed via the weather API endpoint.
4.6.1.1 Requesting Weather Data
/api/v1/weather?<PARAMS> weather (condition: {<PARAMS>} { nodes {
<FIELDS>
id Integer No Unique identifier for the weather data source_id String Yes ID corresponding to the source of the weather data location_name String Yes The location of the weather data period_name String Yes The name of the period for the weather data start_time String Yes Timestamp specifying the start time of the weather in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
end_time String Yes Timestamp specifying the end time of the weather in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
temperature Integer Yes The forecasted temperature in degrees
Fahrenheit wind_speed String Yes The forecasted wind speed wind_direction String Yes The forecasted wind direction icon String Yes The URL to the icon for the weather short_forecast String Yes Abbreviated forecast detailed_forecast String Yes Detailed forecast last_update String Yes Timestamp specifying the last update of the weather in the format “yyyy-MM-dd'T’HH:mm:ss.SSSSSS”.
Table 28 - Weather Data Attributes
4.6.2 Weather Alerts
Weather alerts are specific weather events that have merited an associated alert. Weather alerts data can be accessed via the weatheralert API endpoint.
4.6.2.1 Requesting Weather Alert Data
/api/v1/weatheralert?<PARAMS> weatheralert (condition: {<PARAMS>} { nodes {
<FIELDS>
id Integer No Unique identifier for the weather alert source_id String Yes ID corresponding to the source of the weather alert location_name String Yes The location of the weather alert effective_date_time String No Timestamp specifying the start time of the weather alert in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
expire_date_time String No Timestamp specifying the expiration time of the weather alert in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
end_date_time String No Timestamp specifying the end time of the weather alert in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
local_status String No Local status of the weather alert alert_status String Yes Current status of the weather alert message_type String Yes The type of message of the weather alert severity String Yes Severity of the weather alert urgency String Yes Urgency of the weather alert event_type String Yes The type of event corresponding to the weather alert headline String Yes Headline of the weather alert description String Yes Longer text description of the weather alert instruction String Yes Instructions accompanying the weather alert last_update String No Timestamp specifying the last update of the weather alert in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
Table 29 - Weather Alert Data Attributes
4.6.3 Weather Hourly
Hourly weather forecast data is available via the weatherhourly API endpoint.
4.6.3.1 Requesting Weather Hourly Data
/api/v1/weatherhourly?<PARAMS> weatherhourly (condition: {<PARAMS>} { nodes {
<FIELDS>
id Integer No Unique identifier for the hourly weather data source_id String Yes ID corresponding to the source of the weather data location_name String Yes ID corresponding to the location of the weather data period_name String Yes The name of the period for the weather data start_time String Yes Timestamp specifying the start time of the weather in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
end_time String Yes Timestamp specifying the end time of the weather in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
temperature Integer Yes The forecasted temperature in degrees
Fahrenheit wind_speed String Yes The forecasted wind speed wind_direction String Yes The forecasted wind direction icon String Yes The URL to the icon short_forecast String Yes Abbreviated forecast detailed_forecast String Yes Detailed forecast last_update String Yes Timestamp specifying the last update of the weather in the format “yyyy-MM-dd'T’HH:mm:ss.SSSSSS”.
Table 30 - Weather Hourly Data Attributes
4.7 RWIS DATA
4.7.1 RWIS Surface Observations
Dynamic RWIS surface observation data.
4.7.1.1 Requesting RWIS Surface Data
/api/v1/rwissurface?<PARAMS> rwissurface (condition: {<PARAMS>} { nodes {
<FIELDS>
id Integer No Unique identifier for the RWIS surface observation.
origin_id Integer No Unique identifier for the RWIS surface device.
rwis_id Integer No Unique identifier for the RWIS location sample_time String Yes Timestamp specifying when the RWIS measurements were taken in the format
“yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
surface_status Integer Yes Surface status interpreted from the equipment-specific surface status surface_sensor_error Integer Yes Coded error value provided by equipment surface_temp Float Yes Surface temperature (F) interpreted from either RoadTemp, dstRoadTemp, or
IceRoadTemp surface_salinity Float Yes Surface salinity (%) - amount of salt on surface surface_freeze_point Float Yes surface freezing point (F) surface_water_depth Float Yes surface water depth (mm) sub_surface_temp Float Yes sub-surface temperature (F) surface_ice_depth Float Yes surface ice depth (mm) surface_snow_depth Float Yes surface snow depth (mm) air_temp Float Yes air temperature (F) relative_humidity Integer Yes relative humidity (%) dew_point Float Yes dew point (F) surface_status_text String Yes normallilzed road status text, interpreted from either RoadStatusText, dscRoadStatusText, or
IceAvgCondCode grip Float Yes coefficient of friction, interpreted from dscLevelOfGrip or IceGrip road_status Integer Yes road puck sensor enumerated value road_status_text String Yes road puck sensor status description road_temp Float Yes road puck road temperature (F) dst_road_temp Float Yes Vaisala non-invasive sensor. surface temperature (F) dst_input_voltage Float Yes Vaisala non-invasive sensor. input voltage
(volts) dst_hardware_status Integer Yes Vaisala non-invasive sensor. hardware status enumerated value dsc_surface_status Integer Yes Vaisala non-invasive enumerated value dsc_road_status_text String Yes Vaisala non-invasive road status description dsc_level_of_grip Float Yes Vaisala non-invasive coefficient of friction ice_road_temp Float Yes IceSight non-invasive sensor. road temperature
(F) ice_cur_cond_index Integer Yes IceSight non-invasive sensor. current condition index ice_avg_cond_index Integer Yes Icesight non-invasive sensor. average condition index ice_cur_cond_code String Yes IceSight non-invasive sensor. current condition code ice_avg_cond_code String Yes IceSight non-invasive sensor. average condition code ice_cur_fric_index Integer Yes IceSight non-invasive sensor. current friction index ice_avg_fric_index Integer Yes IceSight non-invasive sensor. average friction index ice_grip String Yes IceSight non-invasive sensor. coefficient of friction ice_x_value Integer Yes IceSight non-invasive sensor laser 1 power return ice_y_value Integer Yes IceSight non-invasive sensor. laser 2 power return ice_yx_ratio Float Yes IceSight non-invasive sensor. laser 1 / laser 2 ratio ice_lens Integer Yes IceSight non-invasive sensor. enumeration specifying if lens is clean Table 31 - RWIS Surface Observations Data Attributes
4.7.2 RWIS Atmospheric Observations
Dynamic RWIS atmospheric observation data.
4.7.2.1 Requesting RWIS Atmospheric Data
/api/v1/rwisatmo?<PARAMS> rwisatmo (condition: {<PARAMS>} { nodes {
<FIELDS>
Attribute Type Nullable Description id Integer No Unique identifier for the RWIS atmospheric observation.
origin_id Integer No Unique identifier for the RWIS atmospheric device.
rwis_id Integer No RWIS device identifier sample_time String Yes timestamp when sample was recorded air_temp Integer Yes air temperature (F) relative_humidity Integer Yes relative humidity (%) dew_point Float Yes dew point (F) wind_direction Float Yes wind direction (degrees) wind_direction_label String Yes wind direction N, NE, E, SE, S, SW, W, NW wind_speed_avg Float Yes average wind speed (mph) wind_speed_gust Float Yes maximum wind speed gust for sample period
(mph) wind_speed_gust_timestamp String Yes timestamp of the maximum wind speed gust for period pressure Float Yes barometric pressure (millibars) – not currently used snow_depth Float Yes snow depth (in) solar_radiation Float Yes solar radiation (watts/m^2) visibility Integer Yes visibility (miles) precip_type String Yes is there precipitation (yes/no) battery_voltage Float Yes battery voltage (volts) snow_fall_rate Float Yes snow fall rate (in/hr) wrwi Float Yes internal UDOT metric rain_total Float Yes rain total (in) snow_interval_depth Float Yes snow interval depth (in) sii Float Yes internal UDOT metric performance_metric Integer Yes internal UDOT metric
Table 32 - RWIS Atmospheric Observations Data Attributes
4.7.3 Mountain Pass
Mountain Pass inventory data.
4.7.3.1 Requesting Vehicle Data
/api/v1/mountainpass?<PARAMS> mountainpass (condition: {<PARAMS>} { nodes {
<FIELDS>
Attribute Type Nullable Description id Integer No Unique identifier for the mountain pass origin_id Integer No Unique identifier for the mountain pass elevation Integer Yes Elevation (in feet) of the mountain pass name String Yes Name of the mountain pass route String Yes Name of the route associated with the mountain pass rwis_ids String Yes List of ids of associated RWIS stations geom Object Yes The geospatial representation of the mountain pass location, as a point formatted in GeoJSON date_created String Yes Timestamp specifying when the mountain pass was created in the format “yyyy-MM-dd'T’HH:mm:ss+hh.mm”.
last_update String Yes Timestamp specifying when the mountain pass was last updated in the format “yyyy-
MM-dd'T’HH:mm:ss+hh.mm”.
Table 33 - Mountain Pass Data Attributes
File details come from the government source that posted it. Updated .