scatter hover - how to remove coordinates?

[michael-imbeault]

I'm using scatter with hover=True and a few attached columns - however the x,y coordinates are also part of the hover output - is there currently an easy way to get rid of those? hover_cols only allow you to add parameters to the hover output, not remove.

[ea42gh]

Is this what you are asking for?

from bokeh.models import HoverTool
# Syntax: $. are 'special fields':  $x inserts the x-coordinate
#         @. are fields from the color data source:
#            provide an extra column of values and declare its name as a vdim

data  = pd.DataFrame( { 'x': [1.1, 3.2, 5.8 ], 'state': ['NY', 'NJ', 'PA'], 'stuff': ['a','b','c']} )
hover = HoverTool(tooltips=[("error", "$x"),
                            ("state", "@state"),
                            ("stuff", "@stuff")
                           ])
hv.Scatter( data, kdims='x', vdims=['state', 'stuff']).opts(tools=[hover], size=10).redim.range(x=(0,7))

[michael-imbeault]

That should work, didn't think of rebuilding the whole hover object. Still think that hover_cols should let you specify parameters, not just add to the default ones.

[philippjfr]

Still think that hover_cols should let you specify parameters, not just add to the default ones.

That is a good point, it is certainly confusing. We do want to expose a more convenient way to override the tooltips, I think for backward compatibility we'll likely stick with hover_cols adding columns and add a new tooltips keyword to specify subsets of the dimensions (but also add additional columns). In the long term we can then consider deprecating hover_cols.

[anitagraser]

This would be a great feature. Quite often, I'd like to hide the coordinates.

[maximlt]

I think for backward compatibility we'll likely stick with hover_cols adding columns and add a new tooltips keyword to specify subsets of the dimensions (but also add additional columns)

To be honest I think in 99% of cases there's no need for the coordinates to be in the tooltips. Coordinates are map metadata, they should rather be presented with a graticule or with a stream that displays the pointer location.

[jbednar]

I think the ratio is more like 50/50, personally; sometimes I want to know that for the precise coordinates listed, the precise value of other columns was as shown. Other times (e.g. for chorpleths) the coordinates are irrelevant. So it's definitely useful to be able to turn them off, but my vote is for them to be displayed by default.

[maximlt]

sometimes I want to know that for the precise coordinates listed, the precise value of other columns was as shown

I'm not sure I understand correctly your statement. Does it mean that you expect from another source than the map that at coordinates (X, Y) the point should have a value of Z, and so in this case the fact that the coords are by default shown in the tooltip helps you? Do you have a more concrete example?

One issue with the default coordinates being part of the tooltip is that when you hover over an area with a high density of points you get lots of tooltips that are cluttered with the points coordinates: The hover tool being activated by default, and the coords being in the tooltip by default, this is the first impression users get.

Grid-based plots don't suffer from this issue:

Here's an overview of when the coordinates appear by default in the tooltips for the geo-supported plots:

Type	Coords in tooltips
points	yes
paths	no
polygons	no
image	yes
quadmesh	yes
contour	no
contourf	no

I'd have to look more into the code but I tend to think that:

• at least for points maps (i.e. geo) the tooltip should not contain the coordinate by defaults
• hover_cols if set by the user should override the default ones set by hvPlot

[jbednar]

When coordinates are most useful in hover is for either the grid case that you've shown, or for the scatter case where there are additional value dimensions so that it is not just showing lat,lon or x,y values but showing that for the object at location x,y the values a,b,c are ... . I agree that showing a ton of overlapping xy coordinates on hover as above is useless, but even in that case showing only x,y is useful for isolated points, so that people can write them down or inspect the locations directly by pointing at the object rather than having to extrapolate down and left to the axes to see where that datapoint is.

Rather than turning off point hover info by default, I'd maybe think that reducing the default number of points shown in the hover would avoid the negative user experience without removing the legitimately useful purposes of hovering.

[maximlt]

I'd maybe think that reducing the default number of points shown in the hover would avoid the negative user experience without removing the legitimately useful purposes of hovering.

I assume this is a feature request for Bokeh.

even in that case showing only x,y is useful for isolated points, so that people can write them down or inspect the locations directly by pointing at the object rather than having to extrapolate down and left to the axes to see where that datapoint is.

If a data set has isolated points that means that it's not a small data set, or not too small, and in that case looking for (x, y) coordinates in a table after writing down the coordinates somewhere is a painful task (lat/lon coords are okayish to be parsed by the human eye, projected coordinates like the ones I was used too are usually not as they're in the orders of millions of meters). If I were to do that, I'd instead add to the hover_cols one or more column(s) that help me identify the isolated points.

[philippjfr]

I assume this is a feature request for Bokeh.

Bryan has long wanted to add hit test filters to make this possible but I think that was just moved to the 3.1 milestone.

[jbednar]

I don't think isolated datapoints are specific to any particular dataset or even to that dataset's distribution, because for any data they will appear at some zoom levels and not others. In any case the question here is whether to have a different and special treatment of the x,y or lat,lon columns when hovering, and my argument is that they are useful enough and in enough cases to vote against treating them specially. I also vote for limiting the number of hover items shown simultaneously, but yes, that depends on Bokeh.

[maximlt]

I was looking for the Bokeh issue on hit testing but couldn't find it, or a relevant one :/ Anyway waiting for Bokeh to fix this is probably not our best option here, and that would actually not solve the original issue which asks how to remove the x,y coordinates.

In the end the issue is indeed that users can't remove the default displayed information on hover, which according to HoloViews includes all the element Dimensions. I'd say this affects mostly users creating points and scatter plots because of the Bokeh issue that causes a lot of noise. But it also affects users that just don't want that information to be displayed.

I'm thinking, should there be (plot?) options at the HoloViews level to disable displaying the kdims and vdims data on hover? What do you think @jlstevens ?

Otherwise the suggestion by @philippjfr seems fine too:

I think for backward compatibility we'll likely stick with hover_cols adding columns and add a new tooltips keyword to specify subsets of the dimensions (but also add additional columns). In the long term we can then consider deprecating hover_cols.

[jlstevens]

We have discussed the idea of having a plot option to determine the hover behavior many times but had trouble deciding on a sensible syntax. What do you imagine it might look like? Maybe a fresh suggestion can help us finally make a decision!

[maximlt]

Found the issue you were mentioning: https://github.com/holoviz/holoviews/issues/1816

[maximlt]

• [ ] Documenting how to remove the coordinates, in particular for geo plots, sounds like a good idea until this is sorted out