You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If someone wants to search for features that are upstream of a pair of data coordinates, but will tolerate a degree of overlap, there's no way to specify that currently. You can only specify upstream and overlap, which includes features that overlap only the stop coordinate.
You CAN sort-of specify that you want to only consider a feature's start coordinate by specifying the start and stop as the same column in the data, but that doesn't help when start/stop are not logically ordered and you need the strand to infer which one is the start, therefor options like '--search-overlap-start' and '--search-overlap-stop' could overcome that and allow start and stop to both be specified. You might even want to ensure that the other end does NOT overlap, like --search-overlap-start-only... whereas --search-overlap-start would not care if the stop also overlaps. Note, I'm not even sure if the code currently accounts for un-ordered start/stop columns.
By the same token, you might want to specify whether the start/stop of a feature should overlap or not.
Nor is a degree of overlap capable of being specified.
It might be a good idea to allow -r to use negative values as the amount of allowed overlap. Currently, a negative value means no limit to the search range, but I could change that to simply un-supplied/undefined. Note, I will have to handle the situation where the negative value results in a coordinate outside of the data coordinates (e.g. if -r -10 and start/stop = 5/10, then the location where it would start searching in the case of --search-upstream would be 15, i.e. 'downstream'). it might even be desirable to specify the degree of overlap allowed via percentage/ratio.
All this would also apply to other search types such as downstream, left, right, etc..
The text was updated successfully, but these errors were encountered:
If someone wants to search for features that are upstream of a pair of data coordinates, but will tolerate a degree of overlap, there's no way to specify that currently. You can only specify upstream and overlap, which includes features that overlap only the stop coordinate.
You CAN sort-of specify that you want to only consider a feature's start coordinate by specifying the start and stop as the same column in the data, but that doesn't help when start/stop are not logically ordered and you need the strand to infer which one is the start, therefor options like '--search-overlap-start' and '--search-overlap-stop' could overcome that and allow start and stop to both be specified. You might even want to ensure that the other end does NOT overlap, like --search-overlap-start-only... whereas --search-overlap-start would not care if the stop also overlaps. Note, I'm not even sure if the code currently accounts for un-ordered start/stop columns.
By the same token, you might want to specify whether the start/stop of a feature should overlap or not.
Nor is a degree of overlap capable of being specified.
It might be a good idea to allow -r to use negative values as the amount of allowed overlap. Currently, a negative value means no limit to the search range, but I could change that to simply un-supplied/undefined. Note, I will have to handle the situation where the negative value results in a coordinate outside of the data coordinates (e.g. if
-r -10
and start/stop = 5/10, then the location where it would start searching in the case of --search-upstream would be 15, i.e. 'downstream'). it might even be desirable to specify the degree of overlap allowed via percentage/ratio.All this would also apply to other search types such as downstream, left, right, etc..
The text was updated successfully, but these errors were encountered: