Project: interactive traffic incident dashboard with selectors and linked charts

One screen for a busy morning. It's 7:40 on a Monday morning. A crash on the ring road is backing up traffic, two stalled trucks are blocking a bridge, and the traffic operations supervisor has three phones ringing at once. She doesn't need a report tomorrow. She needs one screen that shows where the incidents are, what kind they are, and how many are still open, right now. In this project lesson you'll build that screen: an interactive traffic incident dashboard where the selectors, the map and the charts all respond to each other. It brings together everything from this course, and by the end you'll have a working dashboard you could hand to a real operations team.

What you will learn. Here's what you'll be able to do by the end of this lesson. First, you'll plan the dashboard before you build it: the incident data, the fields you need, and which elements go where. Second, you'll wire the interactions: a category selector and a date selector in the header, map actions that react when the map moves, and selection actions so a click on a chart filters everything else. Third, you'll make it ready for operations, with a link that opens the dashboard already filtered to one district, and a refresh interval so new incidents appear without anyone pressing reload.

Start with the data. Every good dashboard starts with the data, not the widgets. Our source is a hosted feature layer, a map layer stored in ArcGIS Online, called Traffic Incidents, fed by the dispatch system. It needs five fields. A field is simply a column in the attribute table. We need incident type, such as crash or debris; severity; status, open or cleared; district; and reported time, the moment the call came in. That layer goes into a web map with sensible symbols, and the web map feeds the dashboard. In the web map, also set the layer to refresh every minute, so new calls appear on their own. Take a minute to check those fields now, because every selector and chart we build later points at one of them. A missing or messy field is much harder to fix after the dashboard exists.

Lay out the elements. Now create a new dashboard in ArcGIS Dashboards and add four elements. The map takes most of the screen, because location is the first question anyone asks. Next to it, an indicator shows the count of open incidents, using a filter where status equals open. Below that, a serial chart, ArcGIS's name for a bar or line chart, groups incidents by type, so the supervisor sees at a glance whether it's a crash morning or a debris morning. Finally, a list shows incidents sorted by reported time, newest first, with severity in the line item. Don't worry about interaction yet. Get the four elements showing the right numbers first, then connect them.

Selectors in the header. Add a header, then put three selectors in it. The first is a category selector on incident type, shown as a dropdown that allows several values, so an operator can pick crashes and stalled vehicles together. The second is a category selector on severity, shown as buttons, because there are only three levels and one click is faster than a dropdown. The third is a date selector on reported time, with a default of the last 24 hours. For each one, open the actions tab and target all four elements. Now change a selector, and the map, indicator, chart and list all narrow together.

Map actions: follow the extent. Next, make the map drive the other elements. In the map's actions tab, add a filter action that runs when the extent changes, and target the indicator, the chart and the list. The extent is simply the area the map is currently showing. So when an operator pans and zooms to the North district, the open count drops to North's incidents, the chart shows only North's types, and the list shows only North's calls. Why is this so useful? Because nobody has to type a district name. The operator just looks at the part of the city they care about, and every number on the screen follows.

Selection actions: click to filter. Now the charts and lists get to drive too. On the serial chart, turn on selection and add a filter action that targets the map and the list. Click the crash bar, and the map shows only crashes. On the list, add a zoom action and a flash action on the map, so clicking an incident takes the map straight to it and flashes the point. Decide deliberately what the indicator should do. Some teams keep one indicator citywide for context. Others want it to follow every click. The diagram shows the result: the selectors feed every element, the map extent feeds the indicator, chart and list, a chart click filters the map and list, and a list click zooms and flashes the map.

Worked example: a filter in action. Let's test it with real numbers. With the default window, the chart shows all forty-four incidents from the past day: eighteen crashes, eleven stalled vehicles, nine roadwork jobs and six debris calls. As expected, crashes lead the day. Now the supervisor changes the date selector to the last two hours. The chart morphs to five crashes, three stalled vehicles, two roadwork jobs and one debris call. The map and list shrink to match, and the open count updates too. That's the whole point of wiring the actions carefully: one control changes, and every element tells the same, consistent story.

Share it filtered and keep it live. Two last touches make it an operations tool. First, open the dashboard settings and add a URL parameter of type category, on the district field, targeting all elements. Now the North district supervisor gets a bookmark ending in hash district equals North, and the dashboard opens already filtered to her area. Second, make sure the Traffic Incidents layer refreshes every minute, which we set in the web map at the start. The nice thing is that the refresh keeps the current filters, so the North view stays North while new crashes appear on their own. Nobody has to reload anything during a busy morning.

Common mistake: numbers that disagree. Here's the trap that catches almost everyone on this project. A selector targets the map and the list, but someone forgets the chart. The operator picks the last two hours, the map and list show eleven incidents, and the chart still adds up to forty-four. Now the screen disagrees with itself, and people stop trusting it. A quieter version is putting the date selector on the last edited date instead of reported time, so every status update makes an old incident look new. The fix is simple: before you share, open every selector and every action, and check its targets and its field, one by one.

Recap. Let's recap the project. First, you started with the data: one incident layer with clean fields for type, severity, status, district and reported time. Second, you wired the interactions: selectors in the header, a map extent action that drives the numbers, and chart and list clicks that filter and zoom the map. Third, you made it operational, with a URL parameter that opens each district's view already filtered, and a one-minute refresh so new incidents appear on their own. Together, that turns a static set of widgets into a screen a traffic supervisor can actually run a morning from.

Your exercise. Now it's your turn. Build this dashboard with any incident-style layer you can reach, from your own organization or a public one in Living Atlas, such as traffic, service requests or outages. Add at least two selectors, one map extent action, and one chart selection action. Then add a URL parameter on a district or area field and open the link in a private browser window to make sure it arrives filtered. Finally, change one selector and check that the map, indicator, chart and list all agree. If they do, you've built a real operations dashboard.