<p>I need tools I am writing to output data in terms of score for each base in the genome. The format needs to be indexed for fast random access. </p>

<p>The obvious choices are bigWig and tabix-index bedgraph (indexed bedGraph seems quicker for computation, bigWig better for visualization), but the problem is that I need the data to be stranded - i.e. I need to record which strand the data belongs to (and perhaps even have a score on the positive and negative strands). </p>

<p>So my choices are:</p>

<ul>
<li>Invent a new format</li>
<li>Bodge one of the existing formats (this is almost as bad as inventing a new format, if not worse). For example: bedGraph, except with two score columns - one for + and one for -, or have a bedGraph with with a strand column. This doesn't seem ideal because other downstream tools won't be able to process it. </li>
<li>Have seperate files for + and - strand scores. This is unweidly and not great if you sometimes don't care about strand, or want to visualise on a single track.</li>
<li>Use a magic format I've not heard of but that someone is going to point out in the answers...</li>
</ul>

<p>None of these are ideal. As they either make tool output files incompatible with other tools, or don't encode all the information I want to. Is there a an established format I can use for this?</p>

CC BY-SA 3.0
2018-04-02T14:39:51.500Z
Since you lose many benefits of creating a new format: I found that having three files — forward, reverse, unstranded/merged — works best.
Konrad Rudolph
CC BY-SA 3.0
2018-04-02T16:29:25.217Z
So far I've been working with three files: a full bed6 with a line per non-zero coverage base. This I index with tabix and use internally. Two bigWigs - forward and reverse, which I use for external programs. The difference in performance is quite impressive. On one benchmark what makes about 18000 queries, querying BAM and processing to stranded depth takes 45 seconds, querying bigWig takes 90 seconds and querying the indexed bed takes 25 seconds.
Ian Sudbery
<file-formats><bigwig>
Which data format for stranded coverage data
# Which data format for stranded coverage data

(Asked by: username_0 on 2018-03-30)

I need tools I am writing to output data in terms of score for each base in the genome. The format needs to be indexed for fast random access.

The obvious choices are bigWig and tabix-index bedgraph (indexed bedGraph seems quicker for computation, bigWig better for visualization), but the problem is that I need the data to be stranded - i.e. I need to record which strand the data belongs to (and perhaps even have a score on the positive and negative strands).

So my choices are:

* Invent a new format
* Bodge one of the existing formats (this is almost as bad as inventing a new format, if not worse). For example: bedGraph, except with two score columns - one for + and one for -, or have a bedGraph with with a strand column. This doesn't seem ideal because other downstream tools won't be able to process it.
* Have seperate files for + and - strand scores. This is unweidly and not great if you sometimes don't care about strand, or want to visualise on a single track.
* Use a magic format I've not heard of but that someone is going to point out in the answers...

None of these are ideal. As they either make tool output files incompatible with other tools, or don't encode all the information I want to. Is there a an established format I can use for this?

**Tags:** file-formats, bigwig
> **Comments:**
> **username_1**: Since you lose many benefits of creating a new format: I found that having three files — forward, reverse, unstranded/merged — works best.  
> **username_0**: So far I've been working with three files: a full bed6 with a line per non-zero coverage base. This I index with tabix and use internally. Two bigWigs - forward and reverse, which I use for external programs. The difference in performance is quite impressive. On one benchmark what makes about 18000 queries, querying BAM and processing to stranded depth takes 45 seconds, querying bigWig takes 90 seconds and querying the indexed bed takes 25 seconds.  

---

## 0 answers

