The other day I worked on a project at work that I found really exciting, and I wanted to talk about it here.
My coworker was working on a project to identify how garbage routes affect transit reliability. As part of that, they needed to assign each bus stop to a trash pick-up day. [1] They started with a shapefile published on the City’s website, but it didn’t work for bus stops that were on the borders of two zones.
For those, they needed to use the City of Philadelphia’s trash and recycling day tool to identify the correct day. This was really labor intensive, but I started asking them about it and figured that this could probably be automated with some API calls. I had them export the list of 500 bus stops that were on the border of two zones and I got to work.
Using my knowledge of front-end from my days as a junior engineer, I tracked down the API that was used to fetch this data.
Looking at the response, it looks like the value for the garbage day was stored in “rubbish_recycle_day” and “secondary_rubbish_day”. The second value is for parts of the City that receive twice weekly pickup – most have trash pick-up once a week. For those areas, the value of the second field is blank.
This seemed promising. One hiccup – our bus stop data doesn’t have addresses, just coordinates. I poked around the addresses API reference, and was able to find another endpoint (Search) that accepted coordinates and returned an address using a reverse geocoder. However, this end-point did not return the trash and recycling day, and the addresses it returned did not appear to work for the end-point (Addresses) that actually contained the trash/recycling day.
I tried finding another reverse geocoding solution, but many were blocked on the network or required some sort of license. I ended up using ArcGIS Pro’s built-in reverse geocoding tool based on a recommendation from Microsoft Copilot.
Initially, I was nervous about this solution because of the credit usage, but with 500 stops and a one off request, I figured it was worth saving time by using it. That got most of the locations. I then wrote a quick script in Python to call the addresses API. It did not require an API key but was slooooow. 500 addresses took about 3.5 minutes. But it did work! Which was very exciting and I was very proud of it.
Most of my work these days is more collaborative and administrative than solving specific technical problems. This was really exciting because I got to exercise skills I hadn’t used in a while and want to use more.
Specifically, it was exciting to
- use my technical skills to conduct novel, valuable and challenging analysis (figuring out which bus stops apply to each stop)
- that can be used to deliver insight (correlating delay to trash pick-ups and by extension the cost to us and to City residents of current trash operations)
- and hopefully advocate for a solution that improves life for everyday people (changing trash times, changing routes so that they don’t intersect with buses during peak hours, etc).
Epilogue
They then pivoted to trying to do it for every bus stop in the system (since their team figured that the shapefile we were previously using might not be accurate). We couldn’t reverse geocode all 13,000 stops with our credit allocation, so I tried finding another way. I reasoned that the data that tells you what trash day corresponds to each address had to come from somewhere, so I asked a friend at the City if we could access to the base dataset. Unfortunately, he couldn’t track it down. He did tell me about someone who could help, but at that point my coworker’s team had pivoted to something else.
[1] Actually, they started by trying to assign street segments to the correct garbage zones, but then we realized we really just cared about the bus stops, and it was much easier to think about those than try to first assign the segments, and then the corresponding bus stops.