How I built my own speed camera and proved my street has dangerous drivers.
Have you felt like more cars speed down your street during the pandemic?
You’re not making it up. It’s true. A new report confirms with emptier roads, people are driving faster and more recklessly. While total miles driven are down 13 percent, road deaths have actually increased 24 percent. This is the sharpest yearly uptick the National Safety Council has measured since 1924 — a century ago.
Speeding cars can be deadly if you’re out for a walk or riding a bike. A pedestrian hit by a car going 40 miles per hour has an 80 percent chance of being killed.
What can you do about it?
Have you complained to your local authorities, only to be ignored? They’re often inundated with issues, understaffed, underfunded, and various laws dictate how they can respond.
Your safety deserves to be taken seriously. Unfortunately, you’ll probably need to build a strong case to be heard. A group of neighbors and I want the city of Oakland to install traffic calming features to slow drivers down. This would likely include speed bumps and traffic circles. So, I built the case for the problem on my street in three major phases:
- Build a homemade traffic sensor for about $200. Mount it and calibrate it.
- Collect and analyze the data. Talk to neighbors and record their stories.
- Share neighbors’ stories and the data with local officials and media. Repeat myself a lot. Be persistent and become hard to ignore.
Build a Homemade Traffic Sensor
Thanks to the Internet, I found an intrepid tinkerer who was vexed by the same problem. He built his own homemade traffic sensor with off the shelf parts. Tim Hodges shared his parts list and code, which I used to create mine. In my case, it took:
- About $200 in parts
- Help from a neighbor who’s a software engineer *
- A bit of patience
* If you happen to know the programming language Python, you can do the whole thing yourself.
If you’re new to this kind of thing, ask people you know. At first, I didn’t have the confidence to build my sensor. But I took a stab when my neighbor Jesse encouraged me. I was able to build the device and get the operating system and sensor program running. He helped me modify the code for remote access and to write the data to a Google Sheet.
You can find our version of the Traffic Camera code on GitHub.
Collect and Analyze the Data
Once the sensor was running, we connected it to a Google sheet. Every time a car passed, the software would write a new line.
To create the charts, we needed to format the data. So we created a new sheet and pulled in the raw data using a =QUERY()
formula. Then we built additional columns using formulas to display the data so it would be easy to create charts.
From there we built a series of pivot tables to create tables including:
- Daily traffic count by direction of travel
- Sum of cars traveling under 25 and over 25, to calculate percentage speeding
- Max speed logged per hour of day
- Sum of cars in various speed ranges by hour of day, to create a stacked bar chart
Now we were ready to create our dashboard. We put some aggregate data on the left column. this included total cars, the 85th percentile speed (a measurement professional traffic engineers use), and percent speeding over certain amounts. We also built a few charts to show daily traffic volume, percentage speeding by time of day, a speed histogram, and the fastest drivers by time of day. A leaderboard (not shown) logged the top speeds by date.
Dashboard showing total cars, 85th Percentile Speed, percent speeding, and several charts.
Finding Errors and Debugging
This sensor setup was a learning experience. A couple bugs along the way particularly stood out to me.
- Asymmetric Traffic Volumes — First, notice the chart on the upper left. The first two thirds of the bars show fewer Eastbound cars than Westbound ones. How could that be? Our study spanned November 2020 to February 2021; we were logging cars in the middle of the COVID-19 lockdown. Could there really be more cars going one direction than another? Perhaps. But it could be something else. When you initiate the Traffic Camera program, you define the monitoring area by putting coordinates in your command. This area shows as green lines on the camera application. When I looked closely, I noticed some Eastbound cars were traveling above that area. So, I re-initiated the program and expanded the coordinates to the area. After this, traffic volumes evened out by direction.
- Full Google Sheets — At first, I checked the camera every day. It was exciting — and infuriating — to see cars logged at 50, 60, and 70mph or more. Over time I grew desensitized to the data to the point where weeks would go by where I didn’t check the dashboard. Once I returned and the charts weren’t showing data at all. The sensor was running and the spreadsheet showed new data being written. I learned that Google Sheets reached its limit and you had to manually add rows to the sheet. Sheets also has a limit of 5 million cells, which we eventually reached. Google Sheets is a good solution to collect data for a few months. If you’re running collection for longer than that, you’ll need a spreadsheet or database that can handle more.
- Really Fast Cars — The sensor captured a few cars driving over 100mph, and even one as fast as 130mph! I believe cars going 70, 80, even 90 because I’ve seen them. Driving faster than that feels implausible. I didn’t take the time to investigate these outliers. Part of me is curious if the sensor became confused. Could it have misread two cars passing by at once? This merits further investigation.
Share Neighbors Stories and the Data
Once our data collection was up and running and we had the dashboard to visualize it, it was time to share our findings with the world. The very first tweet highlighted the first really fast car. We caught someone driving 89mph down our 25mph street! I created a graphic showing the corridor and the figure, and tagged a few local officials:
Later on, I followed it up with a selection of the high speeds logged during the first couple weeks:
Those first tweets didn’t get a lot of attention. We were starting from zero followers. A local advocate I asked for advice recommended we put a human face on the problem by capturing peoples’ stories.
Capturing Stories
Our initial survey asked for residents’ stories about reckless driving and crashes, but those were just text. We needed to grab officials’ attention and encourage them to take action. Thankfully the year-round mild weather in Oakland gave us opportunity to record neighbors outside at a safe distance.
A neighbor and I spent a total of 2–3 hours recording stories from a half dozen people. The interviewees shared about crashes, fatalities, speeding, and reckless driving over the years. I edited these into several videos and social media graphics merging their stories, faces, and our traffic data together.
Fortunately, I possessed the skills needed to present these nicely. I took a video editing class in college and have edited amateur video occasionally through the years. I’ve also produced corporate videos and online announcements while working for a major consumer brand. These are the tools I used to create the videos:
- Descript — This is my secret weapon. Descript lets you edit video clips by editing an AI-generated transcript of the audio just like you would a Word file. Once I had crafted each story by arranging the text, I exported the sequence to Adobe Premiere Pro.
- Adobe Premiere Pro — Adobe’s professional video editing suite comes with Creative Cloud for a monthly fee. I used Premiere to add in the intro and outro graphics, lower-third titles (displaying peoples’ names), and the background music.
- Figma — Figma is a free, browser-based vector drawing tool. I created all of the social media graphics, our logo, and the intro and outro graphics with Figma. This requires a bit of practice. You can substitute this for your favorite graphics tool. Some people prefer Canva, Adobe InDesign, Adobe Illustrator, or even PowerPoint.
Editing the Videos
Descript’s most powerful feature is that it lets you edit video and audio sequences by editing text. So, I took the transcripts and assembled them into five sequences, which became five videos:
- 8th and Center Crash — Two cars in a yard
- 8th and Chester Crash — Two cars hit a four-plex
- Bicycle and Scooter Crashes — Eyewitness stories of crashes
- High Speed Drivers — Clips of reckless drivers with resident comments
- Asking for Solutions — An appeal to city leaders
Once I had assembled the sequences in Descript, then I exported each to Adobe Premiere along with subtitles. There I added the intro and outro images, background music, and b-roll video of speeding cars.
Building Social Media Cards
With the videos transcribed in Descript, I pulled out quotes from the neighbors interviewed. Next, I placed them on graphics in Figma alongside a still image of the person speaking. These became the images for a series of Twitter posts that I posted during the video campaign. I made some cards with images of the car crashes we documented as well.
Sharing the Videos
Finally the videos were ready to share. To get the most impact, I spaced them out. We posted on a Monday, Wednesday, Friday, then the following Monday and Wednesday on our Twitter account and the neighborhood Facebook group. I tagged local leaders in replies and retweets.
Getting Media Attention
My neighbor Tamera (pictured above) works in media relations. She put together a list of local media outlets and reporters, their emails, and Twitter handles. Tamera emailed pitches and I tagged reporters on Twitter. We were fortunate to hear back from local NBC reporter Melissa Colorado, who contacted me and set up the interview for the following day.
Our media tags resulted in two initial interviews: One with Streetsblog SF that resulted in an article, and another with NBC Bay Area. Within a week of posting the videos, our campaign was on the local evening news. Streetsblog SF has since written a follow up piece on our campaign.
What has happened since?
In short, a lot. We’ve made some progress and gotten some attention, but we’ve yet to solve the problem.
After our campaign with videos, social media cards, and media coverage, the city of Oakland started meeting with us. We received some support and background information from Warren Logan, the Mayor’s Policy Director of Mobility and Interagency Relations.
We learned that the city was considering our request for traffic circles and speed humps in their annual Capital Improvement Program, and expect to hear more mid-April. Even if this is approved, it will take another year to see these elements built. So, we’ve switched our message to asking for a less expensive, simpler, short-term fix.
We’ve lobbied our councilmembers at listening sessions for our neighborhood council.
Our campaign was invited to a meeting between our city councilperson and the head of the Oakland Department of Transportation (OakDOT).
We’ve presented our case at the Oakland Bicycle and Pedestrian Advisory Commission (BPAC)’s Infrastructure Committee
Our councilmembers have put forth a revised budget allocating $800,000 from incoming Federal funds for city-wide high priority traffic calming.
How could we improve?
If we were to collect the data and run this campaign all over again, I’d improve a few things.
- First, we could make some of the charts easier to read and introduce more data visualizations. I particularly like the visualizations Adam Balsam used in his entirely different speed camera.
- Second, we could swap out Google Sheets for a database that could handle more records.
- Third, I’d make our Twitter graphics mobile-friendly. I’d mock them up in a simulated Twitter mobile feed to ensure they’re readable in a small format.
- Finally, I’d use a Twitter automation tool. This would automatically retweet our posts to keep our campaign in the front of peoples’ minds over a period of weeks.
What have I learned?
It’s hard to encapsulate everything I’ve learned from building our traffic camera and running our campaign in a few sentences. In short, we never would have gotten the momentum we did had we not built the sensor and collected the data. Data alone wouldn’t have done it either. I learned:
- Data is vital, but it’s just as important to tell peoples’ stories and give the public someone to empathize with.
- Showing the problem beats telling people about it any day. Images of cars crashed into houses and clips of drag racing drivers delivered our point with a punch.
- Even with the most compelling case, getting a resolution will still run at the speed of government.
In short, collecting data is foundational, but sharing stories and showing the problem makes the case.
Visit our website to follow the continued campaign for a Safe 8th Street.