Wikipedia talk:WikiProject Tree of Life/Cladogram requests

Phylogeny extended information
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? &mdash; soupvector (talk) 23:20, 17 September 2017 (UTC)
 * 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. IJReid  discuss 23:30, 17 September 2017 (UTC)
 * Without such sources, wouldn't it be OR? &mdash; soupvector (talk) 23:36, 17 September 2017 (UTC)
 * 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. IJReid  discuss 23:46, 17 September 2017 (UTC)

Or.... just add some parameters so that the information can be directly displayed in Template:Clade... Lythronaxargestes (talk &#124; contribs) 00:41, 18 September 2017 (UTC)
 * Ah Ok if that's what is being asked for I think I could add those (I'd just need a template editor permissions). IJReid  discuss 01:04, 18 September 2017 (UTC)

Tool for generating cladograms?
Are there any WMF tools to help us generating cladograms without manually typing everything in Wiki markup? HᴇʀᴘᴇᴛᴏGᴇɴᴇꜱɪꜱ (talk) 14:54, 15 November 2019 (UTC)
 * Not that I am aware of... Lythronaxargestes (talk &#124; contribs) 00:44, 16 November 2019 (UTC)
 * Several tools for using Newick format data are mentioned in the clade template documentation. The template Clade newick converter can be used to convert a Newick string into the clade template markup. You can also use Newick strings directly in the clade template by using the newick1 parameter in place of 1 (and so on for other indices). What data sources for cladograms did you have in mind?  Jts1882 &#124; talk 07:24, 16 November 2019 (UTC)
 * Thanks. List Converter looks most intuitive for me. HᴇʀᴘᴇᴛᴏGᴇɴᴇꜱɪꜱ (talk) 07:18, 1 December 2019 (UTC)

Using branch lengths to approximate time.
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. 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 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.

This is mainly a test cladogram to visualize the results. Any suggestions?  Jts1882 &#124; talk 08:40, 28 November 2019 (UTC)
 * 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)
 * 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)

Simple clade template with one child (leaf A): Nested template where leafA is replaced by a clade with two children (leaves 1 and 2)


 * 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 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 &#124; talk 17:16, 28 November 2019 (UTC)
 * 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)

Update
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. Any comments or suggestions?  Jts1882 &#124; talk 18:04, 24 December 2019 (UTC)
 * I've setted on lengthN (N is the index) as the parameter name and it takes a number with the unit, e.g. 2em or 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)
 * 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)


 * 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)


 * Ah, you've cracked it. In all cases the vertical lines are added by the label and sublabel cells, controlled by CSS . label1 never has a left border. If the first label is used to define the width with 50px then the width of the cell will be  . If the second (or higher) label is used with 50px then the width of the cell will be the width assigned by 50px plus the thickness of the border, i.e.   with the default border thicknes. I set the border 10 in the example to the left to illustrate the difference better.   Jts1882 &#124; talk 08:04, 25 December 2019 (UTC)
 * 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)


 * 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  property, which will clip long labels.   Jts1882 &#124; talk 07:44, 26 December 2019 (UTC)
 * 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 &#124; talk 08:03, 26 December 2019 (UTC)
 * 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)
 * 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  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.
 * Is the long em tree aligned now? I couldn't see the non-alignment so can't tell.   Jts1882 &#124; talk 08:40, 27 December 2019 (UTC)

Time calibrated cladogram (first attempt)
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.


 * 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 . IJReid { {T - C - D - R} } 17:32, 27 December 2019 (UTC)
 * 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 &#124; talk 13:00, 29 December 2019 (UTC)