Export support values into extended newick as attributes.

[xflouris]

Export the node support values generated from Bayesian runs into a tree into the extended newick format:

[label]#[type]tag[:branch_length]

[stamatak]

not clear to me why you need the extended one, in the specific case
standard newick node labels should do and work with more tree-viewers,

alexis

On 22.10.2015 11:42, Tomas Flouri wrote:

Export the node support values generated from Bayesian runs into a tree
into the extended newick
http://dmi.uib.es/%7Egcardona/BioInfo/enewick.html format:

|[label]#[type]tag[:branch_length]|

—
Reply to this email directly or view it on GitHub
#33.

Alexandros (Alexis) Stamatakis

Research Group Leader, Heidelberg Institute for Theoretical Studies
Full Professor, Dept. of Informatics, Karlsruhe Institute of Technology
Adjunct Professor, Dept. of Ecology and Evolutionary Biology, University
of Arizona at Tucson

www.exelixis-lab.org

[xflouris]

I don't know if there is a standard syntax that tree-viewers are able to parse, and how standardized the eNewick notation is. I've noticed that BEAST uses the following syntax to add attributes to nodes:

label[&attribute1={content},attribute2={content},...,attributeN={content}]:branch_length

For example, to set the attributes height and is_tip to the nodes of a simple rooted tree (A:0.1,B:0.2):0.0;

the syntax BEAST uses is:

(A[&height={0},is_tip={True}]:0.1,B[&height={0},is_tip={True}])[&height={1},is_tip={False}]:0.0;

This seems to be compatible at least with FigTree. Is this the syntax you have in mind?

[stamatak]

The standard syntax for node labels using your example is:

(A:0.1,B:0.2)Node_Label:0.0;

see:

http://evolution.genetics.washington.edu/phylip/newick_doc.html

that's what almost every viewer can digest, we may also just chose to
output two tree files in different formats for greater compatibility

On 22.10.2015 17:34, Tomas Flouri wrote:

I don't know if there is a standard syntax that tree-viewers are able to
parse, and how standardized the eNewick notation is. I've noticed that
BEAST http://beast.bio.ed.ac.uk/ uses the following syntax to add
attributes to nodes:

|label[&attribute1={content},attribute2={content},...,attributeN={content}]:branch_length|

For example, to set the attributes |height| and |is_tip| to the nodes of
a simple rooted tree |(A:0.1,B:0.2):0.0;|

the syntax BEAST uses is:

|(A[&height={0},is_tip={True}]:0.1,B[&height={0},is_tip={True}])[&height={1},is_tip={False}]:0.0;|

This seems to be compatible at least with FigTree
http://beast.bio.ed.ac.uk/. Is this the syntax you have in mind?

—
Reply to this email directly or view it on GitHub
#33 (comment).

Alexandros (Alexis) Stamatakis

Research Group Leader, Heidelberg Institute for Theoretical Studies
Full Professor, Dept. of Informatics, Karlsruhe Institute of Technology
Adjunct Professor, Dept. of Ecology and Evolutionary Biology, University
of Arizona at Tucson

www.exelixis-lab.org

[xflouris]

Okay, I get what you mean. I'm aware of this format; we're already using it for labeling inner nodes in fastdate.

This however allows us to only place a single label to a node (either inner or tip). To place multiple attributes, labels are not sufficient, but could be solved as you say with multiple trees.

For now what you suggest will suffice since we only plan to add for each node the frequency it appears as the root of a coalescent process. But later on, with more attributes (confidence intervals for instance) we'll need a better (more generic) solution.

[xflouris]

It seems most editors do not support neither the extended format nor the BEAST format. I reverted back to printing support values only as inner node labels (as Alexis suggested).