Utah addresses are Cartesian. Google does not grok

After I posted this, I checked the definition of grok to make sure of my usage. Grok is a word invented by Robert Heinlein to describe the experience of a person moving from Mars to Earth and the subtle cultural shocks experienced. This word fits this situation exactly.

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.

> But Google takes you to another city?

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.

Utah/Salt Lake City is covered under appendix D of the US Postal Service addressing standards (unusual addressing situations) [1].

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

Just to be complete, in case anyone pays attention to this and uses it as a specification in a program, there is one more wrinkle.

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.

How can such a delightful article only have 2 upvotes? (One of which is mine.) I had no idea that such an addressing scheme existed, nor that it was so nicely documented by the USPS. Thank you OP!

My understanding of the Google algorithm is that it is based on named streets. By convention in Utah, the first tuple element is the house number and the second element is the street. But because each element has a post-fix identifier, the order does not matter except for the convention.

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.

Do you mean "Change the address to (716w, 631s)"?