I find that the splice junction track displays as blank in IGV 2.1 (EA) (1666)
Reverting to IGV 2.0 restores this functionality.
Can fix?
Thanks!
Malcolm Cook
Computational Biology - Stowers Institute for Medical Research
Perhaps we should display it, but in a strand-neutral way, if the XS
tag is missing.
Jim
Hmmm.
There is no XS tag in my data.
Indeed, XS is not even a defined tag according to the sam spec (dated September 7, 2011 http://samtools.sourceforge.net/SAM1.pdf)
In fact, tags whose name begin with X are " are reserved for local use and will not be formally defined in any future version of this specification."
So far as I know, XS was coined by gmap (http://research-pub.gene.com/gmap/src/README) which I am not currently using.
Were you not previously assigning strand with 0x10 in the bitwise FLAG?
I don't see anything different about spliced reads in how you should assign their strand....
I am producing spliced alignments of RNASeq fastq by using bowtie to align to a genome database which has been augmented with "splice junction entries" (SJE). I then project the coordinates of alignments to any SJE's onto genomic coordinates for displaying in IGV, and downstream analysis. Up till now, everything worked perfectly....
Can you please explain the motivation for the change a little more.... perhaps I am missing something....
By the way, I have also had some experiments with GMAP/GSNAP over 6 months ago and found IGV's interpretation of its output at that time to be perfectly fine for my purposes.
Cheers,
~Malcolm
For paired-end sequencing, at least, it is important to distinguish the read strand from the strand of the "transcript fragment" that is being sequenced. The XS tag is output by Tophat to specify the strand of the transcript fragment, it requires that the user describe their library. Without some knowledge of the library it is not possible to determine this from the read strand, in fact some protocols do not preserve the transcript strand.
Given that the 2.0 behavior is to render the junctions by "read-strand" if the XS strand is missing, I've restored this in the 2.1 EA. Just be aware this might not be the transcript strand. We'll add a menu later to let the user specify the "strand rules" for their library, e.g. transcript strand == strand of first-of-pair, etc.
Jim
Much appreciated and understood.
I am analyzing RNASeq, not paired and, and not stranded chemistry/library.
So, I didn’t really care about the strand being correct.
I do care about the display of the new Junctions coverage track, which was not being displayed, and now is again, thank you very much.
On this topic, it appears to me that the Depth reported on-hover over IGV’s junction coverage track only tabulates reads which are loaded, as goverened by the “View > Preferences > Alignments > Maximum Read Depth” (and possibly other options?).
This contrasts with Coverage track, which tabulates ALL reads (I’m pretty sure), unaffected by any of the Preferences.
I think you might highlight this difference in behavior of the “coverage” and the “splice junction track” in your documentation, and reinforce it in your interface, perhaps using “Total count” in the coverage track (as you do), and using “Loaded count” in the “splice junction track” (instead of “Depth”).
I understand the complication that leads to this implementation decision, and am aware and appreciative of IGV’s ability to load a junctions.bed file as produced by tophat (indeed, as produced by my own ‘custom’ approach utilizing “splice junction entries” as I earlier described).
I only have continued thanks for your consideration and responsiveness.....
~Malcolm
From: igv-...@googlegroups.com [mailto:igv-...@googlegroups.com] On Behalf Of Jim Robinson
Sent: Monday, January 23, 2012 7:35 PM
To: igv-...@googlegroups.com
Cc: 'Jim Robinson'
Subject: Re: [igv-help] splice junction track is blank in IGV early access
Hi Malcolm,