Oncoplot annotationDat Sorting Bug and Documentation Inconsistency

[DarioS]

The documentation has

... a column containing Tumor_Sample_Barcodes ...

but if I have such a column, it seems that the code wants a column named Tumor_Sample_Barcode instead.

Error in `[.data.frame`(annotationDat, , c("Tumor_Sample_Barcode", clinicalFeatures)) : 
  undefined columns selected

The code and documentation should be harmonised.

Another problem happens if there are ties in the annotation variable used for sorting of the samples. All of the ties are placed first and then the samples with unique values are plotted after the ties. For example,

The first six samples on the left side of the plot have patient ages 41, 41, 47, 47, 67, 67. The rest of the patients have ages which no other patient in the data set has. The first six columns should be interspersed with the other columns.

[DarioS]

To resolve this issue, "Tumor_Sample_Barcodes" should be changed to "Tumor_Sample_Barcode" in the documentation. "Tumor_Sample_Barcode" is the correct column heading, according to the official MAF specification.

Also, the annotation-based sample sorting bug can be eliminated by deleting the code

anno.spl.sort = anno.spl.sort[names(sort(unlist(lapply(anno.spl.sort, ncol)), decreasing = TRUE))]`

in the internal function sortByAnnotation. I don't know of any situation in which it is desirable (let alone a default which can't be changed by the user) to put all of the samples which share an annotation value together in the plot, like happens in the example above.

Can such small and easy changes be made soon?

[PoisonAlien]

Hi Dario,

Sorry for the delay. I completely over-looked this one :|

For your second error on sample sorting, its due your annotations being numeric. Sorting script converts all the annotations to characters before ordering it. Regarding the line you mentioned, its used to order annotations according to their sizes. In your case 41, 47, 67 are the largest groups and hence they are at the beginning. One way to force the way you want it to be is to use the argument annotationOrder which would keep the user defined order of levels.

But I do see your point. I have included two arguments to tackle this. isNumeric to specify if the annotation column used for sorting is numeric or character. groupAnnotationBySize to disable further sorting annotations by the size of levels.

Please install from GitHub and let me know if you still have the issue.

Also, code for oncoplots have been migrated from ComplexHeatmap library to pure base graphics for code stability and faster printing. Please let me know if you have any suggestions for improvement.

[DarioS]

Thanks for the fast update but I am not sure why the difference between a numeric or a categorical variable exists. It seems to have something to do with NA values, but NA could also appear for a numeric vector. Also, I think the sorting following the original levels of a factor would often be good. For example, categorical variables which ideally would not be sorted by group size:

Lung Cancer: Smoking History variable with categories Never Smoked, Former Smoker, Current Smoker has a natural ordering to it.
Skin Cancer: Sun Exposure variable with categories Low, Medium, High has a natural ordering to it.

An example without any obvious ordering is "Which drink do you prefer? Pepsi, Fanta, or Lemonade" so sorting in terms of group size might be desirable for a variable such as Drink Preference.

[PoisonAlien]

Hi,

For the first question, sort or order function behaves differently for numeric and character values.

> x = sample(x = 7:12, size = 10, replace = TRUE)
x
 [1] 12 11  7 10  7 10 10 10  8  8
> sort(as.character(x), na.last = TRUE)
 [1] "10" "10" "10" "10" "11" "12" "7"  "7"  "8"  "8" 
> sort(as.numeric(x), na.last = TRUE)
 [1]  7  7  8  8 10 10 10 10 11 12

And the thing with the levels, is that all the data are read with stringsAsFactors = FALSE, so by default there wont be any levels. In which case sorting results in alphanumeric order. In your example case,

> x = c("Never Smoked", "Former Smoker", "Current Smoker")
> x
[1] "Never Smoked"   "Former Smoker"  "Current Smoker"
> sort(x)
[1] "Current Smoker" "Former Smoker"  "Never Smoked"  

To mitigate this issue, by default is to sort based on group sizes. You can over-ride this by manually specifying the order with the argument annotationOrder.

[DarioS]

Ah, yes; lexical ordering. I understand why the changes are suited to both numeric and character vectors.

The changes result in a strange-looking colour scale for the clinical variable, though.

The plot showing the problem is generated using the code

laml.maf <- system.file("extdata", "tcga_laml.maf.gz", package = "maftools")
laml <- read.maf(maf = laml.maf)
annotateTable <- data.frame(Tumor_Sample_Barcode = levels(laml@data[["Tumor_Sample_Barcode"]]),
                            Age = rpois(193, 50))
oncoplot(maf = laml, top = 3, annotationDat = annotateTable, clinicalFeatures = "Age",
         groupAnnotationBySize = FALSE, isNumeric = TRUE)

The colour gradient used before is desirable.

[PoisonAlien]

Ah! I see.. I will fix it. Thanks for the suggestion.

[DarioS]

Can the problem be fixed within the next two weeks? The next release of Bioconductor will be in two weeks' time and it would be great to have numeric clinical variables working properly in the release version of the package and installable by BiocManager. It seems that this use-case is in high demand #263

[PoisonAlien]

HI Dario,

Yes, that is the plan. I would like to address as many issues as possible before the release. Sorry things have been busy so couldnt spend much time on this. I will fix it soon..
Thank you.

[PoisonAlien]

Hi Dario,

I have pushed a fix for numeric annotations. I have removed isNumeric argument and it now auto-detects such numeric annotations and plots them with a gradient colors. This was bit tricky, and I think I have patched it. Please let me know if you find any bugs.

Thanks.

[DarioS]

Thanks for making it possible. What do you think about cBioPortal's oncoplot's representation of numeric values as a bar chart? The human visual system has trouble distinguishing subtle differences of colour gradients whereas the height of a bar is easier to interpret.

Would it be less tricky to implement and maintain in the future than the gradient representation by splitting it into four ordered categories like you've done?

[PoisonAlien]

Hmm.. This looks much better, and I do agree gradient coloring has certain disadvantages.
I will try to make this - I guess it should not be that complicated.