splice junction track is blank in IGV early access

307 views
Skip to first unread message

Cook, Malcolm

unread,
Jan 23, 2012, 1:07:24 PM1/23/12
to igv-...@googlegroups.com
Hi,

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

Jim Robinson

unread,
Jan 23, 2012, 1:16:59 PM1/23/12
to igv-...@googlegroups.com, Cook, Malcolm
Malcolm, are you sure it was displaying correctly, with respect to
strand, before? The track should use the "XS" tag for strand, without
it the strand of the originating fragment can't be know for sure.
Before there was a bug, or possibly incorrect assumption, made and it
would display even without the XS strand. Since obviously you found
this useful I wonder if you could verify whether the strand information
looked correct.

Perhaps we should display it, but in a strand-neutral way, if the XS
tag is missing.

Jim

Cook, Malcolm

unread,
Jan 23, 2012, 6:09:28 PM1/23/12
to Jim Robinson, igv-...@googlegroups.com
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

Message has been deleted

Jim Robinson

unread,
Jan 23, 2012, 8:34:52 PM1/23/12
to igv-...@googlegroups.com, Jim Robinson
Hi 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

Cook, Malcolm

unread,
Jan 24, 2012, 11:53:30 AM1/24/12
to igv-...@googlegroups.com

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,

Reply all
Reply to author
Forward
0 new messages