“Approximate Street Address” Doesn’t Do It Justice
Whew! It’s been a while since the last update- don’t worry, I’ve been hard at work learning TensorFlow (and I’ve even contributed to its documentation a touch), and I’ll have a fairly large post later this week. In the meantime, I thought I’d share something I’ve discovered about one of the Santa Monica Parking API‘s fields that I had previously shrugged off as unhelpful.
I was looking through some of my parking data and decided to print some information for all parking meters, ordered by
meter_id, when I noticed something interesting:
Multiple meters were given the same
street_address field. On further inspection, I also noticed that address numbers in the list either ended in 0 or 1. I couldn’t think of a better thing to do than plot some of them on a map and see what I came up with.
First, I picked two group of meters that had similar addresses. In this example, “00 Pico Blvd” and “01 Pico Blvd”.
Here’s the “01 Pico Blvd” coordinates mapped:
And then with “00 Pico Blvd” added in:
street_address is a label for their block! I tested this out with several groups of meters, and found the block-by-block grouping consistent. That makes me comfortable to say this:
street_address Groups Parking Meters Together by Block
There’s your TLDR. Two reasons I’m sharing this today:
- As of writing, that information is not conveyed in the API
- It’s going to save a huge amount of effort when people inevitably want to group these meters together block-by-block
Before realizing this, I was thinking of various way of trying to use a combination of
meter_id and GPS coordinates to try to group these together without doing it manually, but this provides a very natural way to group them! Hooray for the data being even better than first thought!