Bug: areaY tip/pointer position wrong for stacked data

[Hvass-Labs]

(Solutions and options are shown here: https://observablehq.com/d/d091c93672b14460)

There seems to be a bug when using the tip/pointer interaction on an areaY mark with stacked data. This is part of a larger web-application, but essentially what I do is the following:

Plot.plot({
  marks: [
    Plot.areaY(data, {x: "Date", y: "Value", stroke: "Name", fill: "Name", fillOpacity: 0.5}),
    Plot.tip(data, Plot.pointer({x: "Date", y: "Value", stroke: "Name"})),
  ],
});

Notice in these screenshots how the tool-tip overlay is positioned wrong for the orange area. You cannot see my mouse-pointer, but it is positioned next to the notch in the overlay.

Also note the plot looks a little confusing when the orange area switches between negative and positive. I imagine it is because the lines are interpolated. I don't know if anything could be done about that, but it would of course be a separate issue.

Thanks!

[Fil]

You could try and add an explicit Plot.stackY transform in the options for the tip mark (the areaY mark does not need it because it stacks implicitly).

[Hvass-Labs]

I have tried your suggestion, but it is not obvious to me how this should be done, because of the several layers of nesting and I don't understand your API that well. For example, the following actually makes it worse, because now both the orange and blue areas have the wrong position for the tool-tip:

    Plot.tip(data, Plot.pointer(Plot.stackY({x: "Date", y: "Value", stroke: "Name"}))),

How specifically would you get this working?

And is there a technical or design reason that the user must do this manually? As a user I would expect this to be done automatically behind the scenes.

Thanks.

[Fil]

Please share a notebook with your current status.

[Hvass-Labs]

I don't use your Notebook system. This is part of a web-application. The data comes from a database and I do some extra processing for efficiency. It would take me a while to make a full working example I could post here. Is that necessary?

[Hvass-Labs]

Please see this simple example of the problem: https://observablehq.com/d/d091c93672b14460

Using stackY helps but the pointer / crosshair is still not aligned properly. How would I do this correctly?

I can't find anything about this in the docs, so it might be a good idea to add a section about this.

Thanks!

[Fil]

For a timeline (or any other line or area chart where the x dimension is dominant), we recommend using Plot.pointerX instead of Plot.pointer.

[mbostock]

As @Fil said, you need to make the stack transform explicit if you are using it with the tip mark; the area mark applies it implicitly, but the tip mark does not. But there’s no reason to use the tip mark explicitly here when you can use the tip option instead, and then you can continue to benefit from the implicit stack transform provided by the area mark. That looks like this:

Plot.plot({
  marginLeft: 50,
  y: {
    grid: true,
    label: "Unemployed (thousands)"
  },
  marks: [
    Plot.areaY(unemployment, {x: "date", y: "unemployed", fill: "industry", tip: true}),
    Plot.ruleY([0])
  ]
})

I also removed the “↑” from the label since the arrow is applied implicitly by the axis (though see the labelArrow option) and you don’t want it in the tooltip. And I removed the title option from the area mark, since it was competing with the tip mark, resulting in duplicate tips.

I don’t see the problem you describe with the position of the tooltip; it looks correct to me in the screenshot above. Note that for an area mark (or any mark with y1 and y2 channels) the tooltip will be positioned in the vertical center of the band, not on the top of the band. If you want the tip to be on the top of the band, you can again make the tip mark explicit and then use the stackY2 transform instead of stackY.

Plot.plot({
  marginLeft: 50,
  y: {
    grid: true,
    label: "Unemployed (thousands)"
  },
  marks: [
    Plot.areaY(unemployment, {x: "date", y: "unemployed", fill: "industry"}),
    Plot.ruleY([0]),
    Plot.tip(unemployment, Plot.pointerX(Plot.stackY2({x: "date", y: "unemployed", fill: "industry"}))),
  ]
})

I don’t know what to say regarding the other confusion with negative/positive values in the stacked area. What would you expect to see instead? Edit: Looks like you filed a separate issue for this in #1963 so let’s not discuss this further here.

[Hvass-Labs]

Thanks very much for the detailed answer!

I find it confusing when the tip / crosshair is placed in the middle of the data-area, and I also don't like how the tip snaps to strange invisible points. It was only after your explanation that I realized they were the mid-points of the data-areas. I prefer when the tip / crosshair is shown at the top of each data-area. It didn't occur to me that there was a stackY2 transform for doing that :-)

I have updated my Notebook with the different options and solutions, in case it may help others in the future: https://observablehq.com/d/d091c93672b14460

[Hvass-Labs]

Oops, I closed this too soon. On closer inspection there is a difference in the numbers shown in the tips. When using stackY it shows the tip in the middle of the data-area with the actual value for that particular data. But when using stackY2 it shows the tip at the top of the data-area as I want, but the value is now the sum of all the data-areas beneath it, which I don't want.

I want to show the tip at the top of each data-area, but only with the value for that particular data-area, and not summing all the areas below. Is that possible?

Thanks!

[mbostock]

I’m sure it’s possible, say using the channels and format options, but I’ll leave it to you to figure out. It might be worth filing a feature request to allow controlling the placement of the tip anchor in the case of paired channels (y1 and y2 or x1 and x2)… we could maybe use the existing frameAnchor option for that. There are already quite a few anchor-related options (anchor, preferredAnchor, frameAnchor, textAnchor).

[Hvass-Labs]

Thanks. I've experimented some more with this, and the standard behavior of the tip is pretty good. I think I will use it as is, at least for now, and maybe get back to this in the future if necessary.

To summarize, my two issues are:

1. When showing a single data-area using areaY the tip is automatically placed at top, but it is placed in the middle when showing stacked data-areas, which is a bit confusing at first. Using stackY2 shows the tip at the top, but then the number shown in the tip is summed of all the stacked data-areas, which I don't want in this case.

2. Because the tip snaps its position to the nearest data-point, it can look quite "jittery" when the mouse moves. I wonder if it might be possible to only snap on the x-axis while the y-axis position of the tip is that of the mouse-pointer. I think that might alleviate the "jitter".