New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alignments2 - Mate/next location #907

keiranmraine opened this Issue Jul 14, 2017 · 6 comments


None yet
3 participants

keiranmraine commented Jul 14, 2017

The options to quick view or open in a new tab render the marker (orange line) 1bp to the left of the actual coordinate:

Link from here:
screen shot 2017-07-14 at 15 42 24

To here:
screen shot 2017-07-14 at 15 43 00

@rbuels rbuels modified the milestone: 1.12.4 Jan 25, 2018


This comment has been minimized.


rbuels commented Jan 25, 2018

Think you can investigate this one @rdhayes ?


This comment has been minimized.


rdhayes commented Jan 25, 2018

I see this in the sample data, sure. I have a full plate today, but can take a look tomorrow or early next week.


This comment has been minimized.


rdhayes commented Feb 8, 2018

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.


This comment has been minimized.


keiranmraine commented Feb 9, 2018

Sure, you can use this:

Corresponding ref in here:

@rbuels rbuels removed their assignment Feb 9, 2018


This comment has been minimized.


rdhayes commented Feb 13, 2018

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.



This comment has been minimized.


keiranmraine commented Feb 13, 2018

There's a far smaller dataset covering a small region on 21 here:


@wafflebot wafflebot bot added the in progress label Feb 13, 2018

@rbuels rbuels added this to the 1.12.5 milestone Feb 28, 2018

@rbuels rbuels closed this in #986 Feb 28, 2018

rbuels added a commit that referenced this issue Feb 28, 2018

Merge pull request #986 from GMOD/Alignments2_mateHighlightFix
Alignments2 mate highlight fix, fixes #907

@wafflebot wafflebot bot removed the in progress label Feb 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment