Does HTseq need a gtf file that is sorted according to chr number and coordinates?

Question

[Anna]

Hi I have a simple question, will HTseq counting be affected if my gtf file is in the right format, but not sorted according to coordinates?

Thanks a lot Anna

[WouterDeCoster]

'not aligned' means the read is... not aligned.

[Anna]

yes but i thought bowtie would not write the not aligned reads into the sam/bam file so I was surprised by that...

[GenoMax]

If HTSeq is working as it should then likely no. There must be a reason you are asking this question. Is the counting not working as expected?

You may want to give featureCounts a try instead. It is much faster than HTSeq-count.

[Anna]

okay great thanks for the info, it was sort of working but because I made my gtf it was't sorted properly so just wanted to make sure that this is not a problem :)

[WouterDeCoster]

Please use ADD COMMENT or ADD REPLY to answer to previous reactions, as such this thread remains logically structured and easy to follow. I have now moved your post but as you can see it's not optimal. Adding an answer should only be used for providing a solution to the question asked.

Answer 1

[grant.hovhannisyan]

No, htseq-count should work properly, as it did in my case. And FYI, this is from STAR manual :

"With --quantMode GeneCounts option STAR will count number reads per gene while mapping. A read is counted if it overlaps (1nt or more) one and only one gene. Both ends of the paired- end read are checked for overlaps. The counts coincide with those produced by htseq-count with default parameters."

So if you want reads count table equivalent to the one produced by htseq-count in union mode but substantially faster, try that option in STAR. It produces exactly the same counts.