311 data...improvements are needed

 

Ottawa Publishes Open Data. It Just Doesn't Tell You the whole story.

The City of Ottawa's 311 open data portal is, on paper, a good-government win. Every service request — garbage, potholes, sewer backups, bylaw complaints — logged, timestamped, and published for anyone to download. Transparency, self-service, accountability. 

I pulled a full year of it: 372,029 requests across all 24 wards. 

What I found isn't a transparency success story. It's a case study in how a city can technically comply with open data principles while making the data itself useless for the one thing it's supposed to enable — checking whether the city is actually doing its job.

The "Resolved" stamp means almost nothing

Every request in the dataset carries a status: Resolved, Active, or Cancelled. Resolved is supposed to mean the work got done. Here's what actually happened to the "closed" dates on those Resolved tickets.

For most of 2025, closures tracked normally — tens of thousands a month, declining steadily into early 2026 as the backlog from the previous year worked itself down. Then, in a single week — May 14 to May 20, 2026 — the city closed 123,135 tickets. That's a third of every resolved request in the entire dataset, stamped shut in six days.

This wasn't one department. It hit Roads and Transportation, Water and the Environment, City Facilities, Recreation and Culture, Health and Safety, Licenses and Permits — in every one of those categories, over 99% of all resolved tickets for the year got their close date inside that same six-day window. Bylaw Services, Garbage and Recycling, and Parking Enforcement were untouched — they closed normally, day by day, all year.

That's a bulk administrative closure, not bulk service delivery. Someone ran a process that stamped a backlog of tickets "Resolved" without the underlying work being tied to that date at all.

The consequence: you cannot use this dataset to answer "how long does it take the City of Ottawa to fix a flooded basement or a blocked catchbasin." The number the data gives you — a median of roughly 300+ days — isn't a service-time metric. It's an artifact of when someone cleared a queue.

If the city is using "percentage of requests resolved" or "average resolution time" as a public performance metric anywhere — in a budget document, an auditor general report, a councillor's talking points — that metric is built on this same broken foundation.

You can't map a problem the city won't locate

Ward 13 alone logged 191 flood- and sewer-related complaints in 2025: basement flooding, blocked catchbasins, flooded roads, a couple of sewer cave-ins. I wanted to know where. The dataset has address and coordinate fields for exactly that purpose.

They were populated for 28 of those 191 records — about 15%. The other 85% simply say "\N": null, not provided.

This matters beyond one ward. Without location, a resident can't be told "yes, your street has a documented pattern." A councillor can't be shown a map of where stormwater infrastructure is failing repeatedly. A journalist can't independently verify whether a neighbourhood's complaints cluster around one aging pipe or one undersized catchbasin. The one piece of information that would let anyone outside City Hall do spatial accountability work is the piece most often missing.

No severity, no linkage, no way to see a pattern

Two more gaps compound the first two:

No severity field. A basement flooding complaint that ruins someone's finished basement and a "spray pad blocked" complaint at a splash pad get filed under similar-sounding codes with no way to distinguish impact. The data can't tell you which 311 calls represent real property damage.

No incident linkage. On March 6, 2025, seven separate flooding complaints came in from the same stretch of one Ward 13 street — clearly one storm event overwhelming one piece of infrastructure. 

In the data, they're seven unrelated rows. Reconstructing that cluster took manual cross-referencing of street names and dates by hand. The city's own system had no field to flag "these are the same root cause" — which means nobody at the city is positioned to easily map storm-event impact zones either, unless they've stapled dozens of address strings together the same way.

Even the geography is incomplete

One more: roughly 37,000 of the 372,029 records — about 10% of the entire dataset — have no ward assigned at all. Any ward-by-ward comparison, including the one I just did, is working from roughly 90% of the real picture, with no way to know whether that missing 10% is spread evenly or concentrated in specific wards.

Publishing data isn't the same as publishing accountability

None of this requires new data collection. The city already gathers close dates, addresses, and coordinates — the fields exist, they're just inconsistently filled or, in the case of the May 2026 closures, actively misleading. Fixing this is a data-governance decision, not an engineering project:

• Preserve the actual work-completion date separately from any administrative status-batch update, so bulk closures can never masquerade as timely service.
• Require address or coordinate data at intake for infrastructure-related complaint types, with privacy-preserving generalization (block-level, rounded coordinates) where needed.
• Add a root-cause or incident-linkage tag so related complaints — a storm, a water-main break — can be seen as one event instead of reconstructed by hand.
• Publish the ward field completely, or explain publicly what the 10% gap represents.

Open data that can't answer "did the city fix it, and how fast" isn't transparency. It's the appearance of transparency, which is arguably worse, because it lets the city point at a public portal and call the accountability box checked.