Direction of package

[cvigilv]

Just wanted to open this thread to discuss which will be the direction of the package. Been working on implementing some new recipes, but at the same time have been testing some ideas on regards of how this package could be implemented.

I think this can have 2 main directions:

1. Provide all the basic recipes to work plotting tree structures
2. Something like ggtree, where on can build tree visualizations

I really thinks the aim should be the first, but playing around with the package on my own work it seems that the second options is closer to day-to-day use, since (at least in my case) one generally wants to add metadata to the tree's.

Let me know what you think, since I think we can improve the documentation to provide some guidelines on how to make things work a la ggtree using the functionality provided here.

[cvigilv]

Just to add to the above, I found this tutorial on ggtree that opened this discussion on my brain. Adding it to add some context: https://4va.github.io/biodatasci/r-ggtree.html

[cvigilv]

Related to this: I was thinking on maybe splitting all base plotting functionality into its own function, something like having:

• treeplot
• treelabels
• treescatter
• treepie
• treearea
• treecollapse
• treeheatmap
• treebar

And more...

What do you think?

[BenjaminDoran]

Thanks for your patience.

I'll start with a response here, to give the overall gist, then try to answer your more specific questions. I'll hopefully have some time in the next couple days to look more closely at your pull request.

To give some context, I made this package because I was sick of porting data over to R to use ggtree. My original overall goal would be to have a plotting package that covers the majority of ggtree’s functionality. That said, this is a parttime project of mine, so there is a lot prioritization and triage that is needed. Also, Julia is not R where I would say the majority of data plotting has coalesced around ggplot. In Julia, because there was no generic tree plotting package each phylogenetic package was implementing their own recipes. See Phylo.jl, NewickTree.jl, and PhyloTools.jl (same basic recipe as NewickTree.jl, and where I started building from for my recipe). The other purpose of this package was to be more generic than ggtree. My research, is partially related phylogenetics, but more fundamentally related to analysis of hierarchical structures. So, I wanted a visualization package that could handle any type of hierarchical datatype I might need in the future.

So I agree the first step is to build basic recipes that plot different layers of visualization. Having different recipes to handle these different layers as you suggested is a good idea.

To scope things out a bit. The way I was organizing the package was that the core layout algorithms that calculate coordinates, positions, and are generic to any potential plotting backend should go directly into the BasicTreePlots.jl package. Backend specific functions recipes etc. would go in package extensions for each backend. Functions needed to implement the interface functions for each tree structure backend can go into their own extensions, with the necessary interface being kept as minimal as possible.

Regarding the specific recipes needed and what they should be called.

For this package I would stick with recipe names that follow Makie conventions where they exist, and ggplot naming where no Makie convention exists. There is a package called TidierPlots.jl That would be great to interact with eventually. They have a way to make "geom_templates" which take makie recipes and turn them into ggplot like syntax for julia. Eventually when interfacing with that package it may be worth duplicating some functions so that ggtree syntax is more closely aligned with, but for now we need recipes for plotting trees and tree metadata. And as makie is the only current backend, we should stick with those naming conventions. Hence I would prefer treescatter to treenode. But treelabels does make more sense than treetext unless we are distinguishing between having a backing or not. So we can discuss case by case.

• treeplot: probably shouldn't be expanded much more. It contains the ability to plot the tree structure and optionally label the tips. It is good to have a single recipe that can do both. So I wouldn't remove that capability, but we can switch the default visibility to off once treelabels is fully implemented.

• treelabels fine name. Either this recipe should have the option to plot just the tip label or the internal node labels, or should be split into a recipe for treetiplabels and treenodelabels. "labels" is fine so long as any addition of adding a background behind the text is added as an option to this function. Note distinction between text and label in ggplot

• treescatter good idea to separate from treeplot Should also have option to toggle internal nodes vs tip visibility. One way would to have explicit toggles the other is to require explicit NaNs in the data provided to color or size options. The explicit toggles are more user friendly, and would be preferred if possible.

• treepie good name, would be cool to have

• treearea Your example in the PR looks good. I am only going to merge recipes that work for both Axis and PolarAxis into the main branch. But if it comes to it, it can be moved to another PR while the kinks are worked out if it ends up blocking the other recipes.

• treecollapse The way I would think about this is almost as replacement for treeplot To make this plot manually, I would first copy the tree, and prune away the collapsed node, then use treeplot to plot the remaining structure. and add a cladelabel or similar to designate the pruned node. There are definitely more efficient methods, but the point is I would think of it as a complex plot, and make sure I have the component parts first before taking this on.

• treeheatmap I've wanted this. There are some annoyances in appropriately aligning the axes since the leaves start plotting at 0 rather than 1. It's also going to need some arguments for tweeking how much horizontal space it takes. I would focus this on actually plotting in the same figure location as the tree structure, because I don't think there is a way to create figure location that surrounds another for the circular layouts. It's going to need some way to query the current plotting dimensions to know where to to be placed, i.e. what is the largest x coordinate currently plotted or what is the current x auto limit.

• treebar also very useful. Similar challenges to treeheatmap.

Other features (low priority)

• It would be good to eventually have an unrooted layout. Likely openangle is the easiest, but may need some way to reroot the tree to get better visual results.
• Including some support for Plots.jl

Other thoughts

• For writing code, I focused on clarity and extensibility, then performance. But with the idea that this package should scale to trees with thousands of leaves, The reason I did the segments code as a single line split by NaNs was for performance. The plots start slowing down significantly when trying to plot so many separate line layers.

[cvigilv]

Perfect! Completely agree with what you mention. I'll focus on the basic plots first, since I think this provide the sufficient functionality for more custom things (already been using the package for my work).