BACKGROUND: I recently ran featureProximity.pl wanting to only feature output 1 column which I would later merge with other such outputs to indicate presence/absence. In other words, I had 1 "data" file with a subset of important pairs of coordinates. I also had 13 files which had some subset of those features (possibly with coords that were slightly smaller, but overlapping) plus a number of other uninteresting features. I wanted to run featureProximity 13 times - once for each sample - to look for overlapping features and output just the chromosome column that I would later convert into presence/absence data.
I had run into a bug however - I was checking for redundant features using only the output columns (because I assumed that would uniquely identify a feature. I fixed the bug by using the chromosome ID, start, and stop columns, regardless of output columns.
I realized later though (even though my immediate problem was solved) that there might be cases where the user might want to do something like I did, but with multiple features that have say, different names, that aren't included in the output. One solution would be to always use every column. But a user may actually want to skip certain redundancies... So the complete solution might be to use all columns unless the user supplies the columns on which to filter duplicates.
BACKGROUND: I recently ran featureProximity.pl wanting to only feature output 1 column which I would later merge with other such outputs to indicate presence/absence. In other words, I had 1 "data" file with a subset of important pairs of coordinates. I also had 13 files which had some subset of those features (possibly with coords that were slightly smaller, but overlapping) plus a number of other uninteresting features. I wanted to run featureProximity 13 times - once for each sample - to look for overlapping features and output just the chromosome column that I would later convert into presence/absence data.
I had run into a bug however - I was checking for redundant features using only the output columns (because I assumed that would uniquely identify a feature. I fixed the bug by using the chromosome ID, start, and stop columns, regardless of output columns.
I realized later though (even though my immediate problem was solved) that there might be cases where the user might want to do something like I did, but with multiple features that have say, different names, that aren't included in the output. One solution would be to always use every column. But a user may actually want to skip certain redundancies... So the complete solution might be to use all columns unless the user supplies the columns on which to filter duplicates.