intersectBed -wo returning intersecting insertions with base-pair overlap of 0

[GoogleCodeExporter]

What steps will reproduce the problem?

[XXX]$ cat example.a.gff
chr1    INDEL   insertion_site  11085004        11085004        1       .      
.ID=1399;
[XXX]$ cat example.b.gff
chr1    INDEL   insertion_site  11085005        11085005        1       .      
.ID=1175;
[XXX]$ ~/Installed/BEDTools-Version-2.12.0/bin/intersectBed -wo -a 
example.a.gff -b example.b.gff
chr1    INDEL   insertion_site  11085004        11085004        1       .      
.ID=1399;        chr1    INDEL   insertion_site  11085005        11085005       
1.       .       ID=1175;        0

What is the expected output? What do you see instead?

Do not expect these two 'zero length' insertion_site features to intersect (and 
thus not be output with the -wo flag). 

Prior to 2.12, the 'number of base pairs overlap of each feature' incorrectly 
reported as 1, here it correctly reports 0 but if that is true, then it should 
not be said to 'intersect' nor be printed out.

What version of the product are you using? On what operating system?

[XX]$ ~/Installed/BEDTools-Version-2.12.0/bin/intersectBed
Program: intersectBed (v2.12.0)
Author:  Aaron Quinlan (aaronquinlan@gmail.com)
Summary: Report overlaps between two feature files.

[XX]$ uname -a
Linux genetics-compute.njrc.org 2.6.18-238.1.1.el5 #1 SMP Tue Jan 4 13:32:19 
EST 2011 x86_64 x86_64 x86_64 GNU/Linux

Please provide any additional information below.
As an additional example that maybe suffers from the 'zero length' problem, if 
the example.a.gff was a deletion over coordinates (chr1  7715352  7715352, i.e. 
length 1 deletion or zero length specification by coordinates) and the 
example.b.gff was a deletion over coordinates chr1 7715341  7715612, i.e length 
271) then the overlap returned (by version 2.12 and 2.11) is 2. I would expect 
that this deletion would return an overlap of 1. Perhaps this has something to 
do with the fact that I'm using a gff file instead of bed? Maybe I'm 
mis-interpreting what it means to have 'zero length' features (which appears to 
differ for insertion_site or deletion, though for both chrstart==chrend).

Thanks.

Original issue reported on code.google.com by sonia.le...@gmail.com on 15 Aug 2011 at 8:59

[GoogleCodeExporter]

Original comment by aaronqui...@gmail.com on 31 Aug 2011 at 1:29

• Changed state: Accepted

[GoogleCodeExporter]

Found a similar Error in BEDTools-Version-2.16.2
Intersecting two bed files:
a.bed
    chr11   30  30
b.bed
    chr11   31  31

I get the following output:
intersectBed -a /tmp/a.bed -b /tmp/b.bed -wao
    chr11   30  30  chr11   31  31  0

But when adapting the second bed-file to this:

b.bed
    chr11   31  32  0

There is no longer an overlap:
intersectBed -a /tmp/a.bed -b /tmp/b.bed -wao
    chr11   30  30  .   -1  -1  0

Operating system:
Linux x 2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 
x86_64 x86_64 GNU/Linux

Original comment by Ash.ava...@gmail.com on 18 May 2012 at 11:42

[GoogleCodeExporter]

Similar error also. When the features are 1 base pare long, I have overlap as 
you guys have explained.

Original comment by lpant...@ascidea.com on 18 Dec 2012 at 5:51