Project 2 — Who you gonna call? 3-1-1!
Amogh Silaparasetti, Anne Ning, Jonah Carter, Kevin Long
View it Live | Source Code | Demo Video
Data
Our data are from The City of Cincinnati’s data portal and includes all 311 non-emergency requests received by the city in the full year 2025.
It can be downloaded here.
To position the flags for each neighborhood we used coordinates from each neighborhood’s Wikipedia page. A full list of these pages can be found on Wikipedia’s list of Cincinnati neighborhoods.
Sketching
We each started the design process by reading through the design requirements and then drawing some very basic design sketches of how we wanted to layout our app. A sample of these sketches are included below.
Our sketches for our initial concepts were all somewhat in alignment, but we nonetheless got together and talked about the changes we would make before settling on the layout found in our final design.
The Visualization
1 section on the visualization components: Explain each view of the data, the GUI, etc. Explain how you can interact with your application, and how the views update in response to these interactions. Please include screenshots to illustrate, and relate these screenshots to the text.
There are three sections of our application: the map, the attribute view visualizations, and the service requests over the span of a year.
The largest section, the map, shows various data service requests on a map of Cincinnati. The user can zoom in or out using the plus or minus button in the top left, and change the category of data they wish to see by using the dropdown on the bottom left.
The buttons on the top right allow the user to change the map layer and add/remove filters to change what is shown on the map.
In the Service Request view, the colors of the dots (corresponding to the legend in the bottom left) shows the time it took for a service request to be handled. The Neighborhood view shows all the neighborhoods of Cincinnati (marked with their flag) and the number of service requests they had.
The Priority view shows the priorities of the filtered requests, Responding Department view shows the department that handled the request, and the Service Type view shows the type of service that was performed. The tooltip is visible when hovering over a marker on the map, and it shows more detailed information about the request handled at that location.
Different attribute visualizations can be viewed by clicking the blue buttons at the top of the right panel for attribute views. Requests by Neighborhoods shows the number of requests per neighborhood, sorted in descending order. Common Request Methods show the most common methods of submitting a request on a pie chart.
Hovering over a bar in one of the bar charts shows a tooltip with details about that bar. Hovering over a pie/donut slice or a legend item highlights the section on the chart.
Here is a quick demo video showcasing all the features of our app.
Findings
By default our app shows the pothole repair data and the response time. The first thing you will notice about it is that it is mostly a sea of yellow. This goes to show that the city responds to the vast majority of pothole repair requests within a short amount of time. There are only a few exceptions to this which is why the color scale goes all the way to 238 days (red).
The next most obvious discovery is that the vast majority of the service requests, regardless of service type, are made to the Public Services department (96,637 vs. the next closest at 18,188). This can be seen in the “Requests by Departments” bar graph along the right side.
Although it’s far from the only other thing you can learn from our visualization, one final example is that if you look down at the timeline in the bottom you can see that the two months with the most potholes reported are February and March. This makes a lot of sense if you think about what causes potholes to form. Potholes form when water (usually from snowmelt or rain) seeps into cracks in the pavement and then freezes and expands.
February and March in Cincinnati tend to be the months where the weather fluctuates between rainy and above freezing during the day, then dips during the night (or sometimes even just the next day), thus more freeze-thaw cycles and thus more potholes.
The Process
We used just D3.js and Leaflet with plain old JS, CSS, and HTML for the layout and all the visualizations in our app. Our code structure is pretty similar to the structure used in the sample code. We have a separate code file for each of the visualizations in our app.
We used Python and Pandas for the data preprocessing.
We used Affinity Designer and Figma for the flag illustrations. The flags themselves are from CincyFlags.
Responsibilities
Who did what- describe who did which part of the project
Amogh - I worked on implementing the layer mechanic where the user can choose which map type they want to see and the brush mechanic where the user can drag and make a selection area (brushing)
Anne - I mainly focused on the attribute view visualizations (level 3). I implemented the four smaller visualizations on the side: two bar charts and two pie/donut charts. I also added the brushing for these graphs.
Jonah - I mainly focused on the tooltips and the timeline. I implemented the timeline as a stacked bar chart that responds to changes in the filters. I also added all the useful data you see when hovering over a data point on the map.
Kevin - I worked mostly on map related elements. I implemented the legends and color scales as well as the filters and neighborhood flags.
AI Use
For this project, we have used AI to find solutions that are hard to figure out using other online resources such as documentation, forums. Etc. For instance, AI is used to debug the implementation of the brush feature for the map which can be enabled/disabled using the Arrow Button on the bottom of the list of buttons at top-right corner.
Furthermore we used AI to write the Python data preprocessing scripts we used to help compress the dataset to a more manageable size.
Future Work
We have a couple of things we would like to do if we had more time on this project.
The first and easiest thing is that we have completed code on a separate branch in our project that implements brushing on the map. We didn’t realize until today when we started writing this documentation but that branch did not get merged and therefore it did not get deployed by the due date.
It is ready to merge and would at this point be a very simple feature to add since all the hard work has already been done to implement it.
The next thing I think we would like to do is to finish linking everything. Some of our visualizations are linked (for example the map and the timeline) but there are a couple of the visualizations remaining that we just ran out of time to link together.
