open-location-code VS s2geometry

Pluscode is a trademark. The actual standard is called "open location code" and is unrestricted - https://github.com/google/open-location-code/

Yeah, that seems like a bad design choice. If you look at the spec [0], you can see that they only use "23456789CFGHJMPQRVWX" in the codes. They apparently scored the letters based on how well they can spell 10000 words in 30 languages, without thinking about character similarity. If they had involved actual humans instead of counting letter frequency, they might have noticed that the letter W looks similar to VV, and that its English name is "double U". And tried a letter like N or Y, which would be much harder to confuse.

[0] https://github.com/google/open-location-code/blob/main/docs/...

Lots of thoughts from the founders incl comparison with other systems here: https://github.com/google/open-location-code/wiki/Evaluation-of-Location-Encoding-Systems

It's licensed Apache 2.0 https://github.com/google/open-location-code

I wish https://plus.codes/ took off. The benefit compared to what 3 words is that you can use the closest city to give directions and cells next to each other share the bigger cell name.

And an additional shoutout for https://plus.codes/ from Google.

New to this so sorry if this is stupid. I've been trying to use https://plus.codes to try to check an address for availability at starlink. Whatever code I put in, it simply tells me afterwards "please enter an address or a plus code". That website seems to give me either a shorter or a longer plus code. Neither of them seems to make the starlink website happy. When I try putting in the address, it doesn't like that either. Confused on where to go from here.

I experimented with geospatial Hilbert Curves as a Postgres extension [0] for PostGIS using the S2 [1] spherical geometry library. S2 uses a scale free cell coverage pattern that is numbered using six interlocking space filling Hilbert Curves [2].

By having both high level (cell) and low level (cell id) geometries it was a very powerful library which allowed projection from the hilbert space into a Postgres spatial index (spgist) including various trees, like noted in this article. It appears to be still quite active in development.

[0] https://github.com/michelp/pgs2

[1] https://s2geometry.io/

[2] https://s2geometry.io/devguide/s2cell_hierarchy

If you check the h3geo comparison page, you should see plenty of alternatives to geohash, such as s2 or even h3 itself.

See some discussion I started at https://github.com/google/s2geometry/issues/190

> It was quite hard for me to find open-source implementations of linear quadtrees.

You probably know this, but the S2 library has one: https://github.com/google/s2geometry

https://s2geometry.io shows how this works

If your points are distributed globally, however, I'd suggest using something like s2geometry (calculates over a sphere instead of an ellipsoid which is much faster + already has something called S2ClosestPointQuery).

Some alternative solutions are S2 from Google and H3 from Uber. These don't have the same issues as geohash because they work on a 3-d model of the geoid and not a 2-d cylindrical projection like Geohash.