Santa Monica Parking Meter API: “street_address” Field Is More Useful Than It Appears at First Glance

“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:

The 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:

  1. As of writing, that information is not conveyed in the API
  2. 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!

Leave a Reply

Your email address will not be published. Required fields are marked *