Skip to content

Unrooted layout#43

Draft
cvigilv wants to merge 2 commits into
BenjaminDoran:mainfrom
cvigilv:feat-unrooted-layout
Draft

Unrooted layout#43
cvigilv wants to merge 2 commits into
BenjaminDoran:mainfrom
cvigilv:feat-unrooted-layout

Conversation

@cvigilv
Copy link
Copy Markdown
Contributor

@cvigilv cvigilv commented May 2, 2026

Related issues

Closes #41

This PR intends to implement the unrooted tree layouts and its interactions with the other
tree-related plotting functions. The following is a list of the main features that are being
implemented in this PR:

  • Unrooted tree layout
  • treeplot
  • treelabels
  • treehilight
  • treecladelabel
  • treescatter

Checklist

  • I am following the contributing guidelines
  • Tests are passing
  • Lint workflow is passing
  • Docs were updated and workflow is passing

@cvigilv
Copy link
Copy Markdown
Contributor Author

cvigilv commented May 2, 2026

Hi! Sorry for the delay on this, life got in the way and just got some time to implement the layout into the recipe.

Currently, I have implemented the equal_degree_layout function to generate the unrooted tree layout, which is the standard algorithm for this kind of layout. If you set layout to unrooted_cladogram or unrooted_dendrogram, we get the following result:

unrooted_example

That said, I have questions regarding the convention I am using here: I think this could be provided (i) as I currently have it implemented here, i.e. unrooted_*, or I could add a new branchstyle with is unrooted and that takes into consideration the layoutstyle parameter to define if this is a dendrogram or cladogram. This is the difference:

t = <your tree>
# Current style
treeplot(t, layoutstyle = :unrooted_cladogram)

# Alternative style
treeplot(t, layoustyle = :cladogram, branchstyle = :unrooted)

The think both are valid, that's why I'm asking to see what is your preference.

@cvigilv
Copy link
Copy Markdown
Contributor Author

cvigilv commented May 2, 2026

I have also started working on the treelabel function for this, some examples with the same trees as before (COVID sequences example from documentation):

unrooted_treelabels

@BenjaminDoran
Copy link
Copy Markdown
Owner

This looks pretty good. For now I think having these layouts under those names works well. And I would happy to merge after you add some documentation for these features.

It add my more extended thoughts on how the argument naming should go.

If the end goal is matching most of ggtree's capabilities, it would be good to have these layouts.

https://yulab-smu.top/treedata-book/chapter4.html#tree-layouts

image

It would require adding branchstyle in (:ellipse, :roundrect) and layoutstyle = :daylight

It also suggests a bit of how to separate the arguments to be more conceptually distinct. Ideally, the arguments should be independent and possible to mix and match for any other combination of arguments. It might make sense to have this API

  • treestyle = (:rooted, :unrooted, :daylight)
  • ignorebranchlength = false switch between dendrogram and cladogram styles
  • branchstyle the shape of the line connecting a child node to it's parent. e.g. the (:square, :straight) options currently, and additional options that could be added: (:ellipse, :roundrect)
  • layoutstyle as presets of these and other arguments (with perhaps shorter names)
    • :rooted_dendrogram = (treestyle = :rooted, ignorebranchlength=false)
    • :rooted_cladogram = (treestyle = :rooted, ignorebranchlength=true)
    • :unrooted_dendrogram = (treestyle = :unrooted, ignorebranchlength=false)
    • :unrooted_cladogram = (treestyle = :unrooted, ignorebranchlength=true)
    • :daylight_dendrogram = (treestyle = :unrooted, ignorebranchlength=false)
    • :daylight_cladogram = (treestyle = :unrooted, ignorebranchlength=true)

Adding layouts by name like :radial and :fan are difficult with Makie as they are currently handled by changing the axis to a polar layout. This allows a lot of the same code from the dendrogram layout code to be reused and simpler calculations (I think) when adding other annotations. But it does hide that option somewhat from the visible API of the treeplot function.

This API change will likely need to wait for a refactor (and would a breaking change). And I think only worth if we had these other layout options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unrooted layout

2 participants