I'm trying to us the h3-js library in a react-native app. I npm installed the library, and then when I just import h3 into one of my files, it gives me an error that say's can't find variable document. I'm assuming it is coming from the libh3.js file in "./dist/out" where it has the function....

var libh3 = (function() { var _scriptDir = typeof document !== 'undefined' && dtocument.currentScript ? document.currentScript.src : undefined; return ( ........

I don't know where the problem is coming from but it's not in my code because I'm just trying to import h3-js

Hi, I know that since Js does not support BigInteger this library is returning hex results as index, but is there any safe way to use BigInt object in js to handle these numbers? since in my case I need to manipulate the indexes.

A few questions & clarifications:

Unfortunately I do not have a background in mathematics, please be patient with me.

The gist of my use case is a geo-location based mobile game that uses a hexagonal grid to represent the world, something H3 appears to exactly solve for. Though, this use case necessitates the need to have a coordinate system that can uniquely identify each cell in the global grid for a variety of reasons. I am having a hard time figuring out how to obtain coordinates from the cells of an H3 grid.

H3 Coordinate Systems: https://h3geo.org/docs/core-library/coordsystems Hexagonal Coordinate Systems: https://www.redblobgames.com/grids/hexagons/#coordinates

I marginally familiar three coordinate systems for hexagonal grids:

• Offset Coordinates
• Cube Coordinates (3 axes 120 degrees apart)
• Axial Coordinates (Essentially cube coordinates sans an axis) [What I am aiming for here]

In the H3 docs, it mentions:

• IJK Coordinates
  • This is noted as being the 3 coordinate axes spaced 120° apart which seems like a cube coordinate system. However the example picture's coordinates don't seem to line up with the expectation of i+j+k == 0.
  • What is this if not cube coordinates?
  • Are these globally unique?
  • How can this coordinate be obtained for a given H3Index?
• FaceIJK Coordinates
  • Simply the IJK coordinates, but centered on each face. And I assume constrained to each face. Definitely not what I'm after.
• Hex2d Coordinates.
  • [x,y] coordinates for the IJK coordinates with the +x axis aligned on i axis. This appears to be what I am looking for.
  • Are these essentially Axial Coordinates?
  • Is there a specific conversion expectation to go from IJK to Hex2d?
  • How can this coordinate be obtained for a given H3Index?
• Local IJ Coordinates.
  • At first this looked promising, until I read local coordinates are only valid near the origin.. Which points out that these coordinates are really only valid within the same base cell.

TL;DR: How can I obtain cartesian coordinates for each cell that are globally unique?

The package is listening all 'UnhandledRejection' errors and throwing it's own (h3-js) error from 'dist/hs-js.js', line: 10979 even if the source of the error is not h3-js package itself.

Is there a way to overwrite this 'UnhandledRejection' errors, what do you suggest?

Hi,

Im trying to incorprate your library on a number of solutions which require realtime translations between hex ids and geojson multi/polygons.

h3.h3SetToMultiPolygon(["85291a6ffffffff"],true)

returns

[[[[-121.87310260648961,36.48355301296484],[-121.82059177712684,36.56646154014561],[-121.88144909358076,36.64149027277887],[-121.99481876336013,36.63355254199253],[-122.0471691328904,36.550641568925464],[-121.98631059624982,36.4756707384872],[-121.87310260648961,36.48355301296484]]]]

No problem with that. The issue however is displaying this now results in an askew/misrepresented polygon on a map.

The map is in EPSG:4326. Geojson.io

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {
        "color": "blue"
      },
      "geometry": {
        "type": "MultiPolygon",
        "coordinates": [
          [
            [
              [
                -121.87310260648961,
                36.48355301296484
              ],
              [
                -121.82059177712684,
                36.56646154014561
              ],
              [
                -121.88144909358076,
                36.64149027277887
              ],
              [
                -121.99481876336013,
                36.63355254199253
              ],
              [
                -122.0471691328904,
                36.550641568925464
              ],
              [
                -121.98631059624982,
                36.4756707384872
              ],
              [
                -121.87310260648961,
                36.48355301296484
              ]
            ]
          ]
        ]
      }
    }
  ]
}

Is this correct?

Hi,

I'm using h3-js to compile isochrones (a few hundred millions), and I notices that the memory usage keep growing. After some quick investigations on my code to make sure the issue is not on my side, I think this comes from either h3SetToMultiPolygon or multiPolyfill (I investigate a while ago, and I can't remember). Anyway, after it does what it is supposed to do, a small amont of memory keep being used, and thus, after running it a couple of thousand times, node runs out of memory. For now, as a quick dirty fix, I run it on child processes that I can restart once in a while.

