Traffic incident data: what each record holds and how to use it
A closure, roadworks or other incident comes with its kind, street, district, position and an ID. What each field means, how precise it is, and what it cannot tell you.
A traffic incident record in xMap Flows holds what is wrong, where, and an ID that stays the same while it lasts: its kind (road closure, roadworks or another incident), a name made from the kind and the street, the street and district, the city it was found in, a position good to about 150 metres with its accuracy in metres, and a small icon as online maps draw it. It does not hold a cause, a start or end time, or how many lanes are affected.
This article is a reference for anyone building on incident data: analysts, dispatch teams, newsrooms writing traffic bulletins, and developers sending incidents to their own systems. It goes through each field, explains the two shapes the data can come in, shows how one search looks in practice, and lists the misreadings that cause trouble later.
Two shapes: a list of incidents, or counts on your places
The Traffic incidents block reads incidents live from online maps. How you set its Where decides what comes out:
- An area, a list of cities or a circle around a point: one item per incident found, with all the fields below. A city is searched within about 12 km of its centre.
- Around each incoming place: your own places go on, each with two fields added, incidents_nearby (how many are within the radius) and nearest_incident (the closest one's kind and distance, such as "Road closure, 640 m").
The first shape suits a newsroom or a city roads team that wants every incident. The second suits a business that only cares about incidents near its depots, shops or appointments.
Each field, and how far to trust it
| Field | What it holds | Good to know |
|---|---|---|
| name | The kind and, when known, the street | Falls back to the kind alone after the first 40 incidents a run |
| category | Road closure, Roadworks or Incident | Accidents are reported as road closures for now |
| street, district | Where it is, worked out from its position | Added to the first 40 incidents a run |
| city | The city or area it was found in | The area you searched, not an address |
| lat, lng | Its position | Good to about 150 m |
| accuracy_m | How precise the position is, in metres | Use it before drawing street-level conclusions |
| incident_id | Its own ID | The same while the incident lasts |
| image | Its icon as the map draws it | Shown on maps and in emails, left out of downloads |
The fields of one incident, from the Traffic incidents block's own description.
One search, step by step
Here is a made-up example. A traffic desk in Buenos Aires searches the city at 07:00. The block searches the city in parts, centre first, because a zoomed-out map hides most incident icons; a large drawn area is cut into parts of about 24 km and up to 8 parts are searched in a run, and the step says when an area was only partly covered.
Say the search returns 26 incidents: 15 roadworks, 9 road closures and 2 marked Incident. All 26 get a street and district name, since that is under the 40-a-run limit. The desk sorts them by district, drops those already announced yesterday by matching their IDs, and reads out the new ones. At 07:30 the same search runs again, and only incidents with a new ID come through.
Misreadings to avoid
- Counting accidents. Accidents arrive as road closures, so the data cannot give a reliable count of accidents on its own. Do not report it as one.
- Treating the position as an address. 150 m can be the next block. Say "near" a street, and use the street name the record gives.
- Inferring how long it lasts from one look. Only repeated searches tell you an incident is long-running. Keep the IDs you have seen and the date you first saw each.
- One huge area. Several smaller areas cover a city more completely than one vast drawn shape, because each search has a limit on parts.
- Expecting traffic volume. An incident says something is wrong at a place, not how slow the traffic is around it. For speeds and a jam factor, use Traffic Flow on the same places.
Turning the data into something people read
An AI employee can do the searching and the remembering. A common shape:
- Schedule: every 30 minutes during the hours that matter.
- Area of interest: the city, or several districts drawn on the map.
- Traffic incidents: closures and roadworks in the area.
- Only new: each incident once, by its ID.
- Show on a map and Email: the new incidents, each with its icon, street and district.
What arrives is a short email only when something new has appeared, with a map where each incident shows its own icon. For a business, swap the area for your own places from My data and send only the places with an incident nearby. Templates built this way: Road closures in my city, Traffic bulletin for the radio, every 30 minutes and Roadworks and closures near my projects.
Questions
Why are accidents shown as road closures?
The map's icons are read as they are drawn, and accidents currently come back under the road closure kind. A kind with no matching icon comes back as Incident.
How precise is an incident's position?
About 150 metres. Each record also carries accuracy_m, the precision in metres, so you can check before drawing street-level conclusions.
Does an incident keep the same ID?
Yes, while it lasts. That is how Only new knows not to send it again on the next run.
Can I download incidents to a spreadsheet?
Yes. The results download as CSV or GeoJSON, without the icons, or each run can add rows to a sheet.