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

Intersection Brushing #57

Closed
syntagmatic opened this Issue Aug 15, 2014 · 12 comments

Comments

Projects
None yet
3 participants
@syntagmatic
Owner

syntagmatic commented Aug 15, 2014

Select lines by drawing an intersecting line anywhere between the axes, rather than on the axes themselves.

The intersection tests may need to follow the render-queue pattern to prevent slowing down interactions on large-ish datasets.

http://bl.ocks.org/syntagmatic/5441022

@bbroeksema

This comment has been minimized.

Show comment
Hide comment
@bbroeksema

bbroeksema Aug 17, 2014

Collaborator

A related idea: select lines that have the same (or inverse) slope within some boundary. Pearson correlation coeff. Could be used for this boundary value, but maybe there're more efficient ways to calculate it. Extension: allow for drawing a line acrosss multiple axes. Extension 2: use average (or median) of current brushed set as 'search item'.

Collaborator

bbroeksema commented Aug 17, 2014

A related idea: select lines that have the same (or inverse) slope within some boundary. Pearson correlation coeff. Could be used for this boundary value, but maybe there're more efficient ways to calculate it. Extension: allow for drawing a line acrosss multiple axes. Extension 2: use average (or median) of current brushed set as 'search item'.

@julianheinrich

This comment has been minimized.

Show comment
Hide comment
@julianheinrich

julianheinrich Aug 18, 2014

Collaborator

Brushing lines by slope is sometimes also referred to as 'angular brushing' and is a very useful feature. I have seen some demos where the boundary values are defined interactively using a circle: a click opens up a circle, moving the mouse specifies a portion of that circle (as in a pie chart) that defines the bounding angles relative to some pre-defined value (e.g. the horizontal line).
@bbroeksema what do you mean by Extension two? Refining a brush to be applied within a given brush?

Collaborator

julianheinrich commented Aug 18, 2014

Brushing lines by slope is sometimes also referred to as 'angular brushing' and is a very useful feature. I have seen some demos where the boundary values are defined interactively using a circle: a click opens up a circle, moving the mouse specifies a portion of that circle (as in a pie chart) that defines the bounding angles relative to some pre-defined value (e.g. the horizontal line).
@bbroeksema what do you mean by Extension two? Refining a brush to be applied within a given brush?

@bbroeksema

This comment has been minimized.

Show comment
Hide comment
@bbroeksema

bbroeksema Aug 18, 2014

Collaborator

@julianheinrich @syntagmatic re: extension two: The idea is: you first make a selection using regular brushes. Next, you take average or median values for each axis, and use these values for angular brushing. This can be used to, given a cluster of interest, find similar patters (or inverse) patterns which are not part of the initial selection.

Collaborator

bbroeksema commented Aug 18, 2014

@julianheinrich @syntagmatic re: extension two: The idea is: you first make a selection using regular brushes. Next, you take average or median values for each axis, and use these values for angular brushing. This can be used to, given a cluster of interest, find similar patters (or inverse) patterns which are not part of the initial selection.

@bbroeksema

This comment has been minimized.

Show comment
Hide comment
@bbroeksema

bbroeksema Sep 12, 2014

Collaborator

For your information: I started working on an implementation of pinch selection based on your blocks code. Initial code can be found here (for your reading pleasure):

https://github.com/bbroeksema/parallel-coordinates/compare/pinch

Note: this is just the pinch drawing code, not the actual selection. It will follow soon though. I'd be great if you keep an eye on the progress. Overall I think the implementation is pretty lean. If you've suggestions for improvement, don't hesitate to shoot!

Once I've the feature fully working, I'll give you another shout so you can have a look.

Collaborator

bbroeksema commented Sep 12, 2014

For your information: I started working on an implementation of pinch selection based on your blocks code. Initial code can be found here (for your reading pleasure):

https://github.com/bbroeksema/parallel-coordinates/compare/pinch

Note: this is just the pinch drawing code, not the actual selection. It will follow soon though. I'd be great if you keep an eye on the progress. Overall I think the implementation is pretty lean. If you've suggestions for improvement, don't hesitate to shoot!

Once I've the feature fully working, I'll give you another shout so you can have a look.

@bbroeksema

This comment has been minimized.

Show comment
Hide comment
@bbroeksema

bbroeksema Sep 12, 2014

Collaborator

@julianheinrich wrote:

sounds great! We should discuss how we handle bundling in the future: since it's based on curves, any features of PC will not be immediately available, and coding pinch or angular selection for curves (?) seems cumbersome.

Ah, hmm I didn't really think about that yet. Indeed, the blocks example of Kay assumes straight lines. Using this on curves would result in weird selections (i.e. lines being selected that aren't going through the pinch). I see two possible approaches:

  1. Now, I'm not a geometry wizard and I haven't had a close look at the curve code yet. However, I assume these curves have certain properties (e.g. they are either monotonously increasing or decreasing). Can each curve (i.e. a part of the full polyline, that is between two axes) be described as a single function? If so, we have basically two functions (one describing the curve, and one linear function describing the pinch line). I guess it shouldn't be too hard to figure out if these two functions cross in a given domain.
  2. Another approach might be a pixel based approach. This would require building up a quadtree (or some similar structure) telling which pixels 'contain' which polylines. To make this somewhat perfomant, we'd have to get to WebGL I think.

