I have a friend on the google maps team and we had a brief conversation about this library a few weeks ago while I was helping him out with some projects at home.
If I remember him correctly, this project started off as a 20% time project of just one employee. The more amazing part was it sounded like that employee had been working on the problem, largely by himself, for near a decade.
And now this project, started by one guy, is in production use for an application hundreds of millions (if not billions) of people use daily. All because he just kept working on it. Inspiring.
I'm not sure if that's the best way to describe it. That one employee was Eric Veach, who led the creation of this auction system called AdWords. Then he wrote the first version of SmartAss, the ML system that predicts CTR for AdWords and AdSense. S2 comes from his background in graphics. He had joined from Pixar and won a couple of Oscars. (There's actually someone else at Google who has won more.)
Yes, it was mostly one employee, but it wasn't an ordinary one.
I was playing around with s2 a year or two ago, and it was surprisingly difficult to find information on it, so FWIW here are some links I was able to find at the time if you're looking for some historical reading on s2:
When I was working at Google in 2005ish it was briefly my job to port Dodgeball(1) from an existing PHP codebase to Java on Google infrastructure. It was SO NICE that this library already existed. It made a decent chunk of my work significantly easier.
I didn't know much about S2 geometry before I discovered the library. It was a lot of fun to dive in and learn how it all worked.
from my understanding, H3 doesn't guarantee that a child cell falls strictly inside the geographical region of its parent (since is a hexagon cannot be perfectly comprised of smaller hexagons).
While the hexagon has less distortion - we loose some of the nice child <> parent guarantees that S2 offers in my experience.
Hexagons are all equidistant from their neighbors and all share the same size edge with all neighbors. This allows you to do cool stuff like k-rings. These properties are useful for all sorts of reasons.
With S2 cells there are two different distances to neighbors at the corners vs the sides and the neighbors at the sites have long borders and neighbors at the corners have vertice borders.
Both S3 and H3 are useful, but for different reasons. It's worth knowing the benefits and tradeoffs of both and choosing the solution that fits your particular problem.
H3 uses Buckminster Fuller's Dymaxion project and puts the 20 pentagonal vertices all in the ocean. I'm not sure the impact of this for maritime usage and I'm not sure if there is yet a different orientation that puts all vertices on land, so you can use it for maritime usage without having to concern yourself with these vertices.
Quick note that may be of interest: S² is the mathematical notation for the "2-sphere", aka what we call a sphere in everyday language. I suppose that's explained by this:
> A unique feature of the S2 library is that unlike traditional geographic information systems, which represent data as flat two-dimensional projections (similar to an atlas), the S2 library represents all data on a three-dimensional sphere (similar to a globe).
(S^2 if the superscript character doesn't show up for you.)
I'm still puzzled why they went with 6 quad-trees, instead of doing an equal-area projection with 2:1 ratio and quad-treeing that instead. You lose a bit for half the map but you do with 6 sides too (takes 3 bits).
Somewhere there's an older doc/presentation that goes into the reasons for the cube in more detail, and if I remember where it is, I'll post it here later.
Consistent uniform cell size, minimizing distortions and relegating them to remote parts of the ocean, grouping land masses together (one cube side is almost pure ocean), optimizing for geodesics, and making it easy to index and reason about were some of the considerations in the design decision. It's been a while so I'm little fuzzy on all the reasoning, but I'm sure someone else on here can provide ptrs or fill in the details.
I reckon an equal area projection for a full hemisphere would lead to some unacceptable degree of distortion. It's hard to say exactly but it shouldn't be too difficult to see that a cube is closer to a sphere than two squares stuck together.
Edit: it may also be easier to figure out which squares are adjacent when using a grid based on a cube.
Yeah I guess it depends on what you're trying to optimize (they use web mercator because roads didn't meet at right angles up north for example). But if you're mostly interested in indexing physical areas with polygon approximations, it seems like having each cell be the same area would be the ideal, but idk.
Readit News
If I remember him correctly, this project started off as a 20% time project of just one employee. The more amazing part was it sounded like that employee had been working on the problem, largely by himself, for near a decade.
And now this project, started by one guy, is in production use for an application hundreds of millions (if not billions) of people use daily. All because he just kept working on it. Inspiring.
Yes, it was mostly one employee, but it wasn't an ordinary one.
http://graphics.stanford.edu/papers/veach_thesis/
(I forgot: he was also behind jump consistent hashing)
Almost all modern ray-tracing engines (e.g. Indigo) rely on that technique these days.
And yeah, all the other things he did at Google.
Not your run of the mill engineer, by a very large margin.
Google Presentation on S2: https://docs.google.com/presentation/d/1Hl4KapfAENAOf4gv-pSn...
Christian Perone's blog post on it: http://blog.christianperone.com/2015/08/googles-s2-geometry-...
Google Code Archive: https://code.google.com/archive/p/s2-geometry-library/
Java Implementation: https://github.com/rschreijer/s2-geometry-library-java
I didn't know much about S2 geometry before I discovered the library. It was a lot of fun to dive in and learn how it all worked.
Nice to see that it's all open sourced now.
1. https://en.wikipedia.org/wiki/Dodgeball_(service)
For less distortion, it uses hexagons.
While the hexagon has less distortion - we loose some of the nice child <> parent guarantees that S2 offers in my experience.
With S2 cells there are two different distances to neighbors at the corners vs the sides and the neighbors at the sites have long borders and neighbors at the corners have vertice borders.
Both S3 and H3 are useful, but for different reasons. It's worth knowing the benefits and tradeoffs of both and choosing the solution that fits your particular problem.
H3 uses Buckminster Fuller's Dymaxion project and puts the 20 pentagonal vertices all in the ocean. I'm not sure the impact of this for maritime usage and I'm not sure if there is yet a different orientation that puts all vertices on land, so you can use it for maritime usage without having to concern yourself with these vertices.
> A unique feature of the S2 library is that unlike traditional geographic information systems, which represent data as flat two-dimensional projections (similar to an atlas), the S2 library represents all data on a three-dimensional sphere (similar to a globe).
(S^2 if the superscript character doesn't show up for you.)
Deleted Comment
Somewhere there's an older doc/presentation that goes into the reasons for the cube in more detail, and if I remember where it is, I'll post it here later.
Consistent uniform cell size, minimizing distortions and relegating them to remote parts of the ocean, grouping land masses together (one cube side is almost pure ocean), optimizing for geodesics, and making it easy to index and reason about were some of the considerations in the design decision. It's been a while so I'm little fuzzy on all the reasoning, but I'm sure someone else on here can provide ptrs or fill in the details.
Edit: it may also be easier to figure out which squares are adjacent when using a grid based on a cube.
https://github.com/google/s2geometry/