Sorry for not providing more intels, I investigate this a while ago and found a quick workaround, but it still worth sharing the issue.

Note: i'm using 3.7.1

EDIT: version 3.7.1 was apparently supposed to fix this issue. I guess it's still there...

I needed typescript definitions for these bindings and noticed you generate your README off of jsdoc.

I've managed to generate the definitions using tsd-jsdoc requiring minimal change to h3core.js.

This PR adds the required jsdoc changes, but also a script to bundle the types on prepublish.

I'm not sure how you feel about distributing these definitions yourself. If you'd rather not, I'll simply remove that part. But I do hope you'll allow the jsdoc changes. :smiley:

Hi!

I'm creating an app which shows nearby posts in a customizeable radius (with accuracy of ~100m). I've found h3 to be a very efficient library, but I couldn't quite figure out how to efficiently query my firestore NoSQL database using H3, since firestore is very limited in querying capabilities.

I've currently come up with this solution:

export async function loadNearbyPosts(coordinates: Coordinates, radius: number): Promise<Post[]> {
  const h3 = geoToH3(coordinates.latitude, coordinates.longitude, H3_RESOLUTION);
  console.log(`${JSON.stringify(coordinates)} -> ${h3}`);
  const neighbours = kRing(h3, 10); // <-- how do I convert my 'radius' in metres to the k-ring range ('10')?
  console.log(`Neighbours of ${h3} include: ${JSON.stringify(neighbours)}`);

  const batchedNeighbours: string[][] = [];
  for (let i = 0; i < neighbours.length; i += 10) batchedNeighbours.push(neighbours.splice(i, 10));

  console.log(`Batched to size of 10s: ${JSON.stringify(batchedNeighbours)}`);
  console.log(`Running ${batchedNeighbours.length} queries...`);

  const start = global.nativePerformanceNow();
  // how do I remove this batching and instead use range checks? something like `greater than this h3 and smaller than this h3`
  const queries = batchedNeighbours.map((n) => firestore().collection('posts').where('location.h3', 'in', n).get());
  const results = await Promise.all(queries);
  const end = global.nativePerformanceNow();

  const docs: Post[] = [];
  results.forEach((r) => docs.push(...r.docs.map((d) => build<Post>(d))));

  console.log(`Executed ${batchedNeighbours.length} queries and received ${docs.length} results, all within ${end - start}ms.`);
  return docs;
}

While this does indeed return results for me, it is very inefficient. For this simple query, it actually executes 17 queries (!!) because firestore has a limit of maximum 10 items in an array in the in query (that's why I'm batching the neighbours into arrays of 10 elements), and I'm comparing for exact matches, so I'm forced to using the same precision for all my h3 hexagons.

Using geohashes, I can find by range since they're alphabetically sorted. E.g. I can filter for bc -> bc~ which gives me all squares that start with bc.

Now let's get to my actual questions:

1. Is it possible to "find by range" using h3, similar to geohashes? That way I can remove the batching code and don't have to run 17 queries for a simple "nearby" lookup. I couldn't really find a good explanation of the h3 algorithm on how the tiles are sorted, but if I could reduce it to some smaller amount of queries (e.g. everything in range 871e064d5ffffff -> 871e06498ffffff, plus everything in range of 871e0649bffffff -> 871e06509ffffff... or in other words "larger than this h3 but smaller than this h3")
2. How can I actually convert a range in metres to k-ring/hex-ring ranges?

Thanks for your help!

Hello, Suppose we are storing h3 indexes in a database column. To perform a parent/child query I was thinking of using h3 indexes. Lets say we have this index 832834fffffffff. This cell's children are[ '8428341ffffffff', '8428343ffffffff', '8428345ffffffff', '8428347ffffffff', '8428349ffffffff', '842834bffffffff', '842834dffffffff']. What is the logic to tell if an h3index id is a child of another id. Is there any way that we can find a range of indexies that are child of the specific id. I already found https://github.com/uber/h3/issues/320 and https://stackoverflow.com/questions/53911322/is-the-h3index-ordered but could not find my answer. Thanks

Bumps handlebars from 4.1.2 to 4.5.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

#55 added auto-generated TypeScript types, but it seems like some of the functions (e.g. h3ToGeoBoundary) that return an array of arrays (i.e. Array[]) don't type-check properly in TypeScript, since the compiler expects the outer Array to have a type parameter:

https://github.com/uber/h3-js/blob/c5f653f300eee3f3c2f7aebcfd59812e24f40170/lib/h3core.js#L566

The fix is likely to specify the inner-most type explicitly (e.g. Number[][]) in the JSDoc.

