[bug] wrong range values for boxplot of layout type category

[destradafilm]

When I inspect the range returned after the 'plotly_selected' callback in a boxplot with a categorical axis. I get the string values which is fine

But, if I want to get the pixel values or better yet the range that the selection translates to, I get strange results.

I tried d2p and d2c (c2p and c2r didnt produce any results)
and the results dont seem right. I believe there is a bug here unless I'm wrong

See the screen shot below

Here is the codepen:
https://codepen.io/destrada/pen/EzKeMb

[alexcjohnson]

[undefined, undefined] certainly looks like a bug. Thanks! Presumably we're trying to convert back to d "data value" format, but that doesn't make sense for categorical axes - for these we should be using c "calcdata", ie based on the category serial numbers.

(Note that if we ever get around to the log-range breaking change this will just be the r "range" format, as that will be defined as "d for all continuous axis types, c for discrete axis types." Right now it's not the same as r because log ranges are specified by their log values.)

[destradafilm]

@alexcjohnson right, that's what I assumed that I should be using the c formating but none of those worked for me, even when I had actual values returned from the callback (not undefined)

what I'm looking for are 2 things

• what is the range that the selection translates to (current range for axis is range: [-2, 4]
• what are the pixels that the selection translates to

Also, any chance there's documentation for these conversions anywhere? I basically had to try all of them 'trial and error' to find the best conversion function

[alexcjohnson]

any chance there's documentation for these conversions anywhere?

Good question, @etpinard ? The only place I'm aware of is buried deep in the code:

plotly.js/src/plots/cartesian/set_convert.js

Lines 40 to 55 in e26f8f4

	* d: data, in whatever form it's provided
	* c: calcdata: turned into numbers, but not linearized
	* l: linearized - same as c except for log axes (and other nonlinear
	* mappings later?) this is used when we need to know if it's
	* *possible* to show some data on this axis, without caring about
	* the current range
	* p: pixel value - mapped to the screen with current size and zoom
	* r: ranges, tick0, and annotation positions match one of the above
	* but are handled differently for different types:
	* - linear and date: data format (d)
	* - category: calcdata format (c), and will stay that way because
	* the data format has no continuous mapping
	* - log: linearized (l) format
	* TODO: in v2.0 we plan to change it to data format. At that point
	* shapes will work the same way as ranges, tick0, and annotations
	* so they can use this conversion too.

That describes what the letters d/c/l/p/r mean, so you can extrapolate to the x2y functions. Perhaps we were trying to keep our options open, thinking if we don't document these functions we can change them without considering it a breaking change? 🙈 But obviously people like yourself have found them and depend on them so at this point we really should document them publicly.

[etpinard]

But obviously people like yourself have found them and depend on them so at this point we really should document them publicly.

Or include px values as part of the event data.

[destradafilm]

Or include px values as part of the event data.

and the range values (of the selection box) too?