This page is within the scope of WikiProject Tree of Life, a collaborative effort to improve the coverage of taxonomy and the phylogenetictree of life on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Tree of LifeWikipedia:WikiProject Tree of LifeTemplate:WikiProject Tree of Lifetaxonomic articles
I think this page is a great idea - but it's also a great opportunity to document the evidence for, and process for, each cladogram. How are OTUs selected, where were data obtained, what tools were used with what settings, and how is the phylogeny constructed? If this were included with the cladogram, then uses of that cladogram could point back to this page, yes? — soupvector (talk) 23:20, 17 September 2017 (UTC)[reply]
Yes I think that could work very well. With the proper information (original papers etc), we could probably figure out how to best include the information on taxon selection, character choices and phylogenetic programs. This would be a great thing to have, if of course we can manage to access all the information we would need to add this. IJReiddiscuss23:30, 17 September 2017 (UTC)[reply]
Yes, which is why we'd need to be able to get the information from the papers themselves (or their supplementary information). See for example: Hadrosaurid, I've added a new phylogeny there and taken the information about it from the paper. IJReiddiscuss23:46, 17 September 2017 (UTC)[reply]
@IJReid: Following on from the brief discussion on the cladogram request page, this section is to discuss how best to add parameter support for changing branch lengths to approximate time. Using the div element to change the width of the label cell the way you did was quite effective, but it should be easier with appropriate parameters to change the cell size.
Ideally a |lengthN= just taking a value (e.g. |lengthN=3.8em would be a counterpart for the |stateN=, |colorN= and |thicknessN= parameters. However, because of the way the cladogram is constructed as a HTML table, it wouldn't definitively set the length of the child node branch as that is determined by the widest label of all the sister nodes.
That is why I lean towards just using a general CSS styling element for the label cell, implemented with the poorly named {{[para|branch}} parameter (what would be a better name?) using CSS styling.
As an aid to thinking this through, I've annotated the cladogram below to show where branch lengths are set (value in ems and red line). An x (and blue line) indicates a default. Incidentally, the default width of the label cell is 0.7em, but the cell has left and right padding of 0.2em.
The diagram is great for displaying the result, but I did notice when creating the cladogram initially that branch lengths end up not lining up, eg the 8.2 of D. fenestrata is longer than the 3.1+1.1+0.9+1.5=6.6 of the equivalent D. antarctica branch. I'm just not entirely sure how to explain the effect the padding has on the overall tree as you move branches. IJReid{{T - C - D - R}}15:43, 28 November 2019 (UTC)[reply]
I've made minor adjustments to fully align everything now based on the principle that for every uneven node an additional 0.4em is added. This means that between D. antarctica etc and D. poha, the length of the D. poha only branch is the 3.1+1.1 = 4.2+0.4+0.5 because there are two more nodes in the other branch, giving it a final length of 5.0em, which seems to line up well. This same aspect applies between D. poha and D. incurvata, there is one more branch in D. poha so instead of Incurvata being 5.0+0.9 its 5.0+0.9+0.4 = 6.3em. IJReid{{T - C - D - R}}16:13, 28 November 2019 (UTC)[reply]
Simple clade template with one child (leaf A):
labelA
Leaf A
sublabelA
Nested template where leafA is replaced by a clade with two children (leaves 1 and 2)
labelA
label1
leaf1
sublabel1
label2
leaf2
sublabel2
sublabelA
It's due to the way the cladogram is constructed as a series of nested tables. The illustration to the right shows a single clade template with a single (leaf A) and then below when leaf A is another clade template, this one with two children (leaves 1 and 2). The padding around each label adds to the width and the more nested templates on a branch the more extra padding. In the example its the same, but if you add more nested templates to one branch it inttroduces the shift.
An alternative to the calculation is to adjust the padding using, for example |branch1=width:3.1em;padding:0em;. If you look very closely the alignment is still not perfect. The more deeply nested clades are still shifted very slightly rightwards. This is because each cell containing a nested {{clade}} template has a border of 1px.
I'm thinking that the most logical name for the parameter is |labelstyle=, i.e. it contains CSS styling for the table cell (td tag) containing the label. Jts1882 | talk17:16, 28 November 2019 (UTC)[reply]
I wonder what the effect of no padding at all would have, and whether it would then be easier to compensate by adding 1pixel length to each table. Alternatively it could just be simpler to break up the long individual branches into enough to compensate (eg instead of one being 8.0 have two being 3.8 ...) There should be a few possibilities. IJReid{{T - C - D - R}}19:36, 1 December 2019 (UTC)[reply]
@IJReid: I've made a few changes in my sandbox version of the module to try and make setting lengths easier and with less trial and error.
I've setted on |lengthN= (N is the index) as the parameter name and it takes a number with the unit, e.g. |length1=2em or |length2=15px. This sets the width of the label and suppresses the default padding to make the addition easier.
I found that using pixels is easiest as this allows for an adjustment for number of nodes along a lineage.
In the example the total length of the lineages determined by the lengths of the labels is 160px (add 10px when the label=y to allow for the default). However, you need an adjustment for lineages with less nodes (an extra 2px for each node less). This is because each node in the cladogram adds a nested HTML table and these have a border width of 1px (this sets the lines of the cladogram). So lineages with more nodes have addition pixels due to the border. It's not user friendly but can be made to work.
To use it you have to use {{cladeN}}, which uses my sandbox version of the module, and shouldn't be used in the main namespace. I've being doing a number of changes and will upgrade near the end of the holiday period.
I've decided to take a screenshot and run this through GIMP to exactly line everything up to the pixel. This shows the +2 rule is not necessarily, and I've made adjustments to the tree above (in small text) to match this. Now the issue is determining why this is the case. IJReid{{T - C - D - R}}20:14, 24 December 2019 (UTC)[reply]
Looking more, I think I've found a pattern. The problem arises because the length of the upper and lower segments are unevenm, there is a 1px discrepancy every segment because the vertical black lines add onto the more nested clades. And also the 10 at D. poha was throwing off upper levels because it was over 10px wide. IJReid{{T - C - D - R}}20:47, 24 December 2019 (UTC)[reply]
x
39
x
54+1
D. willana
30
54
D. potatorum
x
D. amatheiae
44
x
60+16+1
D. fenestrata
46
x
49+10+1
D. incurvata
16
x
46+2+1
D. poha
y
x
35
D. antarctica (NZ south)
x
D. antarctica (Subantarctic and Chilean)
11
23
y
D. chathamensis
y
D. antarctica (NZ north)
x
50+1+25+1
Text
10
x
50+1
Text
25
x
Text
50
Text
x
50+1+25+1
Text
10
x
50+1
Text
x
Text
25
x
Text
50
Text
10
50+25
Text
x
25
50
Text
x
Text
x
50
Text
x
Text
There are really two significant things, which I've displayed with some reduced trees. Theres the nesting of the 1pxs, and the inequalities of the horizontal lines. Every additional subnode adds a vertical black line, which needs to be accounted for higher up by adding 1px every time. And the lower lines aren't equal in length with the upper for some reason, the vertical lines are included in the upper horizontal but not the lower horizontal, or its an issue of it being different every time. IJReid{{T - C - D - R}}21:07, 24 December 2019 (UTC)[reply]
50
Text
x=60‑10
Text
x=60+10
Text
50
Text
Ah, you've cracked it. In all cases the vertical lines are added by the label and sublabel cells, controlled by CSS border-left:1px solid. |label1= never has a left border. If the first label is used to define the width with |length1=50px then the width of the cell will be 50px. If the second (or higher) label is used with |length2=50px then the width of the cell will be the width assigned by |length1=50px plus the thickness of the border, i.e. 51px with the default border thicknes. I set the border |thickness=10 in the example to the left to illustrate the difference better. Jts1882 | talk08:04, 25 December 2019 (UTC)[reply]
This may also simplify the entire process of length adjusting, it we limit it to the upper labels that get the lengths ... Double checking in GIMP, everything is perfect to the last pixel, so I think we might have found the solution we need for this entire process, simply labelling the upper bars only! IJReid{{T - C - D - R}}16:28, 25 December 2019 (UTC)[reply]
10
50+25
Text
x
25
50
Text
x
50
Text
x
Text
2.5em
12.5em+6.25em
Text
x
6.25em
12.5em
Text
x
12.5em
Text
x
Text
I think you are right. It will work if |length= sets the first label cell width. Given that the width of all the label elements is determined by the widest, there is no need for specific |length1=, |length1=, etc., and indexed parameters misleadingly suggest they are individually adjustable. A single |length= parameter for each clade template is what is needed and this should set the width of the first label cell. Then there is no need to worry about pixel adjustments, which also means ems can be used as units.
One further possibility is to prevent long labels stretching a label cell when |length= is set. I think this can be done with the CSS overflow:hidden; property, which will clip long labels. Jts1882 | talk07:44, 26 December 2019 (UTC)[reply]
Parameter added. I've left the indexed parameters for now as removing them would make the above discussion incomprehensible. I've add a long label to test the clipping idea. Jts1882 | talk08:03, 26 December 2019 (UTC)[reply]
For some unknown reason this change has seemed to unalign some aspects of the trees ... It works with the 3rd of the basic trees above that I adjusted, but the uppermost line of the long em tree is shorter than the lower ones. IJReid{{T - C - D - R}}01:43, 27 December 2019 (UTC)[reply]
Sorry, I was trying to do too many things at once, adding |length= while keeping the indexed versions (for examples above) and also adding max-width and clipping. I've simplified things and just added the |length= (unindexed) and the CSS max-width: property. The other trees look like they are restored for me, except that now some labels overflow the cell.Edit. It's too tricky keeping the indexed lengths working for the test examples, so now only the first label cell has the length set (which is what we want, but makes the above discussion confusing). |length= and |length1= are now aliases and |length2= is ignored.
The following is an attempt at a time calibrated cladogram using a cladogram from the wolf article. The time scale is just a crude first attempt to test alignments. 100px is 1mya.
Canine phylogeny with ages of divergence (from wolf article)
The em length tree has resolved itself now, and the canine trees are all equal pixel lengths. Which means ... we have gotten this thing to work. Quite an accomplishment. I don't really see anything else being necessary at this point to add or change, I think it is now applicable. Perhaps though we should begin a discussion on a more expansive page, WT:TOL maybe, before these features are put into the traditional {{clade}}. IJReid{{T - C - D - R}}17:32, 27 December 2019 (UTC)[reply]
I've updated the module so the length feature should work with {{clade}}. It shouldn't break anything that was working so I don't think it needs wider discussion. I've also added clipping on the labels so if |length= is set the overflow is clipped. Something should be added to the documentation. Jts1882 | talk13:00, 29 December 2019 (UTC)[reply]
.png){kind=small}
.png){kind=small}
.jpg){kind=small}
.png){kind=small}
.png){kind=small}
.png){kind=small}
.png){kind=small}
.png){kind=small}
.png){kind=small}