NYC311-ML: Predicting Processing Time of NYC Citizen Service Requests Using Machine Learning

This project is a complete full-stack machine learning project that uses real NYC 311 service request data to build an analysis platform for predicting complaint resolution time. The tech stack includes PostgreSQL, FastAPI, React, and XGBoost. The original author is gregluna4809, and the project is open-sourced on GitHub (link: https://github.com/gregluna4809/NYC311-ML) with an update time of 2026-06-08T03:14:47Z. The core goal is to provide data support for urban management and resource allocation through data analysis and prediction models.

After completing a machine learning project in the field of bioinformatics, the developer wanted to shift to analytical problems closer to the daily operations of organizations. NYC 311 service request data became an ideal choice due to its public availability, large scale, and easy-to-understand meaning. This project also provides a comprehensive opportunity to practice multiple skills such as data engineering, SQL, PostgreSQL, machine learning, API development, and front-end development. The 311 system is the main channel for NYC citizens to report non-emergency issues (e.g., noise, heating, street repairs), generating thousands of records daily. Analyzing this data can help understand citizens' concerns and predict processing time.

The project adopts a modern full-stack data application architecture. The data flow starts from the NYC Open Data Platform, is stored in PostgreSQL, provides API services through the FastAPI backend, and finally displays an interactive dashboard via the React frontend. The prediction engine is based on the XGBoost model, supporting real-time estimation of complaint resolution time. The tech stack selection includes PostgreSQL (structured data storage), FastAPI (high-performance asynchronous API), React (responsive UI), Docker (containerized deployment), and XGBoost (structured data prediction), ensuring system maintainability, scalability, and development efficiency.

The dashboard supports multiple functions: exploring the distribution of complaint activities, analyzing complaints by agency/borough, viewing historical complaint volume and resolution time trends, comparing model performance, and generating resolution time predictions for new complaints. The prediction function requires users to input information such as agency, complaint type, borough, day of the week, month, and hour, and returns the predicted resolution category and confidence level. For example, inputting a heating/hot water complaint from the Department of Housing Preservation and Development (HPD) in Brooklyn may result in a prediction of 3-7 days resolution with 64% confidence. This feature can help managers estimate workload, allocate staff, and set citizen expectations.

The dashboard provides multiple analyses: resolution category distribution, complaint hotspots by borough, complaint volume statistics by agency, ranking of popular complaint types, and trends in monthly complaint volume and average resolution time. All data comes from real-time PostgreSQL queries without hardcoding. Sample data shows: the New York City Police Department (NYPD) handled 1650 complaints, the Department of Housing Preservation and Development (HPD) handled 1424; heating/hot water issues (759 cases) and residential noise (493 cases) are the most common complaint categories. These insights have direct guiding significance for resource allocation and policy formulation.

The project evaluated multiple prediction models: majority class baseline (44.3% accuracy), logistic regression (72.1%), standard XGBoost (72.9%), and optimized XGBoost (74.4%). The optimized XGBoost was selected as the deployment model due to its best performance. The target categories are divided into four time intervals: same-day resolution, 1-3 days, 3-7 days, and over 7 days. XGBoost performs excellently in structured data prediction and has the characteristics of strong interpretability and fast training speed, making it suitable for this scenario.

The backend is built based on FastAPI, providing health check, analysis endpoints (category statistics, borough statistics, agency statistics, popular complaint queries, trend analysis), prediction endpoints, and metadata endpoints (list of complaint types). The API follows RESTful principles with clear endpoint naming and consistent return structures. FastAPI automatically generates Swagger documentation, supporting direct testing of all endpoints in the browser, reducing front-end and back-end collaboration costs and enabling third-party integration.

This project demonstrates how to push machine learning from experiments to production applications. It is a complete data product including data pipelines, storage layers, API services, user interfaces, and deployment configurations. For developers learning data engineering and machine learning, it is an excellent case to understand full-stack project architecture. Its practical value lies in providing data-driven decision support for urban service management, helping to plan resources, set service standards, and identify bottlenecks. Similar methods can be extended to other urban service areas, such as emergency response time prediction and public facility maintenance priority ranking.