Where should the sewer service desk review closure lag?

Spatial AnalysisintermediateDecision support

A city service manager has one week of sewer-related 311 requests and wants a spatial review queue. They need to see where requests that took more than 24 hours to close are concentrated, with each underlying request still inspectable.

Use /data/requests.geojson, a fixed 1–7 June 2025 intake cohort of geocoded NYC 311 sewer requests that were eventually closed. In the Python runner, input is mounted at /data/<dataset id>.geojson; assign a GeoDataFrame to result and do not write a file.

Parse created_at and closed_at as local civil timestamps, compute lag_days from their difference in elapsed days, and return only requests with lag_days > 1 (strictly greater than 24 hours). Preserve point geometry in EPSG:4326 and fields request_id, descriptor, borough, created_at, closed_at, and lag_days. The result map should make concentrations of delayed requests visible while each mark remains inspectable.

The one-day threshold is this manager's review rule, not an official NYC 311 service standard. A 311 complaint is a report, not an observed sewer failure; closures can reflect administrative workflow. The snapshot excludes still-open and ungeocoded cases, so the result is a review queue for this cohort, not a citywide failure rate. Run previews your own map without grading; Submit checks the result.

The input files

/data/requests.geojson — EPSG:4326; the geometry is in geometry (Point).

column	type	meaning
`request_id`	string	311 service request identifier
`created_at`	date	Local NYC civil time when the request was created
`closed_at`	date	Local NYC civil time when the agency closed the request
`descriptor`	string	Complaint subtype
`borough`	string	Reported borough
`incident_zip`	string	Reported postal code

What to submit

Submit: A Python script that assigns its output to result.
Input files: /data/requests.geojson
Required properties: request_id, descriptor, borough, created_at, closed_at, lag_days
Result geometry: Point

Objectives

Calculate closure lag from timestamp fields without inventing values for open requests
Select the service manager's review queue
Map the concentration of selected requests while retaining per-request details

Constraints

These are where the teaching is. Read them twice.

Use strict lag_days > 1 rather than >= 1
Preserve original request identifiers and locations
Do not treat the density surface as a risk model or a measure of infrastructure failures

Graded requirements

Requests in the review queue
Correct service-request set
Auditable closure-lag attributes
Longest closure lag remains visible
Mapped locations are points

NYC Open Data publishes 311 service requests: https://data.cityofnewyork.us/resource/erm2-nwe9.json . A heat map shows request concentration, consistent with QGIS's density-analysis training: https://docs.qgis.org/3.44/en/docs/training_manual/processing/john_snow.html .

Python

Loading editor

Files: /data/requests.geojson · assign result

Loading map

What will be checked

5 scored, 0 informational

Requests in the review queue
25%
Correct service-request set
33%
Auditable closure-lag attributes
17%
Longest closure lag remains visible
17%
Mapped locations are points
8%