dataAspectRatio option

[Fil]

Questions:

• [x] name? (~~daspect,~~ dataAspectRatio, ~~height = square~~)?
• [x] application to other scale types? (time, utc at least, maybe band scales too?)
• [x] position? (middle/left/right/top/bottom, top-left etc)?
• [x] syntax (number, array [x, y], number and position (top-left…)?

closes https://github.com/observablehq/plot/issues/836 closes #445

[mbostock]

I was thinking something different for this feature, which is that if you specify this option (which I’d probably want to call aspectRatio), it would compute the necessary height based on the given (or default) width and margins. Meaning, we’d compute this in autoHeight rather than in autoScaleRange.

Another thought: if we don’t want to introduce option is that we could have a special named value for the height option, such as height = square for a 1:1 aspect ratio.

[Fil]

Agree, this will result in much nicer charts (my approach was creating a lot of whitespace).

[Fil]

the last remaining issue is the name of the option.

• aspectRatio doesn't mention that we're speaking about the data/scales/channels, but not the chart's aspect ratio
• daspect sounds awfully technical
• dataAspectRatio is quite a mouthful
• height: "square" doesn't connect (in my brain) with this concept

Another element that we might want to address at a later stage is if we want to size r with the same logic as x and y (for example, if x and y represent metric positions, and r an euclidian distance).

[yurivish]

If there is ever a future option able to set the “data width” and “data height” then maybe the mouthful is worth it. To me dataAspectRatio does a good job of capturing the meaning of the option.

[Fil]

rebased on main

[Fil]

rebased on main cc: @mootari

[tophtucker]

I love this. I was scared to look at the diff but the actual change without tests/docs is 25 lines! 😅 ❤️ Not an expert but looks good and non-invasive.

It's restricted to "utc", "time", and "linear" because those are the only linear scales, and this is only possible for linear scales, right? Might add that to the readme. I like being able to mix "utc"/"time" and "linear" (spacetime diagrams! natural units with aspect ratio of c!). The milliseconds spanned by a temporal x axis usually dwarfs the number of units on the y axis, but it's wonderful if you have relative time in ms on the y axis!

I agree with Yuri that dataAspectRatio suggests the meaning well. I also think aspectRatio would be fine. It's trivial to control the outer frame's pixel-space aspect ratio (width = height), so maybe it's fine to give the shorter name to the nontrivial option? I guess it’s like the aspect ratio of the “grid”, of the plane, of the fabric of reality lol. What does “aspect” mean anyway? It’s the ratio of 1 in x to 1 in y… unitRatio lol. Idk. Whatever! But very valuable feature!

I love the Libor test! Let me know if I can help.

[Fil]

Thank you for the enthusiastic support. The feature could be expanded in the future but we're currently constrained to linear scales because of the wording:

a variation of one unit in the x dimension is represented by the same number of pixels There may be a case for a non-linear dataAspectRatio where x and y share a common domain.

You can totally daspect time (utc) vs duration (milliseconds), see https://observablehq.com/@recifs/dataaspectratio-837

Wording for the README might be: both x and y must be linear (including time scales, for which the unit is the millisecond)?

[mbostock]

This would be useful for a lot of raster mark applications, too.

[mbostock]

(I am not sure the treatment is 100% correct with respect to padding in ordinal scales, but it’s probably “close enough for now” and we can improve it later.)

[Fil]

Re: padding in ordinal scales, I don't think we'd want the autoheight to change when the user specifies a padding (or outer/inner padding), which means the correct approach is to ignore these and base the computation on their default values, as you do here.

Same story with the round option, whose actual value should be ignored, and we should consider only the default. And that's where the computation is not currently perfect, because the default is true, and rounding does not necessarily result in the same bandwidth values for x and y. This is similar to https://github.com/observablehq/plot/issues/1239