Open adamnovak opened 4 months ago
I looked at these more and the reads are indeed overlapping by exactly 1 SVG pixel unit. The X + width of the final rectangle in that blue read on the right is 1 more than the X of the first rectangle of that red read it bumps into.
We probably need to look at the functions that compute read start and end X coordinates: https://github.com/vgteam/sequenceTubeMap/blob/56d3c4b5615dcc89466a4f48e796fee552bdb1b8/src/util/tubemap.js#L2656-L2680
But I have no idea where we're getting the 1 pixel of overlap.
To follow the view link, you should be able to start your local tube map and then click it. The node I am looking at is near the middle of the rendered visualization.
Actually, the problem might be here: https://github.com/vgteam/sequenceTubeMap/blob/56d3c4b5615dcc89466a4f48e796fee552bdb1b8/src/util/tubemap.js#L3787-L3788
We generate the rectangle list entries with exactly coinciding start and end coordinates, and then we add a +1 when we go to draw the SVG elements for them for some reason.
In this view, reads crossing an expanded gap between nodes can get bumped down a lane because they overlap other reads in X by a few pixels, not an entire base. See this image:
Read lines should always start and end exactly on base boundaries. There shouldn't be apparently random slop of a few pixels here or there.