Water data has a place.
Put it on the map.

A water-level reading is useful, but it becomes more actionable when an operator can connect it to a place. A tank with a low reading is one data point. Several low tanks in the same area, alongside reports of dry taps, may point to a wider supply problem worth investigating.

That is the motivation behind the geographic component of Smart Water Zambia. The current web dashboard includes a map view for monitoring stations, tanks and community incidents. It is built with Leaflet and OpenStreetMap tiles, and it plots records that have valid stored coordinates.

What the current map displays

The map supports two main layers. The infrastructure layer displays monitoring stations and tanks. The incident layer displays community reports with their category, location name, status and available location accuracy. Operators can toggle the layers to focus on infrastructure or reports.

Tank markers communicate the last-known condition, including normal, low, critical, offline or sensor-error states. A popup shows the tank identity, last-known level and timestamp. A station marker is deliberately distinct from a tank marker: a station's location is not a substitute for the actual tank's location or measurement.

Incident markers distinguish resolved from unresolved reports. Their popups can show the report category, description, location, coordinates and accuracy, with a directions link for navigation. This makes the map a practical way to inspect where reports were submitted, not merely a decorative map background.

Coordinates need validation

Displaying a pin is easy. Knowing whether the pin is trustworthy is harder. The current geographic helper checks that latitude and longitude are present, numeric, within valid geographic ranges and not the default zero-zero coordinate. It also formats accuracy values where they are available.

Even a syntactically valid coordinate is not proof that a tank or incident is physically located there. The map code explicitly treats stored coordinates as locations that have not necessarily been verified. That distinction matters when an operator uses the map to make a field decision.

From a map to a GIS workflow

A map becomes a more complete geographic information system when spatial data is connected to analysis and operational questions. Smart Water Zambia's current map is a foundation, not a claim that every GIS capability is already implemented.

Useful next analytical layers could include:

• Incident clustering: identify concentrations of shortage, leak and burst-pipe reports over a defined time window.
• Service-area context: compare incidents and tank conditions with verified service boundaries or neighbourhood polygons.
• Temporal comparison: examine whether incidents repeatedly occur in the same locations or after particular supply conditions.
• Field response: help teams navigate to reports and record whether a location was visited and verified.
• Data-quality overlays: distinguish verified coordinates from approximate, manually entered or unverified locations.

These features require suitable source data. A service-area analysis needs authoritative boundary information. A cluster analysis needs enough correctly located reports and a clear definition of what counts as a cluster. A route optimisation feature needs operational constraints such as road access, team availability and priority—not just pins on a map.

Do not turn demo data into evidence

Smart Water Zambia includes simulated telemetry for exercising the application before a complete physical deployment. Simulated readings are useful for testing dashboards, alerts and data flow, but they must not be presented as measured water conditions in a real community.

The newer telemetry design tracks reading provenance and excludes simulated, test, unknown and historic readings from operational telemetry aggregation. The same discipline should apply to geographic reporting: test reports, approximate coordinates and verified field observations must remain distinguishable.

Privacy belongs in the map design

Community reports can contain descriptions, photos and location details. Not every user should be able to see every report or its full submission data. The map should display only information that the viewer is authorised to access, and public-facing maps should avoid exposing personal details or precise household locations unnecessarily.

There is also an external service dependency: the current location search uses OpenStreetMap's Nominatim service. Search text is sent to that service, so usage policy and availability need to be considered. Manual coordinate entry and map selection remain available in the current design.

What needs to happen before operational GIS use

Before relying on spatial insights, the project needs verified infrastructure coordinates, clear location-accuracy metadata, consistent incident categories, enough real reports to support analysis, and an agreed process for confirming field observations. The data model and map should make uncertainty visible rather than hiding it behind a precise-looking pin.

More advanced GIS work should also be evaluated against actual decisions. A heat map is only useful if it helps someone prioritise a response. A service-area overlay is only useful if its boundaries are trustworthy. A route is only useful if it reflects how field teams can actually travel.

Explore the geographic implementation

• Leaflet incident and infrastructure map
• Coordinate validation and map helpers
• Smart Water Zambia architecture
• Smart Water Zambia case study

The useful next step is not to add GIS features because they look impressive. It is to connect reliable locations, verified events and water-system data to decisions that utilities and communities actually need to make.

Written by Leo Mabuku · Software developer and Computer Science graduate · Get in touch