Replies: 1 comment
-
Hey, sounds like you have made a lot of the same design choices in RAD that I use in the alignment-writer format. My format is currently structured like this:
This achieves many of the goals you described in RAD (multithreaded parsing, memory allocation in advance and sorting the alignments so they're in the same order as the reads in particular) but there is no extra information stored apart from what's in the header. The way I've stored the file additionally allows set operations on alignment files from paired-end reads to be streamed which helps immensely with large alignments. Themisto and others (I imagine) have the ability to produce some other read-specific information that might be useful to store, though. I'll ping Jarno about this discussion so he can give his input. Some clarifications regarding my comments
Pseudoalignments fortunately contain relatively little information compared to sam files so they're much easier to compact 😄 |
Beta Was this translation helpful? Give feedback.
-
Pursuant to the discussion that was started in #13 — this is a space that we can use to discuss ideas relevant to an optimized and standardized output format for mapping information. @tmaklin brings up some very good points and desiderata in this comment.
Several of these issues, I think, have clear solutions.
Beta Was this translation helpful? Give feedback.
All reactions