Hacker News Reader

Comment by delecti | Hacker News Reader

To be fair, W3W is already "spheroid-optimized", in that the named squares are quite close to 10'x10' both at the equator and poles. There are grid "skips" (see one here [1]) every so often to keep all of the squares close to the same size.

[1] https://gis.stackexchange.com/a/195696

Also don't discount the benefit of their distribution of the words. If you're using voice input and trying to get somewhere, the system can guess which of multiple inputs you mean. If you're in Louisville Kentucky you're more likely to be trying to get to "captain.water.water" (a ~90 minute drive from downtown) than "captains.water.water" (located on an island in the North Atlantic). Do you have a mechanism (maybe a check digit?) to help with that?

View on HN

WTF?

"captain.water.water" => ~90 minutes from Louisville, Kentucky

"captains.water.water" => island in the North Atlantic

That's crazy. I mean, "..water" should be a contiguous area. With "*.water.water" a contiguous part of it.

Why? You would lose the ability to disambiguate in the way I described. The words aren't coordinates, they're the result of a hash function.

The non-proximity of W3W locations with similar identifiers is intentional; it's meant as an easy way to perform error checking. The concept is that you state your location, and if you state it wrong, or the other person gets it wrong, the mistake will be obvious because the small change to the identifier results in a location extremely distant from you.

The system pretty explicitly considers all squares equal, without a hierarchy such as you envision. There are no identifiers for larger agglomerations of individual squares.

(And more specifically, where identifiers are hierarchical, you generally have the larger scope first, not last. URLs are a bizarre exception.)

OK, I see that.

But (and maybe I'm just too cynical) the huge benefit for W3W is that it's much harder to reverse engineer the identifier-assignment code. So only W3W can generate valid identifiers.

The data files you need to store are fairly small. The bigger problem is people who have done their own imple tstion got threatening legal letters.

Minor nitpick: URLs do tend to be used with the larger scope first (i.e. /resource/child/subchild). Domain names are the odd exception.

HTTP paths are not conceptually hierarchical at all; they're opaque strings.

People set them up that way in practice because they prefer thinking that way. Or, I guess, because they want to sort their URLs meaningfully. Does that happen?

That's a fair point. But the fact is that people do tend to set them up as hierarchies.

But maybe you're right that most people don't understand that, given how adversaries exploit stuff like "games.apple.com.foobar.hosting.tw". You wouldn't fall for that if you understood the system.

While they're not conceptually hierarchical, it's not fair to say that they are opaque strings either. "////" is not a valid HTTP 1.1 path, for example, and "" means "/"

This is a feature not a bug.

If one of the words is slightly wrong, then you want it to be obvious.

If the Kentucky emergency operator adds an extra s they will see that it can’t be right. With the contiguous numbering the ambulance would be close, but probably still unable to find you.

See page 23 of the patent: https://patentscope.wipo.int/search/docs2/pct/WO2014170646/p...

OK. But you need the W3W API to do that. Just by looking at two identifiers, without that, you'd have no clue about where they are.

Reply on news.ycombinator.com