You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Motivation:
Display of allelic expression, especially at SNVs. Bialleleic is typical, but multi-allelic possible and should be handled. Unless I've missed something this is not quite possible in IGV.js currently. One can get close by superimposing and juxtaposing feature and wiggle tracks.
General approach:
Because this displays continuous data at discrete (and relatively sparse) locations, it is essentially a hybrid of wiggle and BED. My implementation expects data delivered in BED files with the minor misuse of the BED format that IGV already supports: semi-colon delimited GTF-style attributes in the 4th column. Two attributes, sizes and labels, are expected, e.g. "sizes=17,17;labels=AT." The sizes correspond to the labels and are assumed to reflect intended display order bottom-to-top. Labels are optional. The sum of the sizes should correspond to the continuous (or integral) value, e.g. total expression depth, that might be displayed by a normal wiggle track, and the image above actually demonstrates this with a stackedBarGraphTrack superimposed on corresponding wiggle using mergedTrack.
Bars can be arbitrarily wide. The image above only shows single-basepair-width bars since allelic expression at SNVs is the motivating use case.
My implementation involves very little change to existing code:
one conditional in textFeatureSource.js
two new lines to trackFactory.js
...and one new file, stackedBarGraphTrack.js, that borrows from a couple files, especially wigTrack.js.
In the long term, borrowed code should probably be factored out, but current approach minimizes impact on existing code.
I'll submit a pull request if this is of interest to the group.
Thanks,
roger kramer, bioinformatician
University of Eastern Finland
The text was updated successfully, but these errors were encountered:
Hi, sorry for the long delay in response. I'm hesitant to take on maintenance of a new track with a specialized file format (effectively) without a community of users and consensus around the format. I think normally this data would will be found in VCF files, as info fields for the genotypes (samples). I have been thinking of a mechanism to allow easy integration of user-contrib tracks, which could be installed easily and registered with igv.js in the startup config. This might be a good candidate for that.
A proposal for a new stacked bar graph track type
Motivation:
Display of allelic expression, especially at SNVs. Bialleleic is typical, but multi-allelic possible and should be handled. Unless I've missed something this is not quite possible in IGV.js currently. One can get close by superimposing and juxtaposing feature and wiggle tracks.
General approach:
Because this displays continuous data at discrete (and relatively sparse) locations, it is essentially a hybrid of wiggle and BED. My implementation expects data delivered in BED files with the minor misuse of the BED format that IGV already supports: semi-colon delimited GTF-style attributes in the 4th column. Two attributes, sizes and labels, are expected, e.g. "sizes=17,17;labels=AT." The sizes correspond to the labels and are assumed to reflect intended display order bottom-to-top. Labels are optional. The sum of the sizes should correspond to the continuous (or integral) value, e.g. total expression depth, that might be displayed by a normal wiggle track, and the image above actually demonstrates this with a stackedBarGraphTrack superimposed on corresponding wiggle using mergedTrack.
Bars can be arbitrarily wide. The image above only shows single-basepair-width bars since allelic expression at SNVs is the motivating use case.
My implementation involves very little change to existing code:
...and one new file, stackedBarGraphTrack.js, that borrows from a couple files, especially wigTrack.js.
In the long term, borrowed code should probably be factored out, but current approach minimizes impact on existing code.
I'll submit a pull request if this is of interest to the group.
Thanks,
roger kramer, bioinformatician
University of Eastern Finland
The text was updated successfully, but these errors were encountered: