Whether I use pairs of words like "reference" and "annotation" to describe which file will get annotation as opposed to supply annotation is up in the air. This script is really a coordinate-based "join" of data. The point is that "data" and "feature" is a pointless separation that just serves to confuse. You're basically joining 2 tab-delimited files of features. One file ends up being annotated with records of the other file. Currently, I only support "left joins" where the "first" file is what gets annotated with matches from the second file.
If I merge the concepts of the current data file and feature file into only feature files, I can do a couple of things:
- Create --left-join and --right-join options that treat the first or second/last file as the (current) "data" file. (I could even create a --union-join or a --unmatched-outfile that includes (current) "features" that had no hit.)
- Allow 1 set of column positions applied to both files or 2 sets applied to the first or second/last file.
- Change the terminology of --feat-orientation (or "--hit-orientation" or "--match-orientation") to --result-orientation which would complement the --search-* flags.
- Change the various --search-* flags into a single array option like the current --feat-orientation with values like
This feature/overhaul would be an analogous style of interface as the current implementation of columnStitch.pl.
Whether I use pairs of words like "reference" and "annotation" to describe which file will get annotation as opposed to supply annotation is up in the air. This script is really a coordinate-based "join" of data. The point is that "data" and "feature" is a pointless separation that just serves to confuse. You're basically joining 2 tab-delimited files of features. One file ends up being annotated with records of the other file. Currently, I only support "left joins" where the "first" file is what gets annotated with matches from the second file.
If I merge the concepts of the current data file and feature file into only feature files, I can do a couple of things:
This feature/overhaul would be an analogous style of interface as the current implementation of columnStitch.pl.