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

Option to prevent symbol truncation at ternary axis boundaries #1385

Closed
geocosmite opened this issue Feb 15, 2017 · 10 comments
Closed

Option to prevent symbol truncation at ternary axis boundaries #1385

geocosmite opened this issue Feb 15, 2017 · 10 comments
Assignees

Comments

@geocosmite
Copy link

I have scoured the documentation but have been unable to find a way to prevent symbols from being truncated by axis boundaries. While you can avoid the problem by extending the boundaries beyond what you would normally use for the 'scatter' plot type (to slightly below zero for instance for cases where zero is the minimum data value), this is not a possibility with the 'scatterternary' type, at least for cases where points lie on an axis or apex.

To see the impact of the symbol truncation consider the plot below left where points at the apices are almost invisible and those in the middle of the axes also are quite small. This display is problematic because the center point has much greater visual heft compared to the remaining points, particularly compared to those on the apices. The preferred plotting approach is depicted on the right where each point has an equal visual weight irrespective of its position on the plot.

image

@etpinard
Copy link
Contributor

Thanks for pointing this out.

@geocosmite
Copy link
Author

My pleasure! I appreciate your taking the time to consider the issue.

What do you think about the idea of having a boolean attribute to provide the desired behavior? The default value could be true to be consistent with the current implementation but false would produce a plot analogous to the "desired display" example above.

In most cases my guess is that you would either want no truncation of markers at the axes at all on the plot or to have the plot behave as it does now so this attribute could be defined at the top level of layout (markeraxistrunctate?). I suppose, however, that having the ability to define this attribute on the axis (markertruncate?) or the trace marker (axistruncate?) levels would allow for finer-grained control at the expense of a more verbose configuration.

@etpinard etpinard self-assigned this Mar 10, 2017
@etpinard etpinard changed the title Option to prevent symbol truncation at axis boundaries Option to prevent symbol truncation at ternary axis boundaries Apr 10, 2017
@etpinard
Copy link
Contributor

etpinard commented Jun 2, 2017

Quick question: should the marker point be placed above the axis tick labels?

image

Or should they be placed in-between the axis bounding line and tick labels?

image

@geocosmite
Copy link
Author

Hi Étienne. Thanks for the question. The marker points near the axis boundaries should go on top of the axis line and tick labels. My rationale is that this seems to be more consistent with the objective of ensuring that they have visual weights that are equivalent to their counterparts near the center of the plot region.

@etpinard
Copy link
Contributor

etpinard commented Jun 21, 2017

I've made some solid progress on this ticket this week. You can track my WIP branch here:

https://github.com/plotly/plotly.js/compare/cliponaxis-false

At this stage,

  • I named the attribute cliponaxis. This attribute will be available from scatter and scatterternary trace and eventually for scattergeo as well.
  • By default, cliponaxis is set to true (the current behavior)
  • When turned on, markers, elements won't be clipped (new behavior)
  • I'm thinking that also text and errorbars could benefit from cliponaxis: false

Quick question: how should we determine if a non-clipped marker is visible or not? Intuitively, markers that have x or/and y strictly beyond the set axis range should be removed. But, should we include the marker size in this calculation? That is,

  • Should all markers that touch the axis bounds be visible?
  • Or, should all markers that are centered on the axis bounds be visible?

@geocosmite
Copy link
Author

geocosmite commented Jun 21, 2017

Great to see that you've made such good progress Étienne! The cliponaxis attribute sounds perfect and I agree that it would be great if it also applied to text and errorbars.

Regarding your question, if a marker point has a value that puts it outside of the axis range (i.e., its center is outside of the plot range) it should be removed irrespective of the symbol size. As you say, points that sit exactly on an axis, however, should be visible.

@etpinard
Copy link
Contributor

Regarding your question, if a marker point has a value that puts it outside of the axis range (i.e., its center is outside of the plot range) it should be removed irrespective of the symbol size. As you say, points that sit exactly on an axis, however, should be visible.

Thanks very much for the prompt response 👍

@etpinard
Copy link
Contributor

etpinard commented Jul 5, 2017

After some thoughts, maybe implementing cliponaxis: false for error bars isn't such a great idea.

Error bars positions are set in data coordinates unlike marker symbols and text size (which are set in pixel coordinates).

Furthermore, in matplotlib's clip_on=False option undoes marker points axis clips, but still clips error bars - see https://gist.github.com/etpinard/9167c1c69144e318ca2aa39539ec5091

cc @alexcjohnson

@secretwpn
Copy link

@etpinard sorry to revive the old ticket but is it possible to also support this in scattergl?
Currently if i switch to scatter it works but not in scattergl.

@alexcjohnson
Copy link
Contributor

Old indeed - feel free to open a new issue if you want to continue the discussion, but my hunch is this would be pretty hard in scattergl, as the rectangular viewport is baked in at a fairly low level

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

No branches or pull requests

4 participants