kanitw
commented
6 years ago Thanks for your detailed report. Here are my replies.
-
I agree with issue A and B. I'll fix it when I have time.
-
For issue C, the size is actually using a linear scale but it won't preserve the magnitude like if you set type to
"quantitative"rather than"ordinal". I agree that with varying shape, the size is not preserved very well. However, we simply use Vega scales in this case. If you wish for a better size scale for shape, please file an issue in the Vega repo. -
For D, this seems like a bug. Thanks for catching.
-
For E, I can see that there could be a better support. We plan to support encoding block for axis/legend, which is equivalent to encode axis/legend in Vega. With this support, you can work around by providing another equivalent shape that is smaller. If you desire for better automatic rescaling, this has to be done at the Vega level. So please file another issue in the Vega repo.
-
For F, this also seems like a bug. Thanks for catching.
TODO
- [x] Fix A
- [x] Fix B
- [x] Fix D
- [ ] Fix F
domoritz
Sorry for the long post but I think the following issues are related so I thought it clearer to keep together for the moment. While some are more points for discussion, I think there are also some bugs too. They all relate to encoding with shape and other channels.
All examples can be found in this block
Issue A
Encoding ordinal data with the shape channel generates two warnings:
Shape channel should be used with nominal data onlyUsing discrete channel "shape" to encode "ordinal" field can be misleading as it does not encode order.I would argue the second of these warnings is helpful and is consistent with Bertin's recommendations, but the first is unnecessary, being both too strong and redundant given the second one. I think there are limited cases were encoding ordinal data with shape is meaningful, or at least not entirely wrong (espeically if using custom shapes). One can eliminate the warning by casting an ordinal field as nominal, but this seems semantically incorrect.
Issue B
Encoding ordinal data with the size channel generates the warning:
Channel size should not be used with discrete field.For nominal data that warning makes sense, but for ordinal data it contradicts Bertin's recommendation. There are certainly cases where encoding ordinal data with size can be valid. Perhaps a more cautious warning would be better, such as
Care should be taken when using channel 'size' to encode an 'ordinal' field as this can sometimes give a misleading impression of relative magnitude.Issue C
Related to Issue B, when encoding ordinal data with size, the relative sizings appear neither linear or quadratic, see for example:
The inconsistency in size is even more apparent when double encoding with shape:
Perhaps consider a more balanced scaling? There is an opportunity here to use a Flannery perceptual scaling.
It would appear that when using custom SVG paths (example below uses SVG path for square of unit size) to represent shapes, the relative sizing is better, so there appears to be at least an inconsistency here:
Issue D
When a mark has
"filled": true, the legend correctly fills the symbols when fields are encoded by size, shape or opacity. But if a separate field is encoded by colour, the shape, size legend items are no longer filled. This is inconsistent with the other legend rules (a default circle is used in both legend sets, but the default blue is not).Issue E
Use of custom SVG path shapes seems to assume an area of around 1 (in pixel coordinates). If a larger area is used, which can be legitimate in some cases such as Isotype symbolisation, the legend uses the size of the custom shape rather than scaling it to fit within a line of legend text:
I think this is a bug rather than feature, but in fixing it there is an opportunity to clarify in the documentation what an appropriate area for custom SVG path symbols should be.
Issue F
When double-encoding a custom shape with another channel (or triple-encoding or higher), the legend separates the shape from other encodings. This is inconsistent with the legend rules for default shapes (which are correctly combined) and creates unnecessarily verbose legends for custom shapes:
This may be related to issue D.