Skip to content
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

Closed
hafen opened this issue Feb 17, 2017 · 8 comments · Fixed by #8285
Closed

Let Scatter marker type be parameterizable #5884

hafen opened this issue Feb 17, 2017 · 8 comments · Fixed by #8285

Comments

@hafen
Copy link

hafen commented Feb 17, 2017

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:

screen shot 2017-02-16 at 6 21 44 pm

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
Copy link
Contributor

mattpap commented Feb 17, 2017

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
Copy link
Contributor

mattpap commented Feb 17, 2017

Possible other issue is how legend would be generated.

@bryevdv
Copy link
Member

bryevdv commented Feb 17, 2017

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
Copy link
Member

bryevdv commented Oct 11, 2017

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

@bryevdv
Copy link
Member

bryevdv commented Oct 18, 2017

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.

@bryevdv bryevdv modified the milestones: short-term, 0.12.11, 0.12.x Oct 18, 2017
@hamilyon
Copy link

It would be a nice feature

@bryevdv bryevdv modified the milestones: 0.13.x, short-term Sep 11, 2018
@bryevdv
Copy link
Member

bryevdv commented Sep 21, 2018

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
Copy link
Member

bryevdv commented Sep 25, 2018

FYI @hafen this is incoming:

screen shot 2018-09-25 at 18 22 31

@bryevdv bryevdv mentioned this issue Sep 28, 2018
3 tasks
@bryevdv bryevdv changed the title Create Marker class that encompasses all markers and allow specific marker type to be specified from data Let Scatter marker type be parameterizable Oct 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants