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

[antonkulaga]

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]

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]

@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]

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]

I think this was resolved by #1637.