Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Harder, Better, Faster, Stronger Version of Uber H3 in Rust

grim7reaper.github.io

Post reply on HN
Print view View original

31–40 of 43 posts

Re: Harder, Better, Faster, Stronger Version of Uber H3 in Rust

#31

Post by ajfriend »

grim7reaper wrote: post #5

Author here! Funny to see this on the front page xD That was the blog post for the initial release, and a lot of things have changed since then (definitely deserves a new blog post ^^). The first big change happened six months after the release, when I rewrote most of the geometrical algorithms (leveraging the excellent geo crate) and got a massive boost in speed and reduction in memory usage which made it applicable…

h3o-zip is really impressive! I've been wanting to play around with it more, and I've been meaning to ask you if you have any good references for that encoding approach. I understand how it works in h3o-zip, but I'd be interested to know more about where else that approach has been used.

Re: Harder, Better, Faster, Stronger Version of Uber H3 in Rust

#32

Post by seanlane »

jiggawatts wrote: post #13

I never understood why anyone would prefer the H3 hex tiles over Google’s much simpler S2 system: http://s2geometry.io/ Sure, hex tiles make certain circular nearest neighbour searches slightly more accurate… but still have an error. And then… everything else that’s inconvenient with hex tiling, like that issue that subdivisions of a cell leak into the neighbouring cells and hence don’t add up to 100% of the parent!…

Some of the original developers of H3 gave a presentation about it that goes over the tradeoffs between those different systems, would recommend watching it.

https://www.youtube.com/watch?v=wDuKeUkNLkQ

Re: Harder, Better, Faster, Stronger Version of Uber H3 in Rust

#34

Post by brookman64k »

jiggawatts wrote: post #13

I never understood why anyone would prefer the H3 hex tiles over Google’s much simpler S2 system: http://s2geometry.io/ Sure, hex tiles make certain circular nearest neighbour searches slightly more accurate… but still have an error. And then… everything else that’s inconvenient with hex tiling, like that issue that subdivisions of a cell leak into the neighbouring cells and hence don’t add up to 100% of the parent!…

It also uses pentagons in some places because a hexagonal grid can‘t tile a sphere. They made sure that the pentagons are located in water, but this feels like it will add even more edge cases to handle.

Re: Harder, Better, Faster, Stronger Version of Uber H3 in Rust

#35

Post by pheelicks »

jandrewrogers wrote: post #26
mattrighetti wrote: post #19

TIL! What are the advantages of hexagonal spatial indexing compared to e.g. quad trees, r-trees?

The main advantage of hexagonal spherical tiling systems is that they are roughly equal area at a given resolution. This makes them particularly suitable for generating visualizable aggregates when you primarily care about spatial distribution rather than specific boundaries (like borders). The main disadvantage of non-congruent tiling systems like H3 is poor scalability and performance when running analytical comput…

It is a common misconception that h3 is equal area. At any resolution level the cell size varies by a factor of 2, which is (roughly) the same as S2.

See the following visualizations for an illustration:

https://a5geo.org/examples/area

https://a5geo.org/examples/airbnb

Re: Harder, Better, Faster, Stronger Version of Uber H3 in Rust

#36

Post by killme2008 »

grim7reaper wrote: post #18
websiteapi wrote: post #7

who is using uber h3 and what for? (besides uber of course)

amo is using it quite a lot, mainly for the scratch map feature in the Bump Map application, but not only. Use cases are: - data storage - data aggregation/clustering - spatial indexing - geometrical computation (as long as you're OK with approximation, you can speed up a lot of things by working with CellID instead of actual geometries) - data visualization I've seen it used by Databend, Helium, Breakroom (they did…

Hi. I am from GreptimeDB team. We use h3o library to implement h3 functions:

https://docs.greptime.com/reference/sql/functions/geo/#h3

These functions encode and decode latitude/longitude to H3 cells and provide utilities for querying cell properties, neighborhoods, distances, and relationships.

Re: Harder, Better, Faster, Stronger Version of Uber H3 in Rust

#39

Post by chillchilla »

jiggawatts wrote: post #13

I never understood why anyone would prefer the H3 hex tiles over Google’s much simpler S2 system: http://s2geometry.io/ Sure, hex tiles make certain circular nearest neighbour searches slightly more accurate… but still have an error. And then… everything else that’s inconvenient with hex tiling, like that issue that subdivisions of a cell leak into the neighbouring cells and hence don’t add up to 100% of the parent!…

S2 is attractive, but the corpus of use cases outside the Pokemon Go community is quite small. The sheer number of companies and hobbyists using H3 for analytics across a wide spectrum makes it much more attractive than S2. H3 functions are built directly into Snowflake DB for example, and h3 extensions / plugins are widely available. I tried and tried to use S2 in my company but the lack of available use cases and examples made it tough to adopt.

Re: Harder, Better, Faster, Stronger Version of Uber H3 in Rust

#40

Post by grim7reaper »

ajfriend wrote: post #31
grim7reaper wrote: post #5

Author here! Funny to see this on the front page xD That was the blog post for the initial release, and a lot of things have changed since then (definitely deserves a new blog post ^^). The first big change happened six months after the release, when I rewrote most of the geometrical algorithms (leveraging the excellent geo crate) and got a massive boost in speed and reduction in memory usage which made it applicable…

h3o-zip is really impressive! I've been wanting to play around with it more, and I've been meaning to ask you if you have any good references for that encoding approach. I understand how it works in h3o-zip, but I'd be interested to know more about where else that approach has been used.

I’m pretty sure the approach isn’t that novel, but I really rediscovered it on my own while exploring several compressions approaches (generic compressions with tailored dict like zstd, integer packing/compressions, compressed bitmap, …: I probably have my notes about these somewhere)

As such, I don’t have any name/papers to give you nor point you to similar application. But I would also be interested ^^

But don’t hesitate to reach out if you work on something similar and wanna discuss about it.

Post reply on HN