How to detect new, updated, and expired incidents comparing to previous update from HERE TrafficML 2.4 Incidents

SYMPTOMS / TRIGGERS

You may need this article if:

You are consuming the HERE Traffic XML Incident feed and want to avoid reprocessing the entire snapshot every cycle
You need to identify which incidents are new, which have been updated, and which have expired since the last pull
You are unsure how ORIGINAL_TRAFFIC_ITEM_ID and TRAFFIC_ITEM_ID relate to each other
Your downstream system is treating unchanged incidents as updates, causing unnecessary processing load
You see duplicate incident records because your comparison logic does not account for the snapshot-based delivery model

ANSWER

Compare ORIGINAL_TRAFFIC_ITEM_ID (constant for the incident's lifetime) and TRAFFIC_ITEM_ID (changes on every update) between your previous and current snapshots.

If ORIGINAL_TRAFFIC_ITEM_ID disappears → the incident expired. If both IDs match the previous cycle → no change.
If ORIGINAL_TRAFFIC_ITEM_ID persists but TRAFFIC_ITEM_ID differs → the incident was updated.
A new ORIGINAL_TRAFFIC_ITEM_ID not present in the previous snapshot → new incident.DETAILED EXPLANATION

DETAILED EXPLANATION

The HERE Traffic Feed delivers a full snapshot of all currently active incidents on every update cycle. It does not provide a delta or change log. To determine what changed, you must compare consecutive snapshots using two fields:

| Field | Behavior |
| --- | --- |
| ORIGINAL_TRAFFIC_ITEM_ID | Assigned when the incident is first created. Remains constant for the entire lifetime of the incident. |
| TRAFFIC_ITEM_ID | Assigned a new value each time the incident is updated (e.g., severity change, location refinement, time extension). |

Cycle-to-cycle comparison logic:

| Condition | Meaning | Action |
| --- | --- | --- |
| ORIGINAL_TRAFFIC_ITEM_ID exists in previous snapshot but is missing from current snapshot | Incident has expired | Remove from your system |
| ORIGINAL_TRAFFIC_ITEM_ID exists in both snapshots AND TRAFFIC_ITEM_ID is identical | Incident is still active but unchanged | No action required |
| ORIGINAL_TRAFFIC_ITEM_ID exists in both snapshots AND TRAFFIC_ITEM_ID differs | Incident has been updated | Re-process / update in your system |
| ORIGINAL_TRAFFIC_ITEM_ID in current snapshot not found in previous snapshot | New incident | Ingest as new |

STEP-BY-STEP IMPLEMENTATION

1. Store the full set of ORIGINAL_TRAFFIC_ITEM_ID → TRAFFIC_ITEM_ID pairs from each snapshot you receive.
2. On receiving a new snapshot, iterate through all items and look up each ORIGINAL_TRAFFIC_ITEM_ID in your stored previous set.
3. Apply the comparison logic from the table above to classify each incident as new, updated, unchanged, or expired.
4. For expired incidents (present in previous, absent in current), mark them as resolved/removed in your downstream system.
5. Replace your stored snapshot data with the current snapshot for the next cycle.

EXAMPLE FILES

Current View Example: IncidentA0114_04292020_1157PST.xml
Previous View Example: IncidentA0114_04282020_1157PST.xml