Utah Addresses Are Cartesian. Google Does Not Grok
Key topics
So here is an actual address, 716 W 630 S, Orem, UT. A person in Utah would expect that incrementing or decrementing either of the numbers in the tuple (-716, -630) would move the point on the map only slightly.
Yes, I am messing up and broke the rules of notation but did this on purpose to force the mind into normal Cartesian thinking. More strictly, I could have said (716W, 930S). But you get what I mean, right?
But try this in maps.google.com. Change the address to (716, 631) and Google says it can't find the address. Change it to (716, 629) and it suggests a bus stop in Salt Lake City. An error of nearly 30 miles.
There is no way to report this misunderstanding to Google.
One could argue Google's approach is correct. Except that, particularly in undeveloped areas associated with a city, people will guess at an approximate address expecting that the hearer will arrive at a location close to what was stated. A bit easier to express that giving latitude and longitude coordinates. But Google takes you to another city?
The post discusses how Utah's Cartesian street addressing system is not well understood by Google Maps, leading to incorrect location results, and sparks a discussion on the limitations and potential improvements of geocoding algorithms.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
18m
Peak period
5
0-2h
Avg / period
2.5
Key moments
- 01Story posted
Sep 26, 2025 at 7:50 AM EDT
3 months ago
Step 01 - 02First comment
Sep 26, 2025 at 8:08 AM EDT
18m after posting
Step 02 - 03Peak activity
5 comments in 0-2h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 27, 2025 at 1:55 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
This problem of street addresses is so deep in the brain that I was making a mistake on purpose to jar the mind of the reader.
So maps will first try to match the entire string entered by the user. Typically, it show a list of possible matches and allows the user to choose one. If there is no match, then the second element of the tuple is chosen and an attempt is made to find this as a name in the street database. But if this fails, maps says what the heck, order does not matter, maybe the first element is the street and looks this up.
In many places, streets are long sections that cross many cities. So Google's street database kind of tosses the city information. So it can end up picking any street that matches either number in the tuple.
Maybe someone has a better knowledge of the algorithm, but this is my best take on it. For Utah, the result is madness.
So I learned something about this when I bought my house. If the second element is a named street, then you're expected to omit the cardinal direction from the first element. So, taking the address in the OP as an example, if 630 S was a street named Foo Boulevard, then the address is correctly written (from USPS' POV) as either 716 Foo Boulevard or 716 W 630 S. Before learning that, I would certainly have written 716 W Foo Boulevard and, indeed, that's what many if not most Utahans expect. (And, actually, including the cardinal direction disambiguates some cases, e.g., State Street. There's a donut shop (best glazed donuts in the valley) at 2699 State Street and the Capitol Building is at 350 State Street. Except the first is S and the second is N, so they're 3049 units away, not 2349.)
Anyway, it's kinda interesting to me because, if I use the former notation of specifying my home address, some navigation systems will put people a couple miles away at some church but it always (so far) works if I use the latter notation. It most recently confused the navigation system a local towing company uses until I gave them the address in the latter notation.
What you're describing is a problem with their reverse geocoding algorithm. It used to be that you could grab the US Census tigerline data, which had every road segment in America along with the starting and ending addresses that were on that road segment, and get a really good location for any American address. But the tigerline data is not updated super duper frequently and your average BigCo wants to serve the whole entire world, so they've all (probably) gone to their own algorithms and data sources, and software engineers love to make assumptions, and... well, you see what happens.
As someone who also lives at an address covered by appendix D, I feel the pain from time to time. Many "we only hire the absolute best" tech companies do not believe my house exists, while all those lame and boring others that just rely on the USPS validator have no problem whatsoever.
[1] https://pe.usps.com/text/pub28/welcome.htm
This makes sense to this life-long Salt Lake Valley resident (unless you specified Orem in your query) because the grid in SL County doesn't extend past county lines. The grid in Orem doesn't even go that far: off the top of my head, Provo uses a different grid even though they're both in Utah County. If you just entered "716 w 629 s utah" without specifying a city, I'm not at all surprised that it put you in SLC because that's in SLC. It's also in Orem but it makes more sense (IMO) for Google to assume SLC if a city is not given.
The public library in SLC is between 200E - 300E and 400S - 500S (most things don't take up a square block, which is why I specify that it does), which would put it just a few blocks away from that address in Orem (716W 630S) but it's actually 30 miles away in SLC. (Its mailing address appears to be 210E 400S.)
FWIW, I read once that 8 city blocks (e.g. 100E to 900E) is a mile, which tracks with my own head-arithmetic when I want to "verify" if the distance the map gives me is accurate. I doubt it's exactly precise but it's pretty close, generally.
The units of distance from the origin can vary. City blocks were typically smaller than county farm parcels. So if you are writing a program, you need to look up the units of distance.
Again, this is a real mess in Salt Lake City where the initial smallish city merged with the farm areas south of the urban center.
I was born in California and moved to Utah as an adult. The addressing system was incomprehensible at first. In Los Angeles when I was young, my father, a salesman, kept several huge map books in his car. The usage of these was first to look up a street name in an index section and then go to the correct page in the book. Then hunt for the street in the square specified in the index.
There were no such books in Utah. The geography is desert and mostly flat. The Cartesian system mostly works. There are some exceptions particularly as you get close to the mountains. In these cases, one would have to do the California thing. The map you would need used to be in the phone book. So typically you would hunt first for a phone booth.
But this was a long time ago. There are no phone books anymore. And certainly no phone booths. So this is a cultural shift in multiple dimensions.
Salt Lake City is a royal mess. What started out like LA with separate cities have now merged into a contiguous urban area. The origin in cases like this is the county center. So sometimes you can reference the original city coordinates or go with the newer unified system.
But still there is this disconnect in the ways that people think about street addresses. There are deep thought patterns that depend on where you were born.