The data for this project includes information logged about all non-emergency phone calls to the Cincinnati Police Department for just the year 2022. It was decided to use just 2022 for a couple reasons. The first is that the focus of this project was not about handling large datasets, so we were able to improve performance by reducing the amount of data. The other reason is so we could see how the number of calls changes depending on the time of year.
The data set can be found at: https://data.cincinnati-oh.gov/Thriving-Neighborhoods/Cincinnati-311-Non-Emergency-Service-Requests/4cjh-bm8b
The data for this project includes information logged about all non-emergency phone calls to the Cincinnati Police Department for just the year 2022. It was decided to use just 2022 for a couple reasons. The first is that the focus of this project was not about handling large datasets, so we were able to improve performance by reducing the amount of data. The other reason is so we could see how the number of calls changes depending on the time of year.
The data set can be found at: https://data.cincinnati-oh.gov/Thriving-Neighborhoods/Cincinnati-311-Non-Emergency-Service-Requests/4cjh-bm8b
This project involved limited sketching, but my team and I made some basic sketches to decide the layout that we wanted for our interface as well as one of our components. We had talked about how we wanted some of the components to look, but we weren't sure about what direction we wanted to go for the timeline. Noah Shremshock decided to sketch out the component so we knew how we wanted it to look before trying to code it. We ended up deciding on a timeline to brush into specific time spans and a heat map for a more granular view of the data over time.
We wanted the entire visualization to be viewable on one screen, so the interactivity between elements could be easily viewed and understood.
We chose to have all of the map elements close together in proximity. We chose to make the ability to change the color encoding on the map buttons on top of the map that changed to a darker color when clicked so the user could easily view what the color encoding is and view the map easily. The color encoding legend is directly to the left of the map so the dots on the map and what each color denotes can be easily associated. We put the zip code barchart close to the map because filtering by zip code updates the map to easily view where each of the zipcodes are geographically.
We chose to have the timeline going across the page horizontally in the center of the page. Since the brushing directly affects the pool of data being visualized on all of the visualizations.
The timeline heatmap is connected to a barchart showing the number of calls made per day since they are providing different ways to visualize the same data.
The map is used to visualize the data spatially, so the user can see the location in Cincinnati that each call was made from. It has zoom and pan functionality so the user can explore the data on the map and see more details than may be first apparent. Each call is marked on the map by a color coded dot.
The user can use the buttons above the map to switch between 4 different color encodings. The color encoding options are color by service name, time between call request date and call update date, time of year, or agency responsible for the call. The legend explaining what each color encoding represents is to the left of the map.
More information can be viewed about each point on the map by hovering the cursor over a point. When a point on the map is hovered over a tooltip appears with that points, service name, the agency responsible, the request and updated dates, and the full description for the call. The map background can be changed by using the drop down menu above the map. There are three different options that allow the user to view different types of maps, including a topological map, a map with more distinct roads and buildings and a map that from afar shows only major cities but displays more information as the user zooms.
There are 4 different color encodings including service name, agency responsible, time of year, and time between when the call was requested and updated. The color codings for service name, agency, and time of year color encodings are categorical and discrete in nature so the colors chosen for these needed to be easy to differentiate from one another.
We chose to color the service and agency color encodings using a rainbow color scale, because it provided a large number of distinct colors to use for the encoding. This was needed for these two because of the large number of different service names and agencies. We decided to color service names by the top nine most frequent services and a category for others for the rest of the service names because of the large number.
We decided that the best way to display the time of year of the call would be to split the dates requested into the season and colored each season with colors associated with each season, blue for winter (between December and February), green for spring (between March and May), orange for summer (between June and August), and red for fall (between September and November).
The color coding for the time between request and update is continuous in nature. We noticed that the time between the request date and the update date was usually very small so to show difference in the data we chose to encode the time between request and update in milliseconds using a green-yellow-red color scale with green representing the least amount of time and red being the largest amount of time between.
The heatmap visualization shows the relative number of calls on each day, organized by day of the week vertically to show patterns across selected weeks. This chart can be filtered by selecting bars in any of the bar charts as well as by brushing on the timeline. Hovering over a particular day shows a tooltip giving the day’s date and the number of calls on that day. The idea of the heatmap is not only to act as the “focus” to the timeline’s “context”, but to also visualize the call frequencies over time in a different and more interesting way.
The continuous color scale used for the heat map was chosen to give an easy to interpret “temperature gradient” to the number of calls per day. Keeping the number of distinct colors in the gradient low - transitioning from yellow to orange to red rather than something like a rainbow spectrum - maximizes readability and avoids issues related to color blindness. The color scaling maximum and minimum are also dependent on the selected and shown data, meaning that smaller selections with less of a range of calls will still show noticeable color differences between days.
The timeline shows the frequency of calls as a line chart, with calls binned by day. Brushing on the timeline filters all other charts to show data for only the days included within the brush, allowing the user to narrow their focus in time and scan for local data trends.
A default brush is provided when the page is opened which is returned to when the reset button is pressed. This shows the user that brushing is possible on the timeline, gives a curated view of a week that includes some interesting data, and helps reduce lag that may occur when trying to view all of the data at once.
We had 4 different bar charts included in our web page, each of which displaying a different metric about the service calls. Each bar chart pairs nicely with another part of the interface.
Two of the charts coincide with different views from our map. The first shows the service calls broken down by their service type. This can be used in conjunction with the service type map view to see the exact numbers of each service type as you look at their locations on the map. The second bar chart that coincides with a view mode of the map is a histogram that shows the time between when a service call was requested and when it was updated.
The third bar chart filters the service calls by their zip code. This view is very interesting to look at alongside the map because it allows the data to be broken up into smaller sections based on location.
The final bar chart is included as an addition to the heatmap, and it breaks down the data by day of the week. All of the bar charts can be selected to filter the data in the bar charts and the data points on the map. Multiple bars on the same chart can be selected as well as bars from different charts.
When creating the timeline and heatmap we noticed that one wednesday, 2/23/22 had by far the most number of calls. The majority of those calls were for pothole repair. After seeing this data on the map we looked up that Wednesday and found multiple articles from that day and the days following about how bad the potholes were at this time. Here is a link to one of the articles explaining what happened.
Our data Visualizations allowed us to identify exactly when issues were being faced in Cincinnati and we would not have noticed this without the timeline and the heatmap visualizing it.
After adding the points on the map we noticed that when zoomed out to view the whole world there was one point that was not in the Cincinnati area and instead off the coast of Africa. On further inspection we found that the point is at latitude, longitude (0,0). Our visualization allowed us to notice what was most likely a mistake in the data.
There’s a clear pattern in the timeline of significantly fewer calls being made on Saturday and Sunday. Looking at the heatmap and corresponding bar chart makes this trend even clearer, with effectively no exceptions to the rule that Monday and Friday will have more calls than Sunday and Saturday in a given week.
Metal Furniture, Spec Collection is always the most frequent service requested
Time Between requested and update is very small, mostly 0
Because we had limited time to complete this project, there were many parts of the project that I would have liked to clean up or do differently. By far the biggest thing I would fix if I revisited this project would be to clean up our data processing. Even though we are only using one year worth of data, it still loaded much slower than I would have liked. Another thing I would clean up is the chart axes and data labels, as many of them clip into each other and can be difficult to read.