Closed kanitw closed 3 years ago
@willium I actually start to think that this one might be a better to begin with. :)
Start with trying to see how to extend Vega spec first, more details about where do you have to extend the code will follow. We can chat more tomorrow evening or next week if you’re around as well.
@kanitw just wondering what should happen if the bar goes all the way to the top. If the label is outside, we may have to change the layout.
Other than that, yes, this is a great issue for @willium.
@domoritz That's a good corner case, but let will begin with putting it on the top / on the right first.
orient
is top
or right
@kanitw seems relatively straight forward -- To clarify, this is different than a tooltip in that you want the text to always show above all bars (or on the sides depending on orient) without hover. Essentially an extension of https://github.com/vega/vega/wiki/Tutorial#bar-chart-specification and the code that makes that work for vega-lite as well. So:
@domoritz This text overflow case seems to be broken in the vega example https://github.com/vega/vega/wiki/Tutorial#bar-chart-specification as well
@willium yep. You're right. It's basically should be the same as "label" shelf in Tableau.
I think currently Vega does not have a way to add additional offset to the scale when drawing domain from data, but this feature might come in handy in this case and #374
By this I mean, if the data ranges from [0, 100] if we can add property like domain.upperBoundOffset
and thus main the scale's domain become [0, 120]. That might be useful. But since we don't have it yet, let's not worry about it yet.
Hey @kanitw @domoritz, so I just re-started on this. I have a vega example showing labels as text mark types, pretty straight forward: https://gist.github.com/willium/f3ffa817ac87f40c2e54.
Now moving on to the vega-lite: It seems like vega-lite has both text and label within channels (what's the difference semantically?), and vega-lite doesn't have many examples with multiple marks within one document, leading me to believe that's not intended as it is in vega. Would this be a channel encoding of the data with vega-lite? In this case I'm not sure what new features I'm inventing vs. how much I'm just building an example for an existing feature set. Are labels entirely unsupported by vega-lite as-is? Would love some more information/guidance to make sure I'm understanding the issue at hand entirely.
Excellent. The example looks great.
Labels are used inside axes. Labels refers to the annotations of axes that shows categories or values of a quantitative domain. The text channel is to draw text marks that are driven by the rows is the data (labels are driven by the domain of the data). For the bar labels (for lack of a better term, maybe annotations), you created another text mark with similar properties as the rect mark.
Vega-lite has a text channel and a text mark. Right now the text channel only works for the text mark (you use that when you create a table). So for implementing the labels, we have two options.
First, there could be a annotation: true | false
option on the field def or in the config. Second, we could add a labek channel for labels/annotations for bar charts (and also scatter plots later). For example
{
"mark": "bar",
"encoding": {
"x": {"field": "Origin","type": "nominal"},
"y": {
"field": "Horsepower",
"type": "quantitative",
"aggregate": "mean"
},
"label": {
"field": "Horsepower",
"type": "quantitative",
"aggregate": "mean"
}
},
"data": {"url": "data/cars.json"}
}
The second option is more flexible because you could have other data driving the annotation/ label but also repetitive for the common case. However, let's implement the general case first and then add a shorthand.
@kanitw Why did you suggest to add a new label channel rather than using the existing text channel? I couldn't think of a case where we we need both cases.
Whenever we add a feature to vega-lite, we have to think about how we design the API. It usually helps me to think about how I would expect the API to look like for specific cases and see what the best general case is. If you want, you can sketch a few json objects and post them here and we can give you feedback.
@willium
Are labels entirely unsupported by vega-lite as-is? Would this be a channel encoding of the data with vega-lite?
Yes. It is not supported yet, but I have recently added some scaffolding for the new label channel in #885.
When a label channel is used, we need to add another vega marks group (as done in the scaffold here. Once each <mark type's namespace>.labels(model)
property returns a mark properties for the label mark group (which would be a Vega text mark), then label would be supported.
In this case I'm not sure what new features I'm inventing vs. how much I'm just building an example for an existing feature set.
For this issue, you would need to fill bar.labels(model)
in compiler/marks.ts
. (You can see that I put TODO(#64)
.)
Note for @domoritz's comment:
Labels refers to the annotations of axes that shows categories or values of a quantitative domain. This definition refers to "axis labels", not labels in general. In this issue, we are talking about labels of bar marks.
@kanitw Why did you suggest to add a new label channel rather than using the existing text channel? I couldn't think of a case where we we need both cases.
We never need both but they are semantically different. I was thinking about whether to use text
to represent label too, but after careful consideration they are not the same thing and thus shouldn't use the same name.
Semantically, there are differences between (1) Mapping a field to text channel in text mark. This modifies property of the main mark group. Semantically, this is the text of the text mark, not its label. (2) adding marks label to other marks such as bar. This is not a text encoding because a bar should not have text by default, unless it's a label of the bar. When applied, this also adds a new Vega mark group with mark type (text), which semantically serves as label of the marks.
First, there could be a annotation: true | false option on the field def or in the config. Second, we could add a labek channel for labels/annotations for bar charts (and also scatter plots later).
We are obviously going for the second here. I don't know if we even need the first one, which is just a syntactic sugar.
Right now the text channel only works for the text mark.
With this design, text mark is the only mark type that contains text and therefore should remain the only mark that supports text channel.
Hey, in will/bar-label I was able to get close to desired behavior (tested with https://gist.github.com/willium/3e09be5fbf8bbfbc972e). A few more values are hardcoded in than I'm comfortable with (mult w/ dy doesn't work, the offsets, and color). Also didn't get a chance yet to look at #374/domain.upperBoundOffset (as you mentioned @kanitw).
Note: an early attempt for this was in PR #1406.
Nice example: https://github.com/vis4/co2-history/
Nice example: https://github.com/vis4/co2-history/
This also demonstrates another case that we need to support line breaks in Vega text marks too.
We now have a labeling channel #7222
Just always put numbers outside like I add 28, 55 below (same for all bars — I’m just adding this by hand so I added only the first two.)
label
encoding channel tochannel.ts
and the schemamarks.ts