Problem with tophat2 handling strandedness

[vang42]

We are using tophat2 (v2.0.10) to analyze RNA-Seq samples produced by a stranded protocol. We have analyzed the same samples with and without a GTF file in the tophat run.

with GTF
@PG     ID:TopHat       VN:2.0.10       CL:/com/extra/tophat/2.0.10/bin/tophat --keep-fasta-order --library-type fr-secondstrand --rg-id negNr2 --rg-sample negNr2 --rg-platform-unit Illumina --rg-center Moma --fusion-search -p 10 -o /scratch/1426995.in/negNr2 --GTF /home/vang/reference/gtf/hg19/gcV15noPseudo.cuffCompTss.gtf --transcriptome-index=/home/vang/reference/gtf/hg19/gcV15noPseudo.cuffCompTss /home/vang/reference/tophat_ref_from_illumina/Homo_sapiens/UCSC/hg19/Sequence/Bowtie2Index/genome negNr2_R1.truncated.fastq.gz negNr2_R2.truncated.fastq.gz,negNr2.singleton.truncated.fastq.gz

without GTF
@PG     ID:TopHat       VN:2.0.10       CL:/com/extra/tophat/2.0.10/bin/tophat --keep-fasta-order --library-type fr-secondstrand --rg-id negNr2 --rg-sample negNr2 --rg-platform-unit Illumina --rg-center Moma --fusion-search -p 10 -o /scratch/1431419.in/negNr2 /home/vang/reference/tophat_ref_from_illumina/Homo_sapiens/UCSC/hg19/Sequence/Bowtie2Index/genome negNr2_R1.truncated.fastq.gz negNr2_R2.truncated.fastq.gz,negNr2.singleton.truncated.fastq.gz

As you can see from the first of the attached slides, the 3'end of the SNHG16 transcript maps to the minus-strand using the GTF file, and maps to the plus-stand when not using a GTF file. By extracting all the first-reads in the region and manually mapping them, we are convinced that the plus strand is the most correct. Does the tophat mapper disregard the strand information when doing the initial mapping to the GTF regions of the genome? And are the information not used later when the two reads are combined as pairs? Is this a bug in tophat?

The following two slides show other examples with disagreement between the tophat with and without GTF found by random in the vicinity of the first region.