OpenLayers3 VS h3

You probably know this, but in Google Maps at least, you can use browser zoom (ctrl/cmd +/-) to change the size of labels without zooming into the actual map.

------

Speaking of maps, I got to work a fun zoom project a few years ago: https://map.fieldmuseum.org/

We used https://openlayers.org/ and thought long and hard about how to best handle zooming and variable levels of information density & visual hierarchy. If you zoom all the way out, we just highlight where the building is relative to the surroundings. As you start to zoom in, we start to highlight major exhibitions and entrances. Then as you zoom in more, we start showing recommended paths, smaller exhibitions, etc. The label sizes try to scale up and down at each level, smoothly, in order to balance readability and density.

Eventually you can reach the max zoom level and the labels will just grow bigger and bigger, but the SVGs dynamically shrink so they remain pictograms and not just contextless-lines.

Then if you keep going, you eventually find microscopic easter eggs :)

The code is pretty jank (and abandoned), but it's FOSS vanilla JS/HTML/CSS, and the only dependency is on OpenLayers: https://github.com/arcataroger/openlayers_indoor_map

In order to display the GeoJSON features on a map, we will use OpenLayers, which is a very powerful open-source mapping library that is also very simple to use.

OpenLayers is available via the ol npm package, offering developers a powerful toolkit for creating sophisticated maps. Here is a JavaScript implementation that utilizes OpenLayers to showcase a map:

Official Website: https://openlayers.org/

For web maps I'd strongly recommend using OpenLayers. While it's less convenient to get started with compared to the alternatives it's also much more feature-complete and you'll likely hit a ceiling in terms of functionality much later than you would with the others.

It looks like the base Kontur dataset uses H3 resolution 8, and there’s a lookup table here. “400m” seems to refer to the edge length (which averages to 461m).

I can speak to quadtrees, but the primary reason for using this is that you need a geographic "dictionary" (not using the word map to avoid confusion with charts), and you're perhaps already using the H3 hexagonal grid system.

HexSet: is a way of storing a set of H3 cells in a tree, and doing fast (2-20 ns on my 2013 trashcan Mac Pro) membership tests. You must first convert the input data (e.g. GeoJSoN polygon) into H3 cells.

> What an amazing tool that can completely change function names when it converts from C to Go.

How can one read the code of the benchmark, then switch into virulent sarcasm mode without trying to understand the code? And seeing "+1" comments without any effort to understand is also disheartening.

The blog post had a link about the Go helper functions the author used. It lands on https://github.com/akhenakh/goh3/blob/main/h3.go This shows that the `FromGeo()` function used by the Go benchmark is a helper that calls transpiled functions. The benchmark code itself was of course not transpiled, so the sarcasm was unneeded and wrong.

If anyone wants to dig in deeper, the C function `latLngToCell()` calls 2 functions, see https://github.com/uber/h3/blob/master/src/h3lib/lib/h3Index...

Uber just released their library to perform geospatial indexing - https://h3geo.org/. This might be an useful building block for you.