@julianheinrich wrote:

I realise that now and should have discussed with you before the pull request.

Well, there was not much activity of any of us around that time.

@julianheinrich wrote:

Of the top of my head, I can think of two solutions to solve this:

  1. leave bundling as a rendering mode, but without support of any of the new features to come (until implemented)
  2. take it out of the main branch and create an 'experimental' fork?

What are your thoughts on this?

The one thing that should be done at least is making sure that pinch selection cannot be enabled when curves are enabled as long as there is no support for curves in pinch selection. I think curves are a useful feature so I wouldn't argue at this point to move them out. What I can do as a simple safety measure is throwing an error when pinch is enabled while curves are enabled (and when curves are enabled when pinch is already enabled).

Collaborator

bbroeksema commented Sep 12, 2014

@julianheinrich wrote:

sounds great! We should discuss how we handle bundling in the future: since it's based on curves, any features of PC will not be immediately available, and coding pinch or angular selection for curves (?) seems cumbersome.

Ah, hmm I didn't really think about that yet. Indeed, the blocks example of Kay assumes straight lines. Using this on curves would result in weird selections (i.e. lines being selected that aren't going through the pinch). I see two possible approaches:

  1. Now, I'm not a geometry wizard and I haven't had a close look at the curve code yet. However, I assume these curves have certain properties (e.g. they are either monotonously increasing or decreasing). Can each curve (i.e. a part of the full polyline, that is between two axes) be described as a single function? If so, we have basically two functions (one describing the curve, and one linear function describing the pinch line). I guess it shouldn't be too hard to figure out if these two functions cross in a given domain.
  2. Another approach might be a pixel based approach. This would require building up a quadtree (or some similar structure) telling which pixels 'contain' which polylines. To make this somewhat perfomant, we'd have to get to WebGL I think.

@julianheinrich wrote:

I realise that now and should have discussed with you before the pull request.

Well, there was not much activity of any of us around that time.

@julianheinrich wrote:

Of the top of my head, I can think of two solutions to solve this:

  1. leave bundling as a rendering mode, but without support of any of the new features to come (until implemented)
  2. take it out of the main branch and create an 'experimental' fork?

What are your thoughts on this?

The one thing that should be done at least is making sure that pinch selection cannot be enabled when curves are enabled as long as there is no support for curves in pinch selection. I think curves are a useful feature so I wouldn't argue at this point to move them out. What I can do as a simple safety measure is throwing an error when pinch is enabled while curves are enabled (and when curves are enabled when pinch is already enabled).

@bbroeksema

This comment has been minimized.

Show comment
Hide comment
@bbroeksema

bbroeksema Sep 12, 2014

Collaborator

@julianheinrich wrote:

I have seen some demos where the boundary values are defined interactively using a circle: a click opens up a circle, moving the mouse specifies a portion of that circle (as in a pie chart) that defines the bounding angles relative to some pre-defined value (e.g. the horizontal line).

I think you mean this one: http://vimeo.com/13437693. Adding it for future reference.

Collaborator

bbroeksema commented Sep 12, 2014

@julianheinrich wrote:

I have seen some demos where the boundary values are defined interactively using a circle: a click opens up a circle, moving the mouse specifies a portion of that circle (as in a pie chart) that defines the bounding angles relative to some pre-defined value (e.g. the horizontal line).

I think you mean this one: http://vimeo.com/13437693. Adding it for future reference.

@syntagmatic

This comment has been minimized.

Show comment
Hide comment
@syntagmatic

syntagmatic Sep 13, 2014

Owner

I also think it's not worth thinking about curves+pinch at this point. The two features could simply be incompatible for now. Much of the interesting parallel coordinates geometry falls out only when polylines are straight (although I'm sure it can be worked out with curved geometries).

Even though Alfred Inselberg calls it a pinch, can we give it a different name? I suggest the word strum.

Strum
v. To play (a stringed musical instrument) by stroking or brushing the strings: strum a banjo.
v. To play (music) on a stringed instrument in this way: strum chords on a guitar.
v. To play a stringed instrument by strumming.

The reason I don't like "pinch" is that on touch devices, pinch is actually a very different gesture generally used for zooming in/out. Strumming to me evokes the idea of touching the polylines directly to activate them.

Owner

syntagmatic commented Sep 13, 2014

I also think it's not worth thinking about curves+pinch at this point. The two features could simply be incompatible for now. Much of the interesting parallel coordinates geometry falls out only when polylines are straight (although I'm sure it can be worked out with curved geometries).

Even though Alfred Inselberg calls it a pinch, can we give it a different name? I suggest the word strum.

