Utah addresses are Cartesian. Google does not grok | Hacker News Reader

Utah addresses are Cartesian. Google does not grok

2 pointspesoneto10 comments

Utah street addressing is Cartesian. The only difference is that instead of using a pre-fix notation of plus-minus to indicate a direction from the origin, the post-fix notation North-South, East-West is used instead.

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?

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.

> By convention in Utah, the first tuple element is the house number and the second element is the street.

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.

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

Yes, that is what I said in the next sentence. I was playing around, trying to make sure that people think. Like you did!

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.

I also notice that your username is Uber Man. You probably have some stories to tell about navigation and getting lost.

Reply on news.ycombinator.com