Join GitHub today
Alignments2 - Mate/next location #907
Is there more test data than the sample_data Volvox "BAM - paired end test pattern at 28kb)" track? I am tempted to think the fix is not so simple, but I see highlighting of the correct base if I simply add 1 to the integer read from the BAM in Store/SeqFeature/BAM/LazyFeature.js function _next_pos(), as currently returned by line 262.
Your BAM is too big to download efficiently. Could you provide just chromosome 1 or even smaller slice?
Part of this is the highlight of the start of mate pairs as a sharp line at the start coordinate, rather than a highlight of the full start coordinate column. Using the Volvox "proper_f_r" example, the location string returned by feature.get('next_segment_position') is the correct interbase ctgA:28135, but this is ultimately translated by Util.parseLocString() and assembleLocString to "ctgA:28135..28134". I think what we want is "ctgA:28136..28135" to highlight start of the correct base. The format looks odd, but is what gives us the current "interbase" highlight.
Question 1: is Util.parseLocString with a single coordinate performing as we expect here? It is parsing "ctgA:28135" to an object with start=28134 and end=28134 (Util.js line 314). I am wondering why one is subtracted (should be start=28135, end=28135?)
Question 2: For Alignments2.js next/previous mate highlighting, I have a working fix that is a rewrite of feature.get('next_segment_position') to return strings of the correct line highlight format (like "ctgA:28136..28135").
What are other use cases for feature.get('next_segment_position') from BAM files? I don't wish to break anything expecting the single interbase start coordinate, though I don't see this attribute used elsewhere in the main codebase. Another option would be to add another getter function called 'next_segment_position_highlight' and update Alignments2 to use that instead in this instance.