# 311 Wrapped: data and methodology

Release prepared September 13, 2026. Source snapshots, row counts, retrieval times and SHA-256 hashes are preserved in `data/refresh/2026-09-13/verified-source-manifest.json`. The website serves precomputed files; it does not query city APIs during a visit. This release covers the 12 cities listed below.

## Periods and year-over-year change

The 2025 edition uses January 1–December 31, 2025. The 2026 edition uses January 1–September 9, 2026. **Every year-over-year comparison uses January 1–September 9 in both years (252 days).** We do not compare a partial 2026 year against all of 2025, annualize counts, or project future requests. September is a partial month in 2026 charts. December is included in 2025 charts.

The cutoff leaves time for each required feed to publish records beyond the comparison window, including Boston's slower new-system export. This is a reporting-lag precaution, not proof that a publisher will never revise its history.

`difference = 2026 matched-period requests − 2025 matched-period requests`

`percent change = difference / 2025 matched-period requests × 100`

Percentages display one decimal place. A zero 2025 denominator gives a null percentage, labeled “New”; it does not imply infinite growth. An incomplete source baseline gives an unavailable comparison, not a percentage.

## Municipal sources

Accessed September 13, 2026. Each row represents a service request or inquiry as defined by its publishing city. Source categories and coverage differ; these are reports, not a count of incidents, residents, rats, or encampments.

