Conversation
|
I can’t put a finger on it but the API feels… a little awkward. Like, you presumably wouldn’t ever change the x- or y-accessor after populating your bins, but the API lets you. Perhaps we should model d3-delaunay instead. I’m excited about this work, through! I’ll try to play with a notebook and get a better sense of what I think would work well. |
|
I don't have a clear use case for changing the x accessor mid-course, but if you're working on a stream of values, then maybe x represents their age x(d => d.time - currentTime) and currentTime varies… though we would probably recommend using translate() in this specific case. |
|
Did you mean than once a point p is accessed, its (x,y) values should be set — but its (i,)j coords on the grid (the bin) could change if we change the translate/rotate? I would tend to agree — but it means big changes:
|
- using hexbin.context([context]), hexbin.hexagon() and hexbin.mesh() support canvas ; fixes #1 - incremental updates: bins.add(point); bins.addAll(points); remove(point); bins.removeAll(points); fixes #3 - hexbin.angle([angle]) sets or reads an angle (default 0°, use 90° for flat-topped hexagons) ; fixes #8
…ifferent order) note: I made it be a setter, which sort of duplicates hexbin(data)
- remove .data(), instead use bins.flat() to get the data, and hexbin() to update without adding points. - don't rebin aggressively when changing parameters, only on update ie when calling hexbin() - all the new methods are on hexbin not on bins
Including a bit more centers solves the issue. The solution breaks a test on centers() in the angle=0 case, which we could keep backwards compatible by testing for angle===0; but I don't think it's a problem if we have a few more centers (better safe than sorry).
|
Rebased on master. |
Giving it another thought, there are 3 possible scenarios when when change a parameter and already have some data binned:
I think there is a plausible user story for each of the scenarios; but I see the weirdness both in A and B, for opposite reasons. With A the binned points are moving with their hexagons when you change the translate/rotate/radius, so what I do in the demo is not possible. With B they are accessed again, so you can't have an x/y accessor that depends on time and points that are progressively binned and stay put. The safe solution is probably C — also more future-proof as it creates no weird expectation? This way the user has to be explicit in how they want to bin everything (past and new data). The only drawback is that the hexbin isn't your data store (but it's easy enough to retrieve the data before changing the params, then rebin it). |
|
Superseded by #19 |
2 participants
Fixes #1 #3 #8. (I tried to separate the concerns but there were too many conflicts between my changes, and I gave up.)
Demo: https://observablehq.com/d/892da8c88474a46c