Live data from Hacker News

Open Location Code: An Open Source Standard for Addresses

github.com

91–95 of 95 posts

Re: Open Location Code: An Open Source Standard for Addresses

#91

Earlier quoted context omitted.

Hi - plus codes founder here. You can just keep adding digits and the area gets smaller. The way I think of it is: +XX "house" (13x13 meters) +XXX "bathroom" (3.5x2.8 meters) +XXXX "chair" (87x56cm) +XXXXX "envelope" (22x11cm) In Kolkata the NGO (Addressing the Unaddressed) are using +XXXX codes.

Wait a minute. How are Kolkatans with (probably) cheap phones getting their hands on coordinates that accurate when phone GPS is usually only good to within ~5m?[1] I assume the postal workers are getting high end equipment? [1] "GPS-enabled smartphones are typically accurate to within a 4.9 m (16 ft.) radius under open sky" -- https://www.gps.gov/systems/gps/performance/accuracy/

First guess: Signs, maybe? You only need a few accurate surveyors and they could write coordinates in places. Use the cheap accuracy to get close then follow the signs.

Looking up the charity mentioned, they even have a nice photo of such a sign, so my guess appears validated: https://www.addressingtheunaddressed.org/services

Neat.

Re: Open Location Code: An Open Source Standard for Addresses

#92
post #61

Earlier quoted context omitted.

You are fortunate that lat/long is sufficient for your use-case. In my experience, the problem is that it isn't as exact as you'd think, especially when your measurement passes back and forth between reality, the idealized cartesian lat/long, and node/distance understandings of road networks. At a previous company, our map provider moved the entire United States three meters to the west and we spent the next week re-…

Yeah had that happen on google maps API a few years back where the earth adjusted southeast or something like that... I wonder if the offset you experienced was able to be re-adjusted by calculation or was the new geometry inconsistent? Ive realized we can't ever get exact - best we can hope for is finding something that's constant enough for a long period. So far lat/lon has done best.

In retrospect I also wonder why we didn't just do a bulk update. I think the problem was that we discovered the geocoding problem and started correcting for it before we understood where the problem was actually coming from. By the time we discovered it was a simple constant offset, we'd already damaged our own data with the one-off fixes.

Worse, the offset was right there in black-and-white in the release notes that we failed to read.

By the way, I apologize for being flippant about it. Location is just one of those things -- like time -- that too many people think is simple, but actually has devilish details that bite the unwary. You are fortunate that lat/long is sufficient and I hope you remain wary.

Re: Open Location Code: An Open Source Standard for Addresses

#93

Reinventing UTM/MGRS again, I see. The major problem with these as addressing standards, and with open location code, is that most people do not live or receive mail at a fixed location in the middle of the ocean. Most location codes encode an empty quadrilateral of ocean. Addressing with efficient encoding needs to be dense in cities, and sparse in uninhabited wilderness.

Doing this saves you about two bits worth of information while usually greatly increasing complexity. To see why consider how geohashes work. As you add letters you telescope in to a more precise region. The land/water distinction is less information than even what is encoded by the very first character of your 9 or 10 character geohash.

If one could maintain an index of a single reference point for human settlements, as geodetic latitude and longitude, addresses could relatively reference from a specific center, and include relative waypoints.

us;il;chi = {41.88206,-87.62781} The Chicago base reference point, positive x-axis points to 0 degrees N, positive y-axis points to 90 degrees east.

us;il;chi;0,0 = Madison and State, street level

us;il;chi;-278,+305 = 111 S. Michigan, street level. This is between the lions of the Art Institute. Horizontal offsets are in meters.

us;il;chi;-278,+305>90:165 = east 165m into the museum, over the bridge, into Greek, Roman, and Byzantine art.

us;il;chi;-278,+305>90:165>180:32,+1 = south 32m into the Modern American Art wing, up the stairs one level, in the top level of the 2-level sculpture court. Vertical offset is in building stories.

us;il;chi;-278,+305>90:165>180:32,+1>270:13 = west 13m into gallery 262, home of Nighthawks.

A geohash can tell you where Nighthawks is, in terms of a geodetic location to a certain precision, but it doesn't tell you that it's on the second floor of a building whose second floors don't all connect, or how to get there to see it. If doesn't matter how many extra characters of precision you add when the place you want to be is separated from the locations of the public access points. Addressing sometimes has to include routing information. Complexity is sometimes needed.

The base reference point for Manhattan (us;ny;nyc) could have its reference grid rotated to 29 degrees NNE, but cities without a grid system needn't bother.

Re: Open Location Code: An Open Source Standard for Addresses

#94

Earlier quoted context omitted.

This is why these technologies never get mass adoption; so many solutions duplicating themselves trying to solve the same thing. Fact is, most users would care less about numerous implementation, they need to be educated just one solution which works fine. Personally I find plus.codes from Google user-friendly. They are already integrated in Google Maps which has over 1 billion downloads. They are free and opensource…

As usual there is a relevant XKCD. This time it is https://xkcd.com/927/

That xkcd is very common around here I noticed. We often get brilliant ideas that someone else already had.

Re: Open Location Code: An Open Source Standard for Addresses

#95
post #88

Seems like reinventing a solid wheel with a disposable one... I'm more for Latitude and Longitude: - Latitude/Longitude have been around for a long time, established, proven reasonably reliable. - Ultimate more calculable, no need for lookup/conversion - No language issues (three words seem to be primarily English) also unless it becomes an international standard whats to stop someone making a similar service with di…

I agree, however this and latitude longitude don't fully solve the problem the post discusses. Just because you know where the entrance is, it doesn't describe how to get there. Maybe the area isn't available on mapping services (not that uncommon for small communities, even in Western countries) or maybe you need to take a specific route to get there.

I was thinking that it would be cool to have some AR thing going (ala Pokemon Go - virtual arrow pointing toward the destination) But of course that fails if there is no direct route from where the traveler is.

To get directions working right. I think there needs to be a good open standard for road/pedestrian maps, but that will only be as good/reliable as the data source... Haven't looked into open street maps but I think that would be one to check out.

Post reply on HN