The current emscripten (1.38.43) is ~3 years old now. The docker container used is also deprecated https://hub.docker.com/r/trzeci/emscripten. Can we migrate to the official emscripten and use a newer version?

There are hosts of benefits and bug fixes from the past three years.

The documentation clearly states that functions edgeLength and hexArea allow for second parameter to be UNIT.rads for edgeLength or UNIT.rads2 for hexArea. However when calling these functions:

h3.edgeLength(12, h3.UNIT.rads);
h3.hexArea(12, h3.UNIT.rads2)

an error is thrown:

Unknown unit: rads

Unknown unit: rads2

importing h3-js this way import * as h3 from "h3-js";

would trigger the error below:

[Sat May 08 2021 16:50:27.116]  ERROR    Error: Requiring module "node_modules/h3-js/dist/browser/h3-js.js", which threw an exception: ReferenceError: Can't find variable: document
[Sat May 08 2021 16:50:27.132]  ERROR    ReferenceError: Can't find variable: document

I am wondering if this could be easily fixed? I am reading that there is a node version of h3-js, how can I import it instead of the browser version?

I tried to only import the function I was using at the time but I am still getting the same error

import {geoToH3} from 'h3-js';

I think the error is pointing to this code here in h3-js

  var readAsync;

  {
    if (document.currentScript) {
      scriptDirectory = document.currentScript.src;
    }

    if (scriptDirectory.indexOf("blob:") !== 0) {
      scriptDirectory = scriptDirectory.substr(0, scriptDirectory.lastIndexOf("/") + 1);
    } else {
      scriptDirectory = "";
    }

I'm getting some weird results from h3SetToMultiPolygon when passing large numbers of h3 indexes (in these examples the h3 cells are all adjacent). There are two issues:

1. When the polygon array is returned there are a number of single point arrays. e.g.

h3Ids: ["8132fffffffffff","812e7ffffffffff","81303ffffffffff","815a3ffffffffff","814f7ffffffffff","81733ffffffffff","81687ffffffffff","814afffffffffff","8133bffffffffff","812f3ffffffffff","814e7ffffffffff","8130fffffffffff","815afffffffffff","8132bffffffffff","814bbffffffffff","812e3ffffffffff","81777ffffffffff","814f3ffffffffff","814abffffffffff","81337ffffffffff","812efffffffffff","814e3ffffffffff","815abffffffffff","81327ffffffffff","814b7ffffffffff","812fbffffffffff","81773ffffffffff","814efffffffffff","81317ffffffffff","815b7ffffffffff","814a7ffffffffff","81333ffffffffff","815a7ffffffffff","81737ffffffffff","81323ffffffffff","814fbffffffffff","814b3ffffffffff","812f7ffffffffff","814ebffffffffff","81313ffffffffff","815b3ffffffffff","814a3ffffffffff","8123bffffffffff","81237ffffffffff","81233ffffffffff","8147bffffffffff","8146fffffffffff","8146bffffffffff","81223ffffffffff","81463ffffffffff","81473ffffffffff","81477ffffffffff","81467ffffffffff","815dbffffffffff","815d3ffffffffff","815cbffffffffff","815c3ffffffffff","8137bffffffffff","815bbffffffffff","81373ffffffffff","8136bffffffffff","81363ffffffffff","8171bffffffffff","81717ffffffffff","81713ffffffffff"]

Gives this result: [ [ [ [ 43.816094965537175, 142.3058437365082 ], [ 47.94353494620575, 140.81932027711576 ], [ 48.30438780776227, 137.965723000237 ], [ 48.41801789173907, 134.76393627595755 ], [ 45.253613490980094, 131.7744009814935 ], [ 45.09643436908035, 125.98114176677377 ], [ 47.997962809385406, 122.1525950681968 ], [ 47.30945130281312, 116.21289563713783 ], [ 43.25414167974314, 115.50113901102061 ], [ 41.14827082786993, 119.13690952882241 ], [ 38.614966776615006, 118.5828850895855 ], [ 37.42985448428109, 118.86929883406582 ], [ 36.20528264541884, 121.690153924224 ], [ 36.005614448071924, 123.16276457697893 ], [ 32.66144519495384, 124.02055612683286 ], [ 29.89298533869355, 120.503393859958 ], [ 26.20027606045547, 121.34751445935747 ], [ 24.728661050965936, 119.64146543031175 ], [ 23.50895195973631, 117.99047716641068 ], [ 19.252194904738655, 118.80300158646772 ], [ 18.127070267319834, 123.02355515221002 ], [ 13.797500809062361, 123.85482415801255 ], [ 10.736966167684393, 120.449366342475 ], [ 6.2891846753414375, 121.26764633911117 ], [ 4.76343118357537, 125.5023153387887 ], [ 7.805398745803346, 129.0449200915637 ], [ 6.19767652780886, 133.49441060685513 ], [ 9.23145267029969, 137.1970727246292 ], [ 7.537486471095007, 141.69432910913807 ], [ 10.472716898667054, 145.410940917621 ], [ 8.701739974658008, 149.7748737561887 ], [ 4.084015752678338, 150.44123001544202 ], [ 2.3920322085174597, 154.598935323174 ], [ 5.189055516512115, 158.0067643262748 ], [ 3.50810422466813, 161.8156148096885 ], [ 6.119591258608643, 164.93539603741024 ], [ 4.4670316097845255, 168.3352524578736 ], [ 4.467031609784517, 168.3352524578736 ], [ 6.172978893164634, 172.0341823693935 ], [ 4.248592317017831, 175.46041201203371 ], [ 5.8899217543139155, 179.21716082489448 ], [ 5.889921754313889, 179.21716082489448 ], [ 2.9040374505798128, -178.0251966524985 ], [ 3.821024494330419, -174.31673738369324 ], [ 7.972793830841406, -173.38014762578527 ], [ 9.060308038526605, -169.29312998396932 ], [ 5.767146686378422, -166.16940101623453 ], [ 6.766536253596447, -161.77338167921764 ], [ 3.3357348575173495, -158.59967491814012 ], [ 4.260374459536216, -154.0294052002189 ], [ 8.71898308656318, -152.5335322367957 ], [ 9.628747217956542, -147.80006555587835 ], [ 14.110797540904425, -146.16007687374923 ], [ 17.737530353545214, -149.3676428224656 ], [ 22.166939007405805, -147.69594788211106 ], [ 25.669243623986258, -151.04796662686522 ], [ 29.891830084602514, -149.34707529879068 ], [ 30.56995088296885, -144.17342232410294 ], [ 34.454167617014946, -142.3232078622538 ], [ 37.68759229063255, -145.7463690434673 ], [ 41.20828589932378, -143.84631120128412 ], [ 44.09362423911827, -147.45009391663316 ], [ 43.44325276436555, -153.03739182353246 ], [ 43.44325276436556, -153.03739182353243 ], [ 46.9088746957617, -156.03631344405528 ], [ 46.51349897531834, -161.56979335131368 ], [ 49.895974148750696, -165.61336675442524 ], [ 49.05085282910133, -171.87311046039585 ], [ 44.74985555511408, -173.25136162888563 ], [ 43.33462463706693, -179.170112546831 ], [ 46.18001465709014, 175.62099681678237 ], [ 44.17622039141846, 169.66101739290986 ], [ 46.48282657751592, 163.91021485526238 ], [ 43.912304017571394, 158.38289640953528 ], [ 45.62266462732751, 152.54480605394903 ], [ 42.63340688235615, 147.81728377284588 ] ] ], [ [ [ 27.949605976503907, 142.4332217566576 ] ] ], [ [ [ 34.33115860097916, 132.30837745804206 ] ] ], [ [ [ 12.194726726167971, 160.7733897026288 ] ] ] ]

The first polygon is accurate but the others are single points and seem unnecessary. Not a big deal as I can easily filter these out. This doesn't seem to happen at lower H3 resolutions.

2. Occasionally I am only getting single point returns (i.e. no actual polygon).

For example with these h3 ids: [ "816efffffffffff", "8126bffffffffff", "8148fffffffffff", "8113bffffffffff", "8122fffffffffff", "810c3ffffffffff", "8150bffffffffff", "815c3ffffffffff", "8126fffffffffff", "81493ffffffffff", "81363ffffffffff", "81457ffffffffff", "81233ffffffffff", "810c7ffffffffff", "8150fffffffffff", "815c7ffffffffff", "81273ffffffffff", "81497ffffffffff", "81367ffffffffff", "81237ffffffffff", "810cbffffffffff", "81513ffffffffff", "815cbffffffffff", "8149bffffffffff", "8136bffffffffff", "8123bffffffffff", "810cfffffffffff", "81517ffffffffff", "811c3ffffffffff", "815cfffffffffff", "816c3ffffffffff", "8127bffffffffff", "8136fffffffffff", "81463ffffffffff", "8151bffffffffff", "81703ffffffffff", "815d3ffffffffff", "81373ffffffffff", "81467ffffffffff", "811cbffffffffff", "81707ffffffffff", "815d7ffffffffff", "816cbffffffffff", "81283ffffffffff", "81377ffffffffff", "8146bffffffffff", "811cfffffffffff", "815dbffffffffff", "81287ffffffffff", "8137bffffffffff", "8146fffffffffff", "811d3ffffffffff", "816d3ffffffffff", "8128bffffffffff", "81473ffffffffff", "811d7ffffffffff", "81713ffffffffff", "8128fffffffffff", "81477ffffffffff", "81123ffffffffff", "811dbffffffffff", "81717ffffffffff", "816dbffffffffff", "81293ffffffffff", "8147bffffffffff", "81127ffffffffff", "81793ffffffffff", "810ebffffffffff", "8171bffffffffff", "81297ffffffffff", "81797ffffffffff", "8112bffffffffff", "816e3ffffffffff", "8129bffffffffff", "81483ffffffffff", "8179bffffffffff", "8112fffffffffff", "81447ffffffffff", "81223ffffffffff", "816e7ffffffffff", "81263ffffffffff", "81487ffffffffff", "81227ffffffffff", "81503ffffffffff", "816ebffffffffff", "81267ffffffffff", "8148bffffffffff", "81137ffffffffff", "8122bffffffffff", "81507ffffffffff", "815fbffffffffff", "814cbffffffffff", "812a7ffffffffff", "8139bffffffffff", "81453ffffffffff", "81677ffffffffff", "81547ffffffffff", "811b7ffffffffff", "812abffffffffff", "814cfffffffffff", "8167bffffffffff", "8154bffffffffff", "811bbffffffffff", "812afffffffffff", "814d3ffffffffff", "813a3ffffffffff", "8145bffffffffff", "8154fffffffffff", "812b3ffffffffff", "814d7ffffffffff", "81183ffffffffff", "813a7ffffffffff", "81277ffffffffff", "81553ffffffffff", "814dbffffffffff", "812b7ffffffffff", "81187ffffffffff", "813abffffffffff", "81557ffffffffff", "812bbffffffffff", "8118bffffffffff", "813afffffffffff", "816c7ffffffffff", "8155bffffffffff", "81743ffffffffff", "8118fffffffffff", "813b3ffffffffff", "8159bffffffffff", "81193ffffffffff", "813b7ffffffffff", "81563ffffffffff", "81197ffffffffff", "813bbffffffffff", "81067ffffffffff", "817c7ffffffffff", "81567ffffffffff", "81343ffffffffff", "810e3ffffffffff", "8119bffffffffff", "815e3ffffffffff", "816d7ffffffffff", "81383ffffffffff", "817cbffffffffff", "8156bffffffffff", "81347ffffffffff", "81753ffffffffff", "810e7ffffffffff", "815e7ffffffffff", "817cfffffffffff", "8156fffffffffff", "8134bffffffffff", "81663ffffffffff", "81757ffffffffff", "8180fffffffffff", "811a3ffffffffff", "815ebffffffffff", "8138bffffffffff", "8134fffffffffff", "81573ffffffffff", "81667ffffffffff", "81443ffffffffff", "8175bffffffffff", "810efffffffffff", "811a7ffffffffff", "815efffffffffff", "81077ffffffffff", "81353ffffffffff", "81577ffffffffff", "8166bffffffffff", "815f3ffffffffff", "811abffffffffff", "814c3ffffffffff", "81393ffffffffff", "81357ffffffffff", "8157bffffffffff", "8144bffffffffff", "810f7ffffffffff", "815f7ffffffffff", "811afffffffffff", "812a3ffffffffff", "8135bffffffffff", "8144fffffffffff", "81673ffffffffff", "81543ffffffffff", "811b3ffffffffff" ]

I get: [ [ [ [ 43.44325276436555, -153.03739182353246 ] ] ], [ [ [ 14.48240061773311, -65.76882190787967 ] ] ], [ [ [ 19.358823435394214, -75.99854824376126 ] ] ], [ [ [ 8.931891500446854, -127.11406580207421 ] ] ], [ [ [ 59.16948256665965, -139.68359348160976 ] ] ], [ [ [ 40.975558199255886, -54.879012779249344 ] ] ], [ [ [ 31.285608665560563, -134.10648897177788 ] ] ], [ [ [ 29.30037465923499, 0.2609468260311339 ] ] ], [ [ [ 41.45713981733575, -138.450291223663 ] ] ], [ [ [ 29.82877615972559, -1.240802016513824 ] ] ], [ [ [ 31.877885956365837, -62.02252554784451 ] ] ], [ [ [ 11.545295975414758, -4.01399844347046 ] ] ] ]

i.e. no actual polygon, just a series of points — seems like a bug?