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
Let Scatter marker type be parameterizable #5884
Comments
We already auto-generate markers' classes in bokehjs, so it would be a reasonable step to just provide one parametrizable class. One issue is |
Possible other issue is how legend would be generated. |
Before we go down the road of a generic/parameterizable marker class, let's see what @clairetang6 work on making CDS slice-able and group-able yields. Because from my perspective the ideal would to be able to drive several markers from a single CDS at a "low" level:
And then have update just
(Above just spitballing on possible spelling) This approach would leave the underlying machinery consistent throughout, not introduce any incompatibilities, would work easily with legends, and make the currently not-very-useful |
CDSView work was merged, that is the better way to do this from bokeh directly. At a higher level, Holoviews is an option |
OK, the newly linked issue has made me re-consider. In cases where folks want multiple lines and scatter glyphs together, not having a "multi glyph" can be quite slow. |
It would be a nice feature |
Per #7066 (comment) intend to make a |
FYI @hafen this is incoming: |
I keep running into an issue with markers where there is a need to vary marker according to some attribute of the data. As far as I understand it, this can only be done by splitting the data up into different data sources and making separate GlyphRenderers for each marker. This is problematic for several reasons.
Take this example, where I'm varying color and marker according to a variable in the data:
As illustrated above, one of the problems with breaking the data up and specifying multiple GlyphRenderers is that when you allow tap selection, the selection is restricted to only that group / marker. There are several related issues dealing with the various tools and callbacks when you want to think of the entire set of markers as a whole. The bigger issue is that it makes things a lot more complicated at the interface level for dealing this special case (in particular, it makes things pretty messy inside rbokeh).
To me, the ideal solution would be instead of individual classes "Circle", "Square", etc., having a class "Marker" that has an attribute "marker" that can be any one of: "Asterisk", "Circle", "CircleCross", "CircleX", "Cross", "Diamond", "DiamondCross", "InvertedTriangle", "Square", "SquareCross", "SquareX", "Triangle", "X". As far as I understand, all of the current marker classes have the same attributes, so it seems like this would be possible.
So basically instead of having a specification with things like this:
With each having a separate ColumnDataSource. Instead, something like this would make life so much easier:
Where here there is a single data source.
If this is not possible or not a priority, is there any way with the current structure of things that I can have a single ColumnDataSource with multiple markers?
The text was updated successfully, but these errors were encountered: