Hacker News Reader

> Half the "namespace" of nearly every coordinate system is biased toward the poles. The distance between 89° N, 10°W, and 89°N, 10°E is 38km, but at 1°N, it's 2226km. My system has a simple and clever way to equally represent the dense equatorial regions and the sparse arctic and antarctic regions, and that equals shorter codes.

The "S2" geometry system (http://s2geometry.io/) is what Google Maps and many other large systems use. It has a small bias towards the poles in terms of some S2 cells being slightly larger than others at the extremes but the bias is pretty minimal.

Another system, Uber's H3 (https://eng.uber.com/h3/), handles this problem in an even better way, although it loses some of the benefits of S2, such as having fine-grained cells no longer exactly fitting into their parent cells. It has other benefits however.

One thing missing from all of these system, including W3W, is that none of them have a height component. If I go to a party in a strange condo and need to call for an ambulance, there is a huge difference between being on the first floor and the fiftieth floor of the same building and W3W does nothing to solve this problem.

The "Z" dimension is something I've been planning on having as part of the system as well.

Since people appreciate height from street level differently than raw altitude, both will be accommodated in my system.

Interesting idea. How do you plan to implement Z and up to what height/depth?

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?

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.

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.

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 Mercator projection is often held to be an imperialist distortion of the globe, and that's what traditional latitudes and longitudes use." There is a difference between a projected coordinate system (like Mercator) and geographic coordinate systems. In Mercator you use projected Mercator-Meters not Latitude and Longitude. All you need to know for local R² (2D Euclidean) estimates, is that longitudes scale with cos(latitude), that's it. How does your system handle 89°N 0°W, and 89°N, 180°W ? Does it infer 222km or 346km? If it's the latter, it's not spherical as in S².

There is quite a body of research into equal-area hierarchical partitions of Sphere. Adressing there is mostly neither trivial nor intuitive and also not compatible with most raster data formats when it comes to storage.

Discrete Global Grid System (DGGS, Pyxis), HealPIX, H3 as variant of DGGRID, EQ_REGIONS, just to name those I remember.

So I'm watching ;)

What benefit do you have over Plus Codes (https://plus.codes/)? I only learned about them from this thread, but they seem to solve the problem quite well, and there's no premium component.

Plus Codes have little application outside building addressing. If I tell you I'm at 4CFM+JW, come get me, you're going to be pretty helpless, because I didn't include the city.

Want to shift a little to the east? 4CFM+JX works, but 4CFM+JY? Whoops. How about north or south? Maybe there's a way to do that, but I haven't found it yet.

How about upping the precision? The size of the square is maybe 4X the W3W grid cell, but not aware of a way for plus codes to achieve a smaller cell.

I'm not out here to bash everybody else's solutions. They're all pretty good, particularly when you limit them to particular applications. Mine just happens to be a slightly improved approach, and slightly less full of drawbacks than everybody else's.

TL;DR: see [3] for an overview of how plus codes work.

-----------------

>Plus Codes have little application outside building addressing.

This claim needs some arguing.

>If I tell you I'm at 4CFM+JW, come get me, you're going to be pretty helpless, because I didn't include the city.

So why would you tell me that? Either include the city, or use a longer plus code that includes the city.

Example from the spec[1]:

>>Nairobi Youth Sports Organization and Information Centre in Kibera, Nairobi, has the Open Location Code "6GCRMQPX9G". Using the location of Nairobi, the code can be shortened to "MQPX9G".

>How about upping the precision?

Use longer codes! It's all in the spec[1]. Again, quote:

>>Using a single grid refinement step, we have an 11 digit code that represents a 1/32000° by 1/40000° area (roughly 3.4 by 2.7 meters at the equator).

Now, regarding this:

>Want to shift a little to the east? 4CFM+JX works, but 4CFM+JY?

This is by design; some symbols were omitted to avoid having words in codes (which, as TFA discusses, can be problematic, e.g. some places might not be happy with codes that have EVIL in them).

>Maybe there's a way to do that, but I haven't found it yet.

The spec[1] is open, and it's all in there!

It is not as simple as what you expected, due to the design constraint above. But that is a tradeoff that I think is reasonable. After all, these addresses are going to be punched into a computer anyway.

E.g. play with the addresses here[2].

I'm really excited to see more development in this space, because one size does not fit all. However, it's important to know what existing systems get right too.

(E.g.: English W3W looks like way easier to say on the phone).

Disclaimer: I work for Google/Geo, the opinions expressed here are mine, and not of my employer.

[1]https://github.com/google/open-location-code/blob/master/doc...

[2]https://plus.codes/map

[3]https://plus.codes/howitworks

>So why would you tell me that? Either include the city, or use a longer plus code that includes the city.

Or I could just use a system that doesn't have that drawback. Plus codes aren't awful. I just find room for improvement.

> This is by design; some symbols were omitted to avoid having words in codes (which, as TFA discusses, can be problematic, e.g. some places might not be happy with codes that have EVIL in them).

So what you're saying is only an open source project could deal with this level of potential offense. I'll agree with that. People who don't like EVIL could add more precision to make EVILGH.

>Or I could just use a system that doesn't have that drawback.

Which drawback? All systems have the drawback that if you don't say the entire address, you don't get the entire address.

>So what you're saying is only an open source..

I was not talking about that (for that matter, plus codes are free/open source). I was just explaining why you ran into this problem: "4CFM+JX works, but 4CFM+JY?". It wasn't obvious to me why "Y" is not a valid plus-code character either until I read the spec.

> Mine just happens to be a slightly improved approach, and slightly less full of drawbacks than everybody else's.

Honest opinion: it is not. Plus codes is the one that has least drawbacks and most advantages.

I have a real problem with people giving dishonest opinions, so good on you.

But seriously, you haven't seen it yet. Ever read Green Eggs and Ham?

8GC2CMXR+X63 is a global plus code with 3x3m precision.

I'm no expert but regarding your question on precision: afaik the longer the plus code is, the more precise it gets

> My system has a simple and clever way to equally represent the dense equatorial regions and the sparse arctic and antarctic regions, and that equals shorter codes.

> With pencil and paper, you'll be able to figure out how to go N, E, S, W by X distance by adjusting a particular character.

Topologically speaking, I am intrigued :)

You have to call Google for Analytics pricing when you outgrow the free tier. And no, we could not afford it.

But at least they tell you that it starts at $150K/year so you know right off the bat if it's even in your ballpark. A lot of SaaS products completely hide thier pricing entirely. I have zero interest in sitting through some sales-bro's phone pitch before I know if I'm even in the right pricing bracket. Nothing like sitting through an hour long preso only to find out afterwards something is 10x what you were looking to spend.

Do they now? They certainly didn't at the time a few years ago.

I at the time found some prices online searching around but nothing from them.

We were very hopeful we'd get some sort of discount because we're in educational tech, so our income per user is very low, but nope. Free to $100k overnight is insane. We’ve got a guy whose full time job now is basically developing analytics tools for us and it’s a cheaper solution.

Back in the day you you didn't have to pay if you ran a Google Ads campaign. There was no minimum spend. If you ran a monthly AdWords campaign for $1/mo you got free GA no matter what your traffic level was.

The main catch is that GA goes to "sampling mode" once your traffic gets high enough, and I think you have to pay extra to get full datasets.

It is actually a form of "foot in the door" https://en.wikipedia.org/wiki/Foot-in-the-door_technique.

If you see a high pricing on their webpage you might go away immediately. But if you make the effort to calling them, you are already committing yourself and you are more likely to accept a higher price than you would have if it was easily accessible.

Not a marketing person, but there also has to be value in the lowest possible bar to begin participating, and then a higher one later to increase engagement with public price menus. "Call now for sales pitch" is not that: it means secret deals and whatever they can haggle out of you.

Look, even this dinosaur got it right: https://azure.microsoft.com/en-us/pricing/details/api-manage...

You are absolutely right, there is actually a whole panel of different techniques that aim at getting you accept offers you would not accept straight on.

I believe as a consumer it is important to be aware of those different manipulation techniques so you can step back and take a rational decision.

For example in case of call for sale, it should trigger an alarm telling you to walk away. If you have a high interest in the product and want to call anyway, make sure to know what price you are willing to pay BEFORE calling and do not commit to anything during the call.

TBH though:

- You are WAY underestimating modern Microsoft, they may be a dinosaur in that they are a relatively old company but they are definitely still one of the bigger predators around.

- Not every business has the same target audience. Some companies desire "everyone" and will make the barrier as low as possible; some companies will purposely target only those customers with the money and commitment to call a sales team and will not make the effort to support customers who are not worth the attention.

Sounds cool, but W3W solves a few different problems. It's got to sound natural, be easy to recognize by various voice systems, and easy to communicate between people.

"12 character code" might solve the problem from your perspective, but the point is that barcodes and IDs are annoying to read and copy by hand.

I thought this was a wink and a nod to just using standard latitude/longitude. Doesn't lat/long naturally solve each of your bullet points?

•Length-optimized. More digits = more precision, check.

•Precision optimized. Except for adding zeros, check.

•Precision-focused. Sig figs cover this.

•Logic-optimized. Adding or subtracting to lat or long respectively.

•Spheroid-optimized. I believe this applies to latitude and longitude, as well, since there's less surface area for a given coordinate space. Though, maybe it's the reverse, that it's more precise at the poles.

They do speak of characters, which then starts to just sound like https://plus.codes

Does it account for geological drifting? This is probably the most important social issue with these kind of systems.

Not OOTB, but I would imagine that any geocoding system could include a suffix, like "(1987)", to know which dataset to use, so as long as there was a server providing accurate geocoding for a particular point in time.

This is a service-related question, though, not a method-related question. There's no math equation that'll tell you your house is there when it used to be here.

...Which defeats the "simple" in 3-words pitch.

"No, I'm `heartfelt-triple-coma` from 2003, not current. Oh, you're using a Spanish-language phone; I don't know which dataset you use."

The formula might not be elegant, but if you have an exact description of tectonic drift, you can absolutely have a code that refers to a fixed location on its plate, rather than to a point on some imaginary sphere.

GPS coordinates are just one possible solution, there's no reason to consider equivalent encodings of the same values as the only alternatives.

> The formula might not be elegant, but if you have an exact description of tectonic drift, you can absolutely have a code that refers to a fixed location on its plate, rather than to a point on some imaginary sphere.

Sure, but (1) is there a good way to get an exact description of tectonic drift?, And (2) does tectonic drift account for all shifts of surface features (intuitively, it would not necessarily for features not fixed to bedrock, which accounts for a very large share of interesting-to-humans features)?

Geographers already have a system for recording positions relative to continental plates - in Europe that means ETRS89 [1], North American NAD-83 [2], Australian GDA94 and so on.

Of course, getting all software to support multiple datums might be a complicated matter, as 98% of things like online slippy maps and mobile phone geolocation APIs just use WGS84, the familiar datum used by GPS.

[1] https://en.wikipedia.org/wiki/European_Terrestrial_Reference... [2] https://en.wikipedia.org/wiki/North_American_Datum

(1) By measuring the location of a few designated landmarks, it should be possible to extrapolate tectonic-level shifts to all other points on the same plate pretty accurately.

(2) Changes on a smaller scale, e.g. due to a landslide, are probably less surprising when they cause a change in location codes. On the other hand, there might be some houses on a hill somewhere slowly sliding down, where the system doesn't work.

(I also realized that my previous comment can be read as supporting a flat earth theory, especially the part about the sphere being imaginary. I firmly believe that the earth is a bumpy ellipsoid, though.)

> By measuring the location of a few designated landmarks, it should be possible to extrapolate tectonic-level shifts to all other points on the same plate pretty accurately.

I would think you'd need a lot of targets near plate boundaries (where deformation is high for that reason) as well as in known regions of intraplate deformation.

Fully accurately, you'll only be able to get retrospective locations (and probably some interpolation thereof), for pretty much the same reason that I can't actually tell you for sure exactly how many seconds the next decade is going to have. We won't know how many leap seconds it has until it is over, or the standards body commits to including no more. But I can tell you exactly how many seconds there were in 2000-2009 inclusive.

Your first four points basically describe lat/lon. But it is hard for humans to parse long characters/numbers. And it's even more difficult to speak random characters. E.g. "B" "b" "be" "bee" are all spoken the same. That's why we use something like the NATO Phonetic Alphabet.

this is way off topic but try buying Google Marketing Cloud services. you have to fill out a 'talk to sales' form, no one ever calls you back, and if you call/chat with any other type of support they have zero idea who to connect you to.

Google is not exempt from this type of behavior, unfortunately.

You should check out what we're working on at qalocate.bamsaas.com/whitepapers/. Even an improvement on W3W is still going to be rather limited and only address part of the problem. We're trying to provide solutions for the entire space.

> "I'm preparing my own version, truly open source (though with a premium component), with the following improvements over W3W:"