Delta updates reduce
getmessages response size by sending only changed and new traffic events after the first request.
Delta update calculation rules
When successive intersecting proximity only or corridor only searches are requested the last result will have items from all previous requests filtered out.
Scenario: A user requests traffic for the first Proximity area (Prox #1) and gets all events (no Delta at this point). Then the user requests traffic for the second Proximity area (Prox #2), which is intersecting with the first area, and gets only the delta update as events from intersecting area were filtered out. Then the user requests traffic for the third Proximity area (Prox #3), which is intersecting with both previously used areas, and gets only the delta update as events from both intersecting areas were filtered out. The same logic applies for any sequential corridor searches.
When successive intersecting searches are requested while changing the type of search (Proximity-to-Corridor-to-Proximity or Corridor-to-Proximity-to-Corridor), the last result will also have items from previous search of the same type filtered out.
Scenario: A user requests traffic for the first area (Prox #1) and gets all events (no Delta at this point). Then the user requests traffic for a corridor area intersecting with the first area (Corr #2) and gets only the delta update as events from intersecting area were filtered out. Then user requests traffic again for the proximity area intersecting with both previously used areas (Prox #3) and gets only the delta update as events from both intersecting areas were filtered out.
Delta Update response size sample
The following example shows the size difference when driving approximately 300km in Germany, first performing a proximity search, and then using route corridor search for incidents and traffic flow during the drive.
getmessages request is for a 10km proximity search, subsequent
getmessages requests are for route-corridor searches with way points for the whole route. A new
getmessages request is sent every 2 minutes, from the position where the car would be located for the remaining route.
In total, 152
getmessages requests are sent, and as many responses returned by the TPEG service. The blue line shows the
getmessages response size when delta updates are used. The graph also shows the size of the non-delta responses using compressed TrafficML (TML) and binary TPEG format.
Delta update thresholds
Traffic Event Compact (TEC): when any incident parameter changes, the incident is updated in the next
getmessages response if the incident is still within the search area.
Delta for flow (TFP): Values of the following parameters will be taken into consideration for threshold calculations. By default, Traffic TPEG API uses units defined in the feeds.
|Parameter||Threshold [units defined in the real time feeds]|
|Average Speed [SP]|| |
|Free Flow [FF]|| |
|Jam Factor [JF]|| |
|Confidence [CN]|| |
|Length of TMC (sub-segement) [LE]|| |
To always receive full traffic updates instead of delta updates, set
TimeOut=0 in the
initsession request. If
TimeOut is greater than zero, the only way to get a full traffic update before that duration is to start a new session.