Let Scatter marker type be parameterizable

[hafen]

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:

{
  "type": "GlyphRenderer",
  "attributes": {
    "glyph": {
      "type": "Circle",
      ...
    }
  }
},
{
  "type": "Circle",
  "attributes": {
    "x": {
      "units": "data",
      "field": "x"
    },
    "y": {
      "units": "data",
      "field": "y"
    },
    ...
  }
}

{
  "type": "GlyphRenderer",
  "attributes": {
    "glyph": {
      "type": "Square",
      ...
    }
  }
},
{
  "type": "Square",
  "attributes": {
    "x": {
      "units": "data",
      "field": "x"
    },
    "y": {
      "units": "data",
      "field": "y"
    },
    ...
  }
},
...

With each having a separate ColumnDataSource. Instead, something like this would make life so much easier:

{
  "type": "GlyphRenderer",
  "attributes": {
    "glyph": {
      "type": "Marker",
      ...
    }
  }
},
{
  "type": "Marker",
  "attributes": {
    "x": {
      "units": "data",
      "field": "x"
    },
    "y": {
      "units": "data",
      "field": "y"
    },
    "marker": {
      "units": "data",
      "field": "m"
    },
    ...
  }
},
{
  "type": "ColumnDataSource",
  "attributes": {
    "column_names": ["x", "y", "m"],
    "data": {
      "x": [1, 2, 3],
      "y": [1, 2, 3],
      "m": ["Circle", "Square", "Triangle"],
      ...
    }
  }
},
...

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?

[mattpap]

We already auto-generate markers' classes in bokehjs, so it would be a reasonable step to just provide one parametrizable class. One issue is Circle glyph that is often considered a marker, but is different (has radius property). This can be solved by leaving Circle as-is and adding circle marker. As there will be no classes for markers, there will be no conflict with the glyph. Some effort will have to be put into deprecating old behavior.

[mattpap]

Possible other issue is how legend would be generated.

[bryevdv]

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:

p.circle('sepal_width', 'petal_width', source=source, group=('species', 'setosa'))
p.square('sepal_width', 'petal_width', source=source, group=('species', 'versicolor'))
p.square('sepal_width', 'petal_width', source=source, group=('species', 'virginia'))

And then have update just Plot.scatter to be able to drive and coordinate doing that automatically at a higher level.

p.scatter('sepal_width', 'petal_width', source=source, group='species')

(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 p.scatter have a new meaningful reason to exist.

[bryevdv]

CDSView work was merged, that is the better way to do this from bokeh directly. At a higher level, Holoviews is an option

[bryevdv]

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.

[hamilyon]

It would be a nice feature

[bryevdv]

Per #7066 (comment) intend to make a Scatter glyph that is vectorizable by marker type, and have the existing Figure.scatter create this new glyph.

[bryevdv]

FYI @hafen this is incoming:

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.