-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pointing at coincident points #1621
Comments
A slightly different way to approach this would be to allow a pointer to catch all the points within a given radius, maybe ordered by distance with the closest one on top. The mark could then decide what to do when it needs to represent several points. For example the tip mark could try to show "as many tips as possible" and rotate through them on click, but the dot mark would not have to do anything fancier than simply draw all the selected dots. With a null radius, we would have the current behavior: a single point (the last one wins). With a number, we would guarantee an array of points (0, 1, or more), within that radius. With radius==0 only coincident points would return an array of more than one value. |
Yep, that’s what I meant by “allow focusing multiple points simultaneously”. 👍 |
I think the mark should detect collisions and try to gracefully render colliding tips without further interaction, that way the solution is also applicable to non-interactive plots with static tips (such as the US states example in the docs). |
Yes, @net, perhaps we should have another feature request for that. Though even so that will only scale to at best ~4 tips, so we’ll still need some way to disambiguate pointing at coincident/dense points. |
@mbostock if resolving the collisions through positioning fails, the mark could fall back on merging the tips into one, positioning the point of the tip at the average of the collided tips, and rendering the merged tip contents in one tip. Of course, that only scales so far too, but it would fix the US states example 🙂
|
Hi @mbostock! First of all, thank you for your great work! :) What do you think about adding access to all points data with the same values of the corresponding axis via pointer? It will help to render one tip for all data(points) represented by the same value. |
See #1671 |
Great! Is it possible to stack tips into one? |
For that use case you'll probably want to group (or bin) the values by date, then compose a grouped tooltip. Here's a quick example, which is definitely not completely functional, given that there are too many lines, but hopefully enough to convey the idea:
|
Since the pointer transform only focuses one point at a time, if points are coincident (or nearly so), some points may not be focusable. Should the pointer transform allow focusing multiple points simultaneously, and then the tip mark could handle cycling between points, or showing multiple tips with collision detection? Or should the pointer transform support an interactive method of cycling through nearby points, say by clicking?
The text was updated successfully, but these errors were encountered: