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.

Purpose

These visualizations are intended to explain first and foremost the somewhat bizarre clue in a 2020 USA Today crossword "Cookie that some people eat with mustard" for Oreo, but also why the word is so popular in crosswords and why crossword constructors have to go to such extreme lengths to keep cluing the word in new and interesting ways.

The Data

The data that primarily powers the visualizations in this piece come from a database of crossword clues from over 90,000 grids from a whole host of different publications.

These data were compiled by automatically downloading and parsing crosswords daily from each of the source publications.

Users

The users of these visualizations are simply the readers of the article. It is assumed that they are at least familiar with the concept of crossword puzzles, but the story portion does a great job of explaining any of the important context needed to understand the visualizations themselves.

For example they include the following text and visualization to explain the prevalence of words like Oreo in the crossword.

Questions and Insights

There are many questions that a user can answer using these visualizations. Using what is probably my favorite of the visualizations, you can answer the question of when different words were first used to clue Oreo. You can slide through the years and see each of the new words used in clues and what the full clue in which each word made its debut.

From this I can for example, see that the first time the word favorite was used to clue Oreo was in 1998 and the full clue was "Cookie favorite".

Another cool interactive visual that provides an interesting insight is the interactive probability permutation grid.

This visualization helps the user understand with the use of numbers and probabilities how Oreo is disproportionately used compared to the actual most probable or common answers.

It helps illustrate why Oreo is such useful fill when the user can see an entire grid and the actual restrictions that come with puzzle construction.

Design Choices

I overall really like most of the design choices in these visualizations. I think they are by and large effective. They are clean and minimal. The almost slideshow-like format really highlights what is important at any given time and enables the user to focus on just that important information without the distraction of previous visualizations and/or text.

The one criticism I have is of the letter frequency visualization.

I very much appreciate the detail-on-demand feature of highlighting the current letter as you hover over it and showing the actual percent frequency. The problem I have with it is for some reason they give you a crosshair mouse pointer.

This makes me at least think I should be able to drag to make a rectangular selection of some kind. Maybe I'm alone here, but I suspect others would expect the same.

Limitations

Really all the limitations of this type of visualization stem from the fact that they are being used to tell a specific story. In this case about the word Oreo.

Perhaps a user may wish to explore some of the other frequently used words in a similar manner. These visualizations do not allow for that.