Add H3 layer #198
Add H3 layer #198
Conversation
|
Still TODO:
|
|
This is awesome. Thank you for doing this. Did you move the files from @uber/kepler.gl? |
| @@ -3506,6 +3506,10 @@ grid-index@^1.0.0: | |||
| version "1.0.0" | |||
| resolved "https://registry.yarnpkg.com/grid-index/-/grid-index-1.0.0.tgz#ad2c5d54ce5b35437faff1d70a9aeb3d1d261110" | |||
|
|
|||
| h3-js@^3.1.0: | |||
There was a problem hiding this comment.
Please update your ~/.npmrc to use registry = https://registry.yarnpkg.com/ before running yarn. This is why the build failed
|
@heshan0131 yep, copied from internal kepler wrapper. Will try to find time this week to wrap it up, TBD. |
|
@ibgreen perhaps? Thoughts on where in deck.gl this would be added, Would probably want to standardize I'm guessing the best path here is to land this into Kepler first and then work w/ @heshan0131 and @nrabinowitz to tidy things up enough to hoist them into deck.gl. Thoughts? |
|
@ericsoco - All sounds reasonable. Also see the ideas in the deck.gl layers roadmap where we start discussing having multiple layer catalogs. Putting things in experimental layers is a nice first start, since more users can access the layers. The big job is typically getting layers out of experimental layers and into the official catalog(s). |
| hexagonResolution: this.dataToFeature.resolution | ||
| }; | ||
|
|
||
| // return {layerData, layer: this}; |
| getElevation, | ||
| getColor, | ||
| getHexId, | ||
| hexagonVertices: this.dataToFeature.vertices, |
There was a problem hiding this comment.
Is this still needed? We calculate in render now, right?
|
|
||
| allData.forEach((d, index) => { | ||
| const id = getHexId(d); | ||
| if (typeof id !== 'string' || !id.length) { |
There was a problem hiding this comment.
Consider h3IsValid here, which checks whether it's a real H3 address. This would be slower but more reliable.
| } | ||
|
|
||
| renderLayer({ | ||
| data, |
There was a problem hiding this comment.
This may be a Kepler.gl style question, but I find the way that data refers to different objects in different methods a bit confusing.
| // get vertices should return [lon, lat] | ||
| export function getVertices({id}) { | ||
| // always reverse it | ||
| return h3ToGeoBoundary(id).map(d => d.reverse()); |
There was a problem hiding this comment.
h3ToGeoBoundary(id, true) will give you GeoJSON [lon, lat] coords in a more performant way than .reverse(). It will also close the loop (repeat the first point), which is required for valid GeoJSON - not sure if that matters here.
|
|
||
| return { | ||
| geometry: { | ||
| coordinates: [...vertices, vertices[0]], |
There was a problem hiding this comment.
No need for vertices[0] here if you use the h3ToGeoBoundary(id, true) suggestion above.
| const vertices = getVertices(object); | ||
|
|
||
| return { | ||
| geometry: { |
There was a problem hiding this comment.
May not matter here, but this isn't a valid GeoJSON object w/o "type": "Feature" at the top level.
| } | ||
|
|
||
| // get centroid should return [lon, lat] | ||
| export function getCentroid({id}) { |
There was a problem hiding this comment.
It probably wouldn't matter if it wasn't in a hot loop, but you might be doing this for 100k hexagons, so I'd suggest just passing the hex id w/o needless destructing.
|
@ericsoco I can take over this PR. Please grant me access to your fork. You can allow edits from maintainers |
Still planning to add a coverage slider to match existing Hexbin Layer.
Also, I think @nrabinowitz has some additional edits.
This addresses #154, but does not add support for H3 bin aggregation (that can come in a followup diff, extending our use of
h3-js.