Display more than 3 levels if not too many tips

[bredelings]

It would be nice to display more levels than 3 in cases like this:

https://tree.opentreeoflife.org/opentree/argus/opentree8.0@mrcaott246ott5272/Phaethontidae--Passeriformes

A simple approach might be to have the depth be equal to max(M, largest depth with < N) children.

M=3, N=0 gives current behavior. It seems like M=3, N=200 would be strictly an improvement on current behavior.

[bredelings]

Concern #1: it could be confusing why different depths are displayed for different nodes. (Thanks to Jim)

[bredelings]

Suggestion #2: "I think we should just fix the number of tips (maybe user controllable) and show trees with that many tips. with sampling and/or ellipses, as needed." (Thanks to JAR)

[josephwb]

I'm waiting for a concrete agreed-upon plan before I move forward with implementing this.

[kcranston]

Also need to think about how this will affect the behaviour and documentation of the public API call for subtree. Current default behaviour:

• default depth (height_limit) is 3 for arguson and no limit for newick
• user can set height_limit when calling method
• the upper limit on returned tips is 25000 (applies to both arguson and newick)

Before deciding on changes to treemachine, I wonder about testing the effect on the visualization on dev by modifiying the opentree code to:

• increase height_limit when calling the API for arguson
• some client-side modifications to limit displayed depth if number_displayed_nodes > X (where X is some large number)

[jimallman]

Also need to think about how this will affect the behaviour and documentation of the public API call for subtree.

Yes, that's an interesting distinction. If the reason for the new behavior is to increase legibility and manage crowding in the arguson view, maybe we just want the web app to fine-tune its requests. (Do we know of other arguson use cases with different priorities?)

When clicking a node in the current arguson view this should be pretty straightforward, since we now get num_tips for each node in the current arguson view. Hm, I suppose the initial arguson view would need to be use kind of flag to trigger smarter behavior from tree_of_life/subtree.

[josephwb]

Yes, the point about subtree is a good one. Perhaps we should separate these again? It is already a bit clunky to support both with one function.