make deme size non linear to number of visible tips

[rneher]

Description of proposed changes

Make demes on make better visible even if heavily filtered down

This changes the denominator in the radius scalefactor of demes. it used to be the number of total tips. This is now replaced by the square root of the product total and visible tips. This choice retains some scaling of deme size with number of tips, but avoid demes essentially disappearing when only a few tips are visible (there is probably a more robust way to getting the number of visible tips....

before:

after:

Thank you for contributing to Nextstrain!

[trvrb]

My guess is that it's least confusing to have a consistent scaling for deme size even if deme circles get pretty small. In the PR I just tried zooming in repeatedly to different clades. I found it odd that the circles weren't getting smaller on the map.

To prevent the fairly pathological case of the overly tiny demes, I'd instead have a minimum deme radius.

[rneher]

but circles are getting smaller.... just not as much as before. I also think that the deme size are not at all intuitive to grasp numbers (people are bad at estimating areas). Since we convey a lot of information via pie charts, having them so tiny that one can't see things is not useful. Minimum deme size is even worse in my opinion, since this will result in linear scaling of area until it suddenly stops and is completely independent of the number of tips.

Also, multiple tiny demes would have the same size even if they had the same number of tips when there was a minimal deme size. I think relative size matters much more than absolute in this context.

[rneher]

I think currently the map view is actually pretty useless once you have filtered things down or zoomed in.

[trvrb]

I see where you're coming from and agree with the minimum size comment. I think I'd prefer some behavior that's between the current live behavior and the PR. Zooming in or filtering on the tree gives fewer dots in the tree panel, ie less ink devoted to tips. This is expected. I'd expect a reduction in ink devoted to demes to mirror this. Just so the visualization has internal consistency. I'm okay with adjusting the scaling of this reduction however.

[rneher]

I initially had this such that it would simply scale with the total number of visible tips. This would have kept the "amount of ink" the same but felt that this was not desirable for the same reasons you point out. I then changed it such that reducing the number of tips by a factor of 4 reduces the amount of ink by a factor of 2. I felt this is a good compromise that worked well in particular when zooming into the map.

compare these two for example:

https://nextstrain.org/ncov/global?c=clade_membership&f_division=Washington&p=grid&r=location

https://auspice-adjust-deme-siz-zb6h8x.herokuapp.com/ncov/global?c=clade_membership&f_division=Washington&p=grid&r=location

[emmahodcroft]

I was initially fairly sceptical about this because, like Trevor, I also think it's important the amount of ink changes (decreases) when you zoom or filter. But I've also been annoyed/disappointed when I zoom in & filter & basically am left with dots you can hardly see. After looking at the examples, I think the middle-route is a pretty good compromise, but clearly other ratios could be experimented with.

[rneher]

@jameshadfield do you have any thoughts on this? That is should deem size adjust when one filters down and zooms in?:

[jameshadfield]

Right now we have a system whereby the circle representing a deme doesn't change size as one zooms the map, and always represents the number of in-view tips associated with that deme. I think this is nicer in theory than in reality.

I think this PR improves things under the presumption that people weren't making an absolute link between the amount of ink in a circle and the number of tips in view. This feels safe to me. It still creates some oddities -- for example when you change filtering from aus-only to all samples, then the amount of ink decreases, as the "visible" tips are calculated off the tree, not what's in the map view.

Filtered to australia only:

No filtering:

Separate to this PR, I think a key would really improve things, similar to one we used in a recent paper. You could then dynamically scale sizes based not only on total number of visible tips but also map zoom level.

[rneher]

Fully agree with your comments! For me one confusing bit has always been that demes don't increase in size as map zooms. But given how filters and map zoom interact, there likely is not perfect solution. I hope this PR strikes a balance between size scaling and visibility. There might be a more elegant way to access the number of visible tips though... so feel free to modify before you merge.

[jameshadfield]

I'm going to merge this and release -- I do think the path forward is having a legend indicating the tip count which different circle sizes represent and changing the sizes dynamically as you zoom the map / filter the data. The devil is, of course, in the details.