Strum
v. To play (a stringed musical instrument) by stroking or brushing the strings: strum a banjo.
v. To play (music) on a stringed instrument in this way: strum chords on a guitar.
v. To play a stringed instrument by strumming.

The reason I don't like "pinch" is that on touch devices, pinch is actually a very different gesture generally used for zooming in/out. Strumming to me evokes the idea of touching the polylines directly to activate them.

@syntagmatic

This comment has been minimized.

Show comment
Hide comment
@syntagmatic

syntagmatic Sep 13, 2014

Owner

Also @bbroeksema, that interaction looks great. It's exactly what I expected, especially clicking the background to remove the intersecting line.

Owner

syntagmatic commented Sep 13, 2014

Also @bbroeksema, that interaction looks great. It's exactly what I expected, especially clicking the background to remove the intersecting line.

@bbroeksema

This comment has been minimized.

Show comment
Hide comment
@bbroeksema

bbroeksema Sep 13, 2014

Collaborator

Strum seems fine to me. It expresses well the actual action. I'll rename my code and files. Another thing I'd like to propose is the way we enable brushing, I'd like to make the API like:

parcoords.brushmode(mode);

Where mode is one of "axes", "strums". This avoids having all kinds of brush specific functions exposed.

Collaborator

bbroeksema commented Sep 13, 2014

Strum seems fine to me. It expresses well the actual action. I'll rename my code and files. Another thing I'd like to propose is the way we enable brushing, I'd like to make the API like:

parcoords.brushmode(mode);

Where mode is one of "axes", "strums". This avoids having all kinds of brush specific functions exposed.

@julianheinrich

This comment has been minimized.

Show comment
Hide comment
@julianheinrich

julianheinrich Sep 15, 2014

Collaborator

Hm strum sounds interesting, but I fear many users will get confused if we chose to use a different name for every brush. A consistent (though not very creative) way would be to use something like '1d brush', '2d brush' (the strum), 'angular brush', etc. They are all different ways of 'brushing' in different dimensions.
Another option is to remove the previous 1d brush, as the new 2d brush can also be used to brush in 1d. So whenever the library detects that the user is brushing within a certain proximity to an axis, we could switch to brush in 1d (for performance reasons) but keep the same visual metaphor as for 2d.

Collaborator

julianheinrich commented Sep 15, 2014

Hm strum sounds interesting, but I fear many users will get confused if we chose to use a different name for every brush. A consistent (though not very creative) way would be to use something like '1d brush', '2d brush' (the strum), 'angular brush', etc. They are all different ways of 'brushing' in different dimensions.
Another option is to remove the previous 1d brush, as the new 2d brush can also be used to brush in 1d. So whenever the library detects that the user is brushing within a certain proximity to an axis, we could switch to brush in 1d (for performance reasons) but keep the same visual metaphor as for 2d.

@bbroeksema

This comment has been minimized.

Show comment
Hide comment
@bbroeksema

bbroeksema Sep 15, 2014

Collaborator

@julianheinrich Well "users" are for now developers, as we only provide a component, not an application. How they present the different strums to the end-users is basically up to them. I like the different naming as it makes clear which parts of the code are for which mode. And after all, both strums and angular brushing are 2D, so we'd have to come up with a "slightly more complex" naming scheme anyhow.

I like the idea of automatically switching to a 1D brush based on axis proximity. Then it is basically only the 2D brush that needs to be configured. Though, the angular brush is something I need to start playing with and I'm not sure if it's interaction patterns would match well with an automatic switch.

btw: I just pushed another set of changes to the pinch branch, it's getting close to fully functional now for multiple pinches (or strums if you want). There are still a number of smaller issues to work out. I keep a list here: https://github.com/bbroeksema/parallel-coordinates/wiki

Collaborator

bbroeksema commented Sep 15, 2014

@julianheinrich Well "users" are for now developers, as we only provide a component, not an application. How they present the different strums to the end-users is basically up to them. I like the different naming as it makes clear which parts of the code are for which mode. And after all, both strums and angular brushing are 2D, so we'd have to come up with a "slightly more complex" naming scheme anyhow.

I like the idea of automatically switching to a 1D brush based on axis proximity. Then it is basically only the 2D brush that needs to be configured. Though, the angular brush is something I need to start playing with and I'm not sure if it's interaction patterns would match well with an automatic switch.

btw: I just pushed another set of changes to the pinch branch, it's getting close to fully functional now for multiple pinches (or strums if you want). There are still a number of smaller issues to work out. I keep a list here: https://github.com/bbroeksema/parallel-coordinates/wiki

@bbroeksema

This comment has been minimized.

Show comment
Hide comment
@bbroeksema

bbroeksema Oct 21, 2014

Collaborator

As of e42b7a4 we have basic strum support.

Collaborator

bbroeksema commented Oct 21, 2014

As of e42b7a4 we have basic strum support.

@bbroeksema bbroeksema closed this Oct 21, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment