Project: prepare a water main break web map for a city operations dashboard

A break at 6:40 in the morning. It's six forty on a Monday morning. A twelve-inch water main has just broken under a busy downtown street. Within minutes the field supervisor wants to know which crew is closest. Customer service wants to know which blocks have low pressure. The operations manager wants a count of every open break in the city. They'll all look at the same operations dashboard. That dashboard doesn't store any data. It reads everything from a web map and its layers. If the fields are messy, the pop-ups are cluttered or the wrong people can see the data, the dashboard shows those same problems. In this project you'll bring together everything from this course and build the web map properly, before anyone draws a single chart.

What you will learn. This is the project lesson for the course, so we'll work through one complete example from start to finish. First, you'll prepare a hosted feature layer of water main breaks. That means correct field types, readable aliases, a status domain and real date fields. Second, you'll build the web map the dashboard will read. You'll set symbology that tells the story at a glance, pop-ups that answer the crew's first questions, and layer visibility that keeps the map clean. Third, you'll create hosted feature layer views so each audience sees only what it should, and you'll share everything so the dashboard actually works for the people who open it.

The project brief. Here's the brief from the city's water utility. They have one hosted feature layer called Water Main Breaks, with one point for each break. Each point records a status, the time it was reported, the diameter of the main in inches and the crew that's assigned. Two audiences will use this data. The internal operations team needs every break, including crew names. The public needs a simple status page showing only active breaks, with no staff details. We'll do all of this in ArcGIS Online, which you can open at arcgis dot com. Think of the brief as a work order. Every decision we make next should trace back to one of these needs.

The workflow. Here's the order we'll follow. We start with the hosted feature layer and fix its fields and domains, because everything downstream inherits them. Next we build the web map, where we set symbology, pop-ups and visibility. Then we create hosted feature layer views. A view is a window onto the same data with its own filter and its own sharing, a bit like giving a visitor a key to one room instead of the whole building. After that we share each view with the right group. Only then does the dashboard enter the picture. If you follow this order, you rarely have to go back and rebuild anything.

Worked example: check the data. Before we touch the map, let's check the data the way a dashboard will read it. This small Python example has five breaks. The status field stores short codes, and the labels dictionary plays the role of a domain. A domain is a fixed list of allowed values, each with a code that's stored and a label that people see. Converting the reported column to a true date type matters because dashboards can only filter by "last twenty-four hours" on real date fields, not on text. Then we keep every break that isn't closed. That leaves four active breaks, and two of them are on mains twelve inches or larger. Those are exactly the numbers the dashboard's indicators should show later.

Where the breaks are. Now let's put the data on a map. Here the four active breaks appear across the city. Operations staff often ask which customers are affected, so we can add a three hundred metre buffer around each break. A buffer is a zone drawn at a fixed distance around a feature. It's a quick way to show the area that probably has low pressure until the hydraulic model says otherwise. Now fly in to break one oh one, the twelve-inch main. At street level you can see which blocks sit inside the zone. So what zoom level will the dashboard map open at? Save the web map at the whole-city extent, around zoom thirteen, so every active break is visible when the dashboard opens. The dashboard starts from the map's saved extent, so set it now.

Symbology that reads at a glance. Symbology is how the map draws each feature, and on a dashboard it has to work at a glance on a wall screen. We'll style by unique values of status, using red for Reported and orange for Crew on site. Because we set up a domain, the legend shows the friendly labels instead of the codes. Then we add size by main diameter, so a sixteen-inch main draws larger than a six-inch one. Stop there. Two visual variables are about the limit before people start squinting. For repaired breaks, add a layer filter in the operations map, status not equal to closed, rather than giving them a pale color. Try it on a phone-sized browser window too, because supervisors will open this dashboard in their trucks.

Pop-ups that answer the first question. When a supervisor taps a break on the dashboard map, the pop-up should answer their first question in one line. Set field aliases so people see "Main diameter, inches" instead of main underscore diam underscore in. Put the status and the reported time at the top. You can add an Arcade expression that works out how many hours the break has been open. Arcade is Esri's short expression language for calculating values on the fly. Then remove the clutter, such as object IDs, global IDs and the editor tracking fields. The result is a pop-up a crew lead can read in two seconds, and the dashboard's map element reuses this same pop-up automatically.

Views for each audience. Now we split the data by audience. From the source layer, create two hosted feature layer views. The operations view keeps every field and is shared only with the operations group. The public view gets a filter for status not equal to closed, and the crew field is hidden in its field settings. Share that one with everyone. Both views read the same source layer, so an edit in the field shows up in both without any copying. Build one web map on each view and save them with clear names. That gives you one layer to edit and two safe windows onto it, and you can add a third audience later in about five minutes.

Common mistake: sharing out of step. The most common mistake in this project is sharing that's out of step. Someone shares the public web map and the dashboard with everyone, but the view underneath is still private. Public visitors then get a blank map or an unexpected sign-in prompt. The second version of this mistake is filtering only in the web map. A map filter changes what's drawn, but anyone who opens the layer's URL can still see every record, including crew names. Filters that protect data belong in the view. The fix is simple. Before you announce anything, check sharing on the dashboard, the web map and the view together, then open the dashboard in a private browser window to see exactly what the public sees.

Recap. Let's recap the project. First, clean data comes first. Real date fields, a status domain and readable aliases carry through to every map, pop-up and chart built on top. Second, the web map is where the dashboard's look is decided. Its symbology, pop-ups, visible layers and saved extent all come straight through, so get them right once. Third, hosted feature layer views let one source layer serve several audiences. Each view has its own filter and its own sharing, and those settings have to match the map and dashboard that use it. With that, your data and maps are ready, and the next track builds the dashboard itself.

Your exercise. Now it's your turn, and it takes about forty-five minutes. Publish a small layer of five to ten water main breaks in your ArcGIS Online organization, or start from a sample incident layer in Living Atlas. Give it a status field with a coded domain, readable aliases and a true date field for the reported time. Build an operations view with every field and a public view that shows only active breaks and hides the crew field. Make one web map for each view, with status symbology and a clean pop-up. Finally, open the public web map in a private browser window and confirm it loads without a sign-in prompt. Keep these maps, because we'll build the dashboard on them next.