How to replace firestore geofire with h3? about h3-js

[mailinger-mate]

I would think the solution probably relies on the indexing order, however I need help with understanding how that is represented in the indexes between resolutions, if the lowest resolution set is continuous between startAt and endAt of higher resolutions...
https://observablehq.com/@nrabinowitz/h3-indexing-order

[mailinger-mate]

I have read a few more responses from @nrabinowitz Stack Overflow as well and now I think I understand that the child indexes of any hexagon are not continuous alphanumerically, and cannot be used to range queries in NoSQL databases:
https://stackoverflow.com/questions/53911322/is-the-h3index-ordered#comment95750613_53915447

Using the referenced h3 indexing order visualization I am able to extract that for the San Fransisco 8428309ffffffff hexagon the children h3 indexes at lower resolution cannot be described in continuous ranges:

["*807*","*80f*","*817*","*81f*","*827*","*82f*","*837*","*847*",...]

To give more context, for now using the Geofire library I am mapping the h3 hexagons to their nearest geohash [start, end] range pairs (rectangles), and then calculate and exclude for each range the geohashes that are outside the radius of the hexagon (red rectangles), specifically:

{
  "h3Index": "8665812cfffffff",
  "geohashRanges": ["w60gh","w60gk"],["w60g4","w60g6"],["w60fu","w60fw"],["w60ff","w60fh"],
  "geohashesExcluded: [["w60g5zz8ku","w60g5zz8kv"],["w60g5zz8mh","w60g5zz8mj"],["w60g5zz8kv"],["w60g5zz8mj"],["w60g5zz8kg"],["w60g5zz8m5"]]
}

Unfortunately this results in several parallel aggregate queries, and because the rectangles will never fit the hexagons, displaying aggregate numbers of the rectangles mapped to the hexagon will always be redundant and inaccurate. Of course I could just display the geohash rectangles on the map, but the benefits of h3 indexing are more appealing both visually and computationally.

This is why I am looking for any solution where I can use h3 indexes in the database objects and query them at various resolutions in a way that are less expensive and less inaccurate relative to the current solution.

[nrabinowitz]

If i understand your use case correctly, I believe H3 can do what you're trying to do. While k-rings (also called grid disks, the set of cells within k steps of some origin) are not ordered sequentially, children at a given resolution are. You can request the range of children at some res with the lower bound as cellToCenterChild(res); the upper bound is a little tricker until we release childPosToCell but you can construct it. This is harder in JS, because we can't use 64-bit ints, but essentially you apply a bitmask of all 1s to the bottom N bits of the index, where N is 3 * (15 - parentRes) (I think, I haven't tested this). The bit layout diagrams here might help.