| City | Source and period |
| --- | --- |
| New York City | [nyc 2025](https://data.cityofnewyork.us/resource/erm2-nwe9.csv); [nyc 2026](https://data.cityofnewyork.us/resource/erm2-nwe9.csv) |
| Chicago | [chicago 2025](https://data.cityofchicago.org/resource/v6vf-nfxy.csv); [chicago 2026](https://data.cityofchicago.org/resource/v6vf-nfxy.csv) |
| San Francisco | [sf 2025](https://data.sf.gov/resource/vw6y-z8j6.csv); [sf 2026](https://data.sf.gov/resource/vw6y-z8j6.csv) |
| Austin | [austin 2025](https://data.austintexas.gov/resource/xwdj-i9he.csv); [austin 2026](https://data.austintexas.gov/resource/xwdj-i9he.csv) |
| Philadelphia | [philly 2025](https://phl.carto.com/api/v2/sql); [philly 2026](https://phl.carto.com/api/v2/sql) |
| Boston | [boston_legacy 2025](https://data.boston.gov/api/3/action/resource_show?id=9d7c2214-4709-478a-a2e8-fb2020a5bb94); [boston_legacy 2026](https://data.boston.gov/api/3/action/resource_show?id=1a0b420d-99f1-4887-9851-990b2a5a6e17); [boston_current 2026](https://data.boston.gov/api/3/action/resource_show?id=254adca6-64ab-4c5c-9fc0-a6da622be185) |
| Washington DC | [dc 2025](https://maps2.dcgis.dc.gov/dcgis/rest/services/DCGIS_DATA/ServiceRequests/FeatureServer/18); [dc 2026](https://maps2.dcgis.dc.gov/dcgis/rest/services/DCGIS_DATA/ServiceRequests/FeatureServer/21) |
| Denver | [denver 2025](https://services1.arcgis.com/zdB7qR0BtYrg0Xpl/arcgis/rest/services/ODC_service_requests_311/FeatureServer/66); [denver 2026](https://services1.arcgis.com/zdB7qR0BtYrg0Xpl/arcgis/rest/services/ODC_service_requests_311/FeatureServer/66) |
| Baltimore | [baltimore 2025](https://services1.arcgis.com/UWYHeuuJISiGmgXx/ArcGIS/rest/services/311_Customer_Service_Requests_2025/FeatureServer/0); [baltimore 2026](https://services1.arcgis.com/UWYHeuuJISiGmgXx/ArcGIS/rest/services/311_Customer_Service_Requests_current/FeatureServer/0) |
| Los Angeles | [la_legacy 2025](https://data.lacity.org/resource/h73f-gn57.csv); [la_current 2025](https://data.lacity.org/resource/73a2-6ar5.csv); [la_current 2026](https://data.lacity.org/resource/2cy6-i7zn.csv) |
| Cambridge | [cambridge 2025](https://data.cambridgema.gov/resource/2z9k-mv9g.csv); [cambridge 2026](https://data.cambridgema.gov/resource/2z9k-mv9g.csv) |
| Seattle | [seattle 2025](https://cos-data.seattle.gov/resource/5ngg-rpne.csv); [seattle 2026](https://cos-data.seattle.gov/resource/5ngg-rpne.csv) |

## Cleaning and geography

Downloads are checked against source row counts before and after retrieval. ArcGIS downloads fix an object-ID list and verify each returned batch. The release verifier checks hashes and CSV field counts; malformed records fail validation instead of being skipped. Repeated request IDs within a source are counted once, retaining the row with the latest recorded closure. Legacy and replacement systems have separate ID namespaces.

Explicit UTC timestamps in Philadelphia and Boston's new system are converted to Eastern Time. DC epoch timestamps are converted to Eastern Time. Baltimore's publisher states that downloaded timestamps use local Eastern Time, so they are retained as wall time. Denver uses its full `Case_Created_dttm` field, not the date-only field. Other floating calendar timestamps are retained as published. Los Angeles metadata does not specify a UTC offset, so no offset is inferred. These timestamp policies are recorded per source.

Reported five-digit ZIP codes are checked against the same 2023 Census TIGER ZCTA reference in both years. The reference is selected in a fixed region extending 1.5 degrees longitude and 1 degree latitude around each configured city center. A ZIP with no matching three-digit prefix in that region is treated as missing, then repaired by point-in-polygon intersection where usable coordinates exist. Using a regional prefix preserves valid postal ZIPs without their own ZCTA, including building and airport ZIPs. Missing ZIPs are assigned the same way; ties at boundaries use the lowest ZIP. Coordinates outside the reference region are omitted from story maps. This is a regional plausibility check, not an exact municipal boundary or postal validation. No location is invented for an unlocated request. Citywide source comparisons include unlocated requests; ZIP stories, maps, rankings and their city summaries use only requests assigned a ZIP. Each city/year records both totals and monthly location coverage in its provenance, plus geographic correction counts. Changes in geocoding coverage can affect ZIP comparisons.

Four published categories are removed before any counting because they record call-center interactions or complaints pinned to one facility, not problems at a neighborhood location; every one of their records closes at zero duration. Chicago's "311 INFORMATION ONLY CALL" (447,202 located records in the 2026 window, all logged at the 311 call center at 2111 W Lexington St in ZIP 60612) and "Aircraft Noise Complaint" (316,114, all logged at O'Hare in ZIP 60666) together were about half of Chicago's located 2026 requests; left in, they set 60612's "fastest" closure time, shifted every Chicago ZIP's rank and comparison to the city average, and distorted Chicago's cross-city benchmarks. Los Angeles's "Information-Only" records (302,627 located 2026 records across 504 ZIPs, 19% of the city) describe information provided, status provided, transfers and "SR Created", the last duplicating a separately filed request. Washington DC's "DC Government Information" records (18,846 located 2026 records, 5% of the city) are all described as "311- Call Center", and 38% sit at 2720 Martin Luther King Jr Ave SE in ZIP 20032. Left in, these inflated counts and pulled median closure times toward zero. A scan of every city found no other single address holding more than 1% of located requests. The exclusions are declared per city in `city_config.py` and applied by one shared step whenever normalized data is read, so citywide totals, matched-period comparisons, ZIP stories, response maps, encampment points and cross-city benchmarks all omit the same records, and the release verifier's independent recount applies the same step. Source manifests and provenance row counts still include the excluded records.

ZIP values can be erroneous in source data or shared between city services. If more than one city reports a ZIP, the app resolves its bare ZIP URL to the city with the most reports for the selected year; conflicts are retained in `zip_conflicts.json`. Map centers use the median reported coordinates for the ZIP. ZCTAs approximate postal ZIPs and neighborhoods; they are not exact neighborhood boundaries.

Population rates are requests per 1,000 residents using the existing **2022 ACS five-year** ZIP population snapshot as a fixed denominator for both years. They are not estimates of 2026 population. Missing or zero denominators are omitted; rates for small ZIP populations can be unstable. Rates are rounded to one decimal before ranking; tied rates share the lowest applicable rank. Counts measure reporting activity and access to 311, not the prevalence of every underlying condition.

## City-specific limitations

- **Berkeley is excluded** from this release because its accessible feed lacks a complete 2025 baseline. Its archived CSVs are retained, but it is absent from city selection, comparisons, benchmarks and ZIP routing. ZIPs beginning with 947 are not routed to incidental reports in another city's feed.
- **Denver:** the current feed retains a rolling 12-month window. A preserved 2025 CSV supplies requests before September 12, 2025; the newly retrieved feed supplies dates from then onward. This nonoverlapping date splice avoids regenerated object-ID collisions. Historical records in the archive cannot reflect later publisher revisions.
- **Los Angeles:** 2025 combines legacy and replacement MyLA311 exports; 2026 uses the replacement system. A system migration is a break in comparability: category changes or manually recreated cases can affect counts. The latest timestamp in the publisher's 2025 replacement export is December 31 at 12:59:54; the annual total is the published records, not an estimate of any unreported year-end activity. The YoY window ends September 9. The output does not claim that every change reflects resident behavior.
- **Boston:** both the legacy annual exports and the new-system export are included, with records assigned to years by their opening timestamps. Categories moved between systems during 2025–2026; category-specific comparisons are not a harmonized classification.
- **Seattle:** duplicate source IDs are removed. Its export lacks closure dates; unavailable closure-time metrics remain null rather than zero.

## Maps and other metrics

Monthly, hourly and weekday charts count requests; absent months within a displayed period are zero-filled. Response time means elapsed hours from opening to the recorded close date, among requests with valid nonnegative durations. Slow closures, including those over 30 days, remain included. Unclosed requests are not assigned a zero duration. Closure is an administrative status and does not prove the problem was fixed. 2025 requests may have closure dates in 2026 as observed in the refreshed source. Differences in time available for closure make these descriptive closure metrics unsuitable for a causal year-over-year service-performance claim.

Response-map quintiles rank ZIP median closure times within each city and selected period. “Median ZIP” is the median of those ZIP medians, not the median of all requests. Encampment dots are distinct reported coordinates, rounded to five decimal places, for categories containing “encampment”; they are not verified encampments or a concentration statistic. Other story maps may show a reproducible sample of points; their headline totals use the full relevant request set.

The subway layer uses the [MTA station dataset](https://data.ny.gov/resource/39hk-dx4f.json), retrieved for this release. Stations within 800 meters of a ZIP's median report location are shown. Counts use NYC requests whose category is “Rodent,” within 200 meters of each station, for the selected year/window. Station buffers can overlap; the ZIP total counts each nearby report once, while station totals count their respective buffers. These are rodent reports, not individual rats. Station geography is held fixed across the two editions.

The election chapter remains explicitly the 2025 NYC mayoral election; its static election data is not relabeled as 2026. Service ratings, archetypes, “snitch” scores and themed copy are editorial heuristics, not validated indices of neighborhood quality. Their existing formulas are in `precompute.py`. Cross-city category and rating comparisons are descriptive and affected by differences in service coverage.

## Reproduction and verification

Use the four stages documented in the repository README: `refresh_data.py`, `prepare_years.py`, `build_years.py`, and `release_data.py`. The final stage independently recounts matched-period requests from normalized data and verifies every ZIP total, monthly total, story date, comparison, source hash, and CSV record shape. It rebuilds year-specific map layers and indexes. `verification.json` records the resulting city totals and coverage status. `--install` backs up existing local assets before installing validated data; it does not deploy the website.

**Confidence:** high in the arithmetic and correspondence to the preserved source snapshots after validation; limited by publisher completeness, timestamp conventions, geocoding and changing service systems. Berkeley is excluded.

## Detail and small-sample rules

Worst-day multiples use the number of calendar days in the selected edition, including days with no reports. Calendar labels preserve the city's reporting date regardless of the viewer's timezone. Night activity includes hours 22, 23, 0, 1 and 2 (10pm up to 3am); the total comes from the full hourly distribution, while the map shows at most 500 sampled, located requests. The noise percentage is the share of all requests whose published category contains “noise” or “loud”; it is separate from the commercial-to-residential noise ratio retained in legacy data fields.

ZIPs with fewer than 25 reports receive a limited-data story with counts, timing and a share card, without personality or service-rating claims. The 25-report display threshold is a presentation rule, not a statistical confidence interval. Raw records, city totals and matched-period comparisons remain intact. Service grades combine recorded closure times and the share of selected report categories using editorial weights; they are unavailable when fewer than 25 closure durations are recorded. A recorded closure does not establish that a problem was repaired. The slowest-category comparison requires at least 11 recorded closure durations in a category; otherwise it displays unavailable.

## Category, channel and comparison safeguards

Cambridge uses the published `issue_category` as the category and preserves `issue_type` (which can be a resident-written title) as the descriptor. Report counts and time windows are unchanged by this correction. Denver retains published `Case_Summary` labels: its structured `Topic` field is empty and `Type` is almost entirely empty in the current snapshot, so some categories remain free text and the feed includes inquiries. No replacement category is inferred.

The former civic-vigilance score is now presented as a report-mix percentage: categories containing “noise”, “loud”, “parking”, “blocked driveway” or “driveway block”, ignoring case. It describes the contents of each city's published feed. City coverage and category definitions differ. It does not measure how many residents use 311. Street/water, cleanup/pest and building/construction groups also use shared category-word rules instead of New York-only exact labels. Editorial archetypes use a whole-word tree match so “street” cannot be counted as “tree”.

Reporting-channel labels such as “Phone Call”, “Mobile Device” and “Citizen Web Intake” are grouped using an explicit alias list in `compute_channel_usage`. Unspecified channels remain unspecified; ambiguous interfaces, staff systems and other channels stay in “Other” rather than being guessed to be web or mobile. Percentages use all reports as the denominator.

Twin comparisons use category shares among ZIPs with at least 25 reports in the same city and edition. The similar twin is the ZIP with the smallest cosine distance between the two share vectors. The different twin is chosen only among ZIPs with at least 1,000 residents in the population snapshot, so airports, civic buildings and hospitals cannot be anyone's twin. Each ZIP's shares are compared with the median share of every category across the city's profiled ZIPs, and the different twin is the eligible ZIP whose pattern of over- and under-reporting points most nearly opposite to the selected ZIP's (lowest cosine similarity between the two deviation vectors). The previous rule, the farthest raw share vector, named the same airport or civic-building ZIP for most of a city. The similar and different twins must be different from the selected ZIP and from each other; a ZIP with no eligible candidate has no different twin. Service grades, agency comparisons and response-map rankings require at least 25 recorded closure durations; raw medians and closure counts remain available. The slowest-category comparison requires at least 11 recorded durations in that category. These are display safeguards, not confidence intervals. Gray map areas indicate missing or insufficient closure data. Map dots in the category explorer and turf-wars views are capped samples, not complete inventories of requests or distinct people. Peak three-hour windows compare the eight labeled clock windows directly.