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

overlaps considers that Strand.FORWARD cannot overlap with Strand.INDEPENDENT #1650

Closed
antonkulaga opened this Issue Jul 30, 2017 · 4 comments

Comments

Projects
None yet
4 participants
@antonkulaga
Contributor

antonkulaga commented Jul 30, 2017

Right now what I see that many reference genomes are imported with INDEPENDENT strand while in features we have FORWARD/REVERSE and functions like .extract fail to find features because FORWARD strand cannot overlap INDEPENDENT (overlaps functions uses sameStrand function that checks strand equality) and extract functions uses .overlaps inside of it. Maybe it makes sense to allow overlapping take place if the region that is being overlapped has INDEPENDENT strand?

@fnothaft

This comment has been minimized.

Member

fnothaft commented Jul 31, 2017

Hi @antonkulaga ! We have a covers function that is similar to overlaps, but which ignores strand; we should also have a function named disorient for converting a stranded ReferenceRegion to one with INDEPENDENT strand.

The rationale for using overlaps and not covers in the ReferenceFile code is that if the strand is specified, the behavior of extract is less clear. E.g., if you call extract with a ReferenceRegion that is on the negative strand, do you get back the reference sequence covering the region, or its reverse complement?

@antonkulaga

This comment has been minimized.

Contributor

antonkulaga commented Jul 31, 2017

@fnothaft I know about covers function as I use it actively in my projects. My question if we should change default extract behaviour to tolerate Strand.INDEPENDENT My practical experience with latest human and mouse genome releases tell me that we should (otherwise extract/extractRegions becomes useless in many cases as fragments there are always independent while features have direction)

@devin-petersohn

This comment has been minimized.

Member

devin-petersohn commented Jul 31, 2017

Hi @antonkulaga, check out #1513 & #1555. I think it resolves the issue of defaulting to Strand.INDEPENDENT. The data still must have stranded information, and you would still need to use covers for Strand.INDEPENDENT and Strand.FORWARD/Strand.REVERSE.

@fnothaft

This comment has been minimized.

Member

fnothaft commented Mar 7, 2018

I think this was resolved by #1637.

@fnothaft fnothaft closed this Mar 7, 2018

@heuermh heuermh added this to the 0.24.0 milestone Mar 7, 2018

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