Aspect ratio key for 2d plots

[jackparmer]

Similar to:
https://plot.ly/python/reference/#layout-scene-aspectratio
For 3d plots

[n-riesco]

@jackparmer I'm not entirely clear what the API would be.

For gl3d, the API is layout.scene.aspectratio: { x: number, y: number, z: number }.

What'd it be for gl2d (layout.????.aspectratio: { x: number, y: number })?
gl2d only has exports.attr = ['xaxis', 'yaxis']

cc/ @etpinard @mdtusz

[etpinard]

I'm not entirely clear what the API would be

I'm not sure either.

@jackparmer are you referring to the aspect ratio of the either graph OR of each xy subplot?

If the former, then a layout.aspectratio attribute could be used to pre-populate layout.width and layout.height.

If the latter, then ... hmm there's no obvious way to add aspectratio in 2D graphs in our current schema.

I'd vote for the former. Since, our layout.?axis.domain are in normalized coordinates (i.e. in [0, 1]), 2D subplot will adjust proportionally under resize given a layout.aspectratio - which I think is the desired effect. cc @cpsievert @alexcjohnson

Moreover, maybe this issue could be merged with #106 ?

[alexcjohnson]

There are two separate issues here. One is making sure the overall plot keeps a nice shape when the window is resized - like if you have a responsive webpage, it would be cool if the plot could take its width from the container element and its height from this aspect ratio. That should work fine with layout.aspectratio.

The second is where the data on a plot has a 2D metric, like if you're showing physical positions in two dimensions, or in momentum space, really anything where x and y have identical units so relative scales and angles are meaningful. The first (layout.aspectratio) can be used to solve this problem, though not if you allow zooming, not if you allow auto-margin, and anyway you have to do a bunch of calculations to get it right even in the beginning. Really we need something per-subplot that enforces pixel equivalence in the two directions. This is tricky for a multitude of reasons:

• API - as already mentioned, we don't have per-subplot settings for cartesian, we only have per-axis settings. That might be a blessing in disguise though, as you can't have more than one constraint per axis.
  • one option: define axis.constrainwith and axis.aspectratio. I would think that if you provide neither, then both are omitted, but if you provide constrainwith then aspectratio defaults to 1, and if you provide aspectratio then constrainwith defaults to axis.anchor, or the first counteraxis if anchor=='free'.
  • another option: define something like layout.xy_aspectratio which could perhaps be just a number for simple plots (or to give all subplots the same ratio), or an object like {xy: 1, x2y: 2} (my comments below about couplings should apply just as well if we choose this form, except that the obviously silly contradiction wouldn't be possible, but a circular reference could still be created out of 4 subplots).
• couplings - what happens when you have two subplots sharing an x axis, with two y axes that both want to enforce an aspect ratio? We could certainly start out allowing only one constraint per axis, but eventually someone will want subplots sharing an axis and both to have aspect ratio constraints. But with a 2x2 or bigger layout, if all x and y axes had aspect ratio constraints you could actually define a self-contradictory system:

xaxis: {constrainwith: 'y', aspectratio: 1}
yaxis: {constrainwith: 'x2', aspectratio: 1}
xaxis2: {constrainwith: 'y2', aspectratio: 1}
yaxis2: {constrainwith: 'x', aspectratio: 2}

In fact you could say something obviously silly:

xaxis: {constrainwith: 'y', aspectratio: 1}
yaxis: {constrainwith: 'x', aspectratio: 2}

I think for the most general case we need to allow both x and y axes to define constraints, otherwise there would be no way to create a legitimate fully-constrained 2x2 layout, or even three subplots (central, top, and right, for example). We could just say it's an error to define a circular constraint reference, that should avoid this problem.

• conflict resolution - say the user specifies both x and y ranges, as well as aspect ratio. What do we do? It seems like we want the aspect ratio to be enforced, and probably only show more than what was asked for, ie never reduce a range, only expand (symmetrically). Similarly for autoscale, just symmetrically expand one axis. But then what happens if someone resizes the plot multiple times, does the range keep growing (ie the x range grows when you make the plot wider, then the y range grows when you make it narrower...)? Or does it somehow remember what the last range was that the user really asked for, and size based on that? Maybe it would work to have layout just keep what the user asked for, and _fullLayout the recalculated (expanded) ranges?
• zoom - I already had to do one form of constrained zoom for ternary Ternary phase diagrams #390 - and I suspect we could do something similar here for the main zoom... like the smallest rectangle that contains the start and end points of the drag, centered in the direction that needs to be bigger than you've dragged. But for ternary I totally ignored the single-axis and corner draggers. At least initially we could do the same here too, though I imagine we could come up with fairly compelling arguments as to what should happen with each of these draggers. Corner draggers could just project your drag onto the diagonal from that corner to the opposite one. Single-axis pan draggers (and 2D pan) are no problem as they don't alter aspect ratio. Single-axis endpoint draggers (And again for coupled subplots, where one axis change is triggered by the main or corner draggers of a different subplot), the obvious choice seems that the counteraxis should get a symmetric change keeping the same center point.

[cpsievert]

I agree there are two different types of ratios, one which ignores the data range (in ggplot2, this is theme(aspect.ratio = ...)), and another which scales to the data range (in ggplot2, this is coord_fixed()). That being said, I can't think of any scenarios where I would want different aspect ratios, so maybe we could get away with just layout.aspectmode and layout.aspectratio?

By the way, the main idea behind plotly/plotly.R#509 is to essentially ensure ratio = diff(layout.yaxisid.domain) / diff(layout.xaxisid.domain) for each relevant combination of axes. The problem I ran into was that, in some cases, domains have to be recomputed on resize, which requires moving a bunch of logic to the browser (I've generally been trying to avoid as much as possible to provide a consistent experience in viewing local vs. remote plots). If need be, I suppose I could disable autosize, but it'd be nice to have a more general solution.

[alexcjohnson]

@cpsievert right, this has to be done in the js library itself for the aspect ratio to survive nearly all our interactivity. I suppose you're right that having different aspect ratios on different subplots is an unusual case, but having some subplots that want a fixed ratio and others that don't seems like a fairly common case, at which point we've nearly arrived at each one supporting its own aspect ratio anyway.

[cpsievert]

having some subplots that want a fixed ratio and others that don't seems like a fairly common case, at which point we've nearly arrived at each one supporting its own aspect ratio anyway.

True, I suppose it would be nice to have that flexibility if it's doable (just FYI, I won't need this for our ggplot2 converter). In that case, from a user perspective, it might be nice for subplot specific ratios to inherit from a global ratio.

[n-riesco]

Thanks everyone for the discussions. I feel they help make the problem more clear in my mind.

The issue with the layout aspect ratio, as @etpinard said, could be addressed by letting layout.width and layout.height take percentage sizes (issue #106).

On the other hand, from @alexcjohnson 's comment, I now understand that setting the subplot aspect ratio through layout.xaxis is not only very complicated for the user but also it may lead to inconsistent circular constraints.

Currently, gl3d sets the aspect ratio using layout.scene.aspectratio: { x: number, y: number, z: number } and layout.scene.aspectmode. I find this way of specifying the aspect ratio easier than using a ratio (no need to remember whether the ratio is x/y or y/x, y/z, ...

Assuming the layout aspect ratio is specified using percentage units in layout.width and layout.height, layout.aspectratio could be used to specify a table of subplot aspect ratios (similarly to what Alex described), i.e. layout.aspectratio: {xy: { x: number, y: number }, x2y: { x: number, y: number }}.

Instead of defining another table for the aspect mode (layout.aspectmode), we could include this field in layout.aspectratio, like this:

layout.aspectratio: {
    xy: {
        mode: enumerated,
        x: number,
        y: number
    },
    x2y: {
        mode: enumerated,
        x: number,
        y: number
    }

What do you think? Would something like this work?

[cpsievert]

To be a little more clear, I would be estatic with layout.aspectmode/layout.aspectratio that fails (silently) in cases where setting the aspect ratio doesn't make sense. In fact, this is exactly what ggplot2 does:

library(ggplot2)
ggplot(mtcars) + 
  geom_point(aes(wt, mpg)) + 
  facet_wrap(~vs) + 
  coord_equal()

versus

ggplot(mtcars) + 
  geom_point(aes(wt, mpg)) + 
  facet_wrap(~vs, scales = "free_x") + 
  coord_equal()

So, in other words, when layout.aspectratio="data" and there are multiple x/y ranges, it fails to set the aspect ratio. Couldn't we do the same? Specifying aspect ratio at the axis-level seems complex, error-prone, and more flexible than most would need/want.

[rreusser]

Some various use-cases of aspect ratios:

• physical space (obviously). Maybe science-biased? e.g. https://plot.ly/~empet/14243 but also just anything representing physical space, e.g. basketball courts
• mathy stuff—circle, square, polygon, triangle, e.g. http://codepen.io/rsreusser/pen/GjZwYb Or anything where euclidean distance is meaningful (graphs?)
• Principle Component Analysis (PCA): I haven't used this enough to know how the dimensions of the axes usually turn out, but a 2D gaussian, for example, has meaningful scale:
  
• Multidimensional Scaling (MDS): by definition seeks to map things into nice 2D space—which then requires a meaningful aspect ratio
• Biplots
• More from statistics
• More examples from @cpsievert https://vimeo.com/190011823
• Maps