The linked presentation slides give a bit better explanation IMO: <a href="https://docs.google.com/presentation/d/1Hl4KapfAENAOf4gv-pSngKwvS_jwNVHRPZTTDzXXn6Q/view?pli=1" rel="nofollow">https://docs.google.com/presentation/d/1Hl4KapfAENAOf4gv-pSn...</a><p>Too bad there aren’t more general docs for the library.<p>I still don’t quite understand the benefit of using a single number instead of a pair of numbers for describing a cell in a two-dimensional space. Seems like a pair of 32-bit fixed point numbers would be just as descriptive as a single double-precision float along the hilbert curve.<p>The way they project the sphere onto a cube also leads to cell shapes that aren’t especially relevant to typical human purposes, whereas there are many shapes on a map which align with the latitude/longitude grid.
Correct me if I'm wrong but isn't locality unidirectional? Two close points in the plane might by chance be encoded far away on the line if they're unluckily next to a seam.
Would someone please explain to me how you one convert between the 1D and 2D coordinates of a Hilbert curve? Is there a formula for it? The drawings look nice but they don't tell you how to actually do the conversion, which seems to be the crucial piece of the data structure.
Is it faster for spatial queries to store the S2 cells in a Btree index in a database like the article mentions or to just use something like PostGIS with its gist spatial indices -- specifically, for determining whether points are inside or outside of a polygon?
I think this is also a great example how Google abandoning the Google Code will affect the availability of previously published work.<p>What I want to tell is that this library is not (yet according to some googling) migrated to the new platform even when it is from people from Google.
There's also a Go port of S2: <a href="http://godoc.org/github.com/golang/geo/s2" rel="nofollow">http://godoc.org/github.com/golang/geo/s2</a>