The real-time speed information provided by INRIX is used in Optima. In particular, the INRIX speed data handling involves:
- Obtaining raw speed data from the INRIX API
-
Reading received raw data
- Filter data to consider only data relative to the Optima reference network
- Decode OpenLR locations
- Harmonizing the parsed data
Obtaining raw speed data from INRIX
The request sent INRIX to obtain the raw speed data every minute is:
https://segment-api.inrix.com/v1/segments/speed?box=47.77577|-122.207249,47.743362|-122.16227&accesstoken={token}&Resolution=100&RoadSegmentType=xds&units=1
| Parameter | Description |
|---|---|
|
box |
Parameters used to specify a bounding box of the returned data. |
|
Resolution |
Used to limit the length of the XDS (OpenLR line location reference). If possible the returned segments are divided into subsegments of the length specified by the resolution parameter. Quote from the INRIX API documentation: “If 'resolution' is specified, the speed of subsegment is returned. The subsegment is specified in terms of offsets. The length of the subsegment will be based on the resolution specified. The default is 0, which means 'full resolution' or one section per segment.” |
|
RoadSegmentType=xds |
Quote from the INRIX API documentation: “This indicates the type of Segment to return. If 'RoadSegmentType' is not specified, INRIX XD Segments (XDS) are returned.” |
|
units |
Quote from the INRIX API documentation: “Use 0 for English units, 1 for metric. The default is 0.” |
|
accesstoken={token} |
Value of the current security token used to authenticate the request. Quote from the INRIX API documentation: “A valid authorization token returned in response to a GetSecurityToken request.” |
Example response:
{
"copyright": "Copyright INRIX Inc. 2023",
"versionNumber": "v1",
"createdDate": "2023-08-09T17:15:24.5925147Z",
"responseId": "13d6194a-e8de-438a-8db5-865fa97404a3",
"result": {
"unit": "KPH",
"segmentspeeds": [
{
"time": "2023-08-09T17:15:00Z",
"segments": [
{
"code": "1626720471",
"type": "XDS",
"speed": 80,
"reference": 113,
"score": "30",
"c-value": "85",
"subSegments": [
{
"speed": 95,
"startoffset": 0,
"endoffset": 303
},
{
"speed": 93,
"startoffset": 303,
"endoffset": 404
},
{
"speed": 87,
"startoffset": 404,
"endoffset": 505
}
]
},
{
"code": "170445410",
"type": "XDS",
"speed": 26,
"reference": 38,
"score": "30",
"c-value": "85"
},
{
"code": "169655995",
"type": "XDS",
"speed": 18,
"reference": 58,
"score": "30",
"c-value": "85"
}
]
}
]
}
}
| Parameter | Description |
|---|---|
| speed | Speed value Given in km/h because Units = 1 |
| c-value | Data reliability Validity: [0, 100] |
| reference | INRIX free flow speed |
| score=30 | 30 = real-time time data for this specific segment 20 = based on real-time data across multiple segments or based on a combination of expected and real-time data 10 = based primarily on historical data or on road reference speeds |
Reading received raw data
The imported raw data is parsed to decode the XD Segments (XDS) and to refer them to the Optima reference network.
After applying a filter on the received data to consider only the matched XDS, for each matched XDS the speed information is assigned to the streets included in the XDS. The speed information is given according to the subsegments.
Example case:
{
"code": "1626720471",
"type": "XDS",
"speed": 80,
"reference": 113,
"score": "30",
"c-value": "85",
"subSegments": [
{
"speed": 95,
"startoffset": 0,
"endoffset": 303
},
{
"speed": 93,
"startoffset": 303,
"endoffset": 404
},
{
"speed": 87,
"startoffset": 404,
"endoffset": 505
}
]
}
It can happen that the subsegmentation does not cover all XDS (see second and third subsegment of the example above). In this case, the gaps are filled with dummy subsegments with the speed set equal to the value of the attribute speed of the XML element Segment.
The next image illustrates the XDS subsegmentation.
To set the speed on the streets, the following steps are performed:
The total “XDS length” is computed as:
| Parameter | Description |
|---|---|
| T | Total travel times in minutes (value of the attribute travelTimeMinutes of the element Segment) |
| Vs | Segment speed (value of the attribute speed of the element Segment) |
If there is a hole in the segmentation (the first offset value of the current subsegment differs from the last offset value of the previous one), a dummy subsegment is created with a speed equal to the value of the entire segment.
The sequence S defined by the concatenation of each street mapped to the XDS is considered along with the relative positions defined by the mapping, with length:
| Parameter | Description |
|---|---|
| li | Length of the i-th street |
| fsi | “From” relative position value defined by the XDS street (OpenLR) mapping to the i-th street |
| tsi | “To” relative position value defined by the XDS street (OpenLR) mapping to the i-th street |
| n | Number of streets mapped to the XDS |
For each subsegment, the relative positions on the XDS defined by the subsegment are computed:
| Parameter | Description |
|---|---|
| offsetAi | First offset value read in the XML attribute offset of the i-th subsegment element |
| offsetBi | Second offset value read in the XML attribute offset of the i-th subsegment element |
| fxi | “From” relative position value on the XDS defined by the i-th subsegment |
| txi | “To” relative position value on the XDS defined by the i-th subsegment |
fxi and txi are referred to S in order to locate how many streets are mapped by each subsegment and with what relative positions.
Considering the subsegment SD2 of the example, we have:
SD2 is mapped to:
- Sr3 from to 1 ( is the “From” relative position on Sr3 defined by SD2.)
- Sr4 from 0 to 1
- Sr5 from 0 to ( is the “To” relative position on Sr5 defined by SD2.)
To each street touched by the subsegment (real or dummy) is assigned the subsegment speed and a reliability value computed as:
| Parameter | Description |
|---|---|
| Vi | Subsegment speed |
| Vs | Segment speed |
| “From” relative position on the j-th street defined by the i-th subsegment | |
| “To” relative position on the j-th street defined by the i-th subsegment |
The speed (with its reliability) and the relative position assigned to each street is used to create the Optima object called TrafficState.
All the produced traffic states are written to the Optima database into the tables:
- TRAFFICSTATE_RLTM – contains only the last arrived bunch of data (→ Real-time traffic data)
- TRAFFICSTATE – contains all arrived data (→ Real-time traffic data)
The data written to the tables is as follows:
| Attribute | Value |
|---|---|
| CDAT | Value of the XML attributes createdDate of the XML element Inrix |
| FPRG | |
| TPRG | |
| RELIABILITY | cvalue * (tprg - fprg) |
| METADATA | "{"reference":x,"score":y,"cvalue":z}"; with:
|
Harmonizing the parsed data
The raw real-time traffic information can be elaborated by Harmonizer (→ Harmonizer). Harmonizer provides a single speed value on each street that has at least some raw real-time speed data.
According to its job schedule, Harmonizer accomplishes the following steps:
Harmonizer reads all data contained in the TRAFFICSTATE table that is not older than x minutes (according to the CDAT attribute). The parameter x is defined in the Harmonizer configuration file.
For each street, the speed value is computed as:
| Parameter | Description |
|---|---|
| Vsi | Speed value on the s-th street obtained by the i-th (real or dummy) subsegment that touches the street |
| ri | Reliability of Vsi |
| m | Number of the speed information on the s-th street |
The speed computed on each street with the above formula is used to create an Optima object called Tsta.
All produced Tsta are written to the Optima database into the tables:
- TSTA_RLTM – contains only the last produced speeds (→ Real-time traffic data)
- TSTA – contains all the produced data (→ Real-time traffic data)
The data written to the tables is as follows:
| Attribute | Value |
|---|---|
| CDAT | Harmonizer running timestamp |
| FDAT | CDAT – x min |
| LDAT | CDAT |