variableStep vs fixedStep for range formats
1
0
Entering edit mode
5.6 years ago
m98 ▴ 420

I am reading the specifications of many range formats: BED, bigBED, bedGraph, Wig and BigWig. I am having a hard time summarizing which of these can store data that is either variableStep or fixedStep.

For each format, there is an important parameter/characteristic to understand:

  • Size of the windows
  • Space between the windows

With this in mind, range formats can be:

  • fixedStep: This is when the data has values for :
    • For every base OR
    • For windows that are:
      • fixed-sized
      • regularly spaced

OR

  • variableStep: This is when the data has values for windows that are both:
    • fixed sized
    • variably spaced

With this in mind, is the following correct?

  • BED: accommodates arbitrarily sized ranges

    See following link: http://genomewiki.ucsc.edu/index.php/Wiggle_BED_to_variableStep_format_conversion

    “The span specification in wiggle formats has a very specific use and is not to be used to specify arbitrarily sized data items (that's what the BED format is for)”

    Additionally, the bigBED specification link says: “The bigBed format stores annotation items that can either be simple, or a linked collection of exons, much as bed files do.” - suggesting that BED files can do variableStep at least.

    => Sounds like BED is the most simple format that can story range that be arbitrarily sized.

  • BigBED: idem as BED since it's made from a BED file

  • bedGraph: it accommodates windows that are both variably sized and variablly spaced (sort variableStep but not fixed-sized windows)

  • WIG: it accommodates either fixedStep or variableStep

  • bigWig: idem as WIG OR idem as bedGraph, depending on how it was made

Sorry if the question is basic but with all these similar formats, I am finding it hard to be sure and I find the distinction between size and space between windows confusing. And I feel it's important to understand the difference if I am to choose the right format.

ucsc formats bigwig bedgraph range • 1.8k views
ADD COMMENT
3
Entering edit mode
5.6 years ago
genecats.ucsc ▴ 580

Hi m93,

I think there is some confusion here that arose from that genomewiki page you linked. BED data (and bigBed) is displayed in the UCSC Genome Browser as "blocks" along the genome, while wiggle data (and bigWig) is displayed as a signal (with a genomic base on the x axis and some value on the y axis). The description pages for each of these formats may clear this up a bit:
bed: https://genome.ucsc.edu/FAQ/FAQformat.html#format1
bigBed: https://genome.ucsc.edu/goldenPath/help/bigBed.html
wig: https://genome.ucsc.edu/goldenPath/help/wiggle.html
bigWig: https://genome.ucsc.edu/goldenPath/help/bigWig.html

The bedGraph format is basically a 3 column bed file with a 4th column containing a score (instead of an item name), and thus is kind of a hybrid between bed and wiggle format. bedGraphs (and regular bed and wiggle) files are extremely inefficient to use as custom tracks on the UCSC Genome Browser because it requires us to store the whole entire file to disk, whereas with bigBed and bigWig we can just request the bit of data we need for the current view from your server, and don't need the whole file (and we cache some of this as well), and so things are much faster.

Which format you want to use to represent your data should depend entirely on what you want to see, a signal graph (bigWig), or blocks (bigBed).

It sounds like you already have bedGraph files, you can convert them to bigWigs via the bedGraphToBigWig utility and then load them onto the browser.

If you have further questions about UCSC data or tools feel free to send your question to one of the below mailing lists:

  • General questions: genome@soe.ucsc.edu
  • Questions involving private data: genome-www@soe.ucsc.edu
  • Questions involving mirror sites: genome-mirror@ose.ucsc.edu
ADD COMMENT
0
Entering edit mode

Thanks, that really helps!

ADD REPLY

Login before adding your answer.

Traffic: 3205 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6