[Genome] problem loading a BED-formatted WIG file

[Hiram Clawson]

Ah yes, I forgot about the variableStep overlap.

In that case, you get the data value graphed which was last loaded by
the system.  I don't think it is guaranteed which data point gets drawn.

To be strict and accurate, you will have to do something to combine your
data values at the same location into a single data value at that location.
The wiggle graphing system can not combine your data values.

--Hiram

Gordon Robertson wrote:
> Hiram,
> 
> Thanks for your quick reply.
> 
> My use case is: I have an experimental or computational result set, in which
> all bases in a region have been assigned a constant value, but regions may
> partially overlap another region, all bases of which were assigned a
> different value. I want the browser to draw the highest value for a
> particular base, considering all regions that overlap at that base. Region
> width is not necessarily constant. (I guess I'd prefer to be able to control
> the transparency of the rendering for this track, as well as the RGB colour,
> but that's a secondary point.)
> 
> The browser currently lets me overlap WIG regions when I use variableStep
> format, but not when I use BED format (below):
> 
> [this is refused]
> track name="WIG BED" description="Test WIG as BED" type="wiggle_0"
> color=0,0,0 autoScale=off viewLimits=0.0:15.0 maxHeightPixels=40
> chr1 100000000 100000020 10.0
> chr1 100000010 100000030 8.0
> chr1 100000040 100000060 4.0
> chr1 100000070 100000090 2.0
> 
> [this is accepted]
> track name="WIG vS" description="Test WIG as variableStep" type="wiggle_0"
> color=0,0,0 autoScale=off viewLimits=0.0:15.0 maxHeightPixels=40
> variableStep chrom=chr1 span=20
> 100000000 10.0
> 100000010 8.0
> 100000040 4.0
> 100000070 2.0
> 
> For the data I've been given, which were processed from an Affy expression
> assay, I have both some overlapped regions _and_ a variable region width.
> So, variableStep is not appropriate.
> 
> Would you be open to relaxing the overlap restriction for BED-formatted
> files in a future version of the browser?
> 
> G 
> 
> 
> On 3/19/07 10:27 AM, "Hiram Clawson" <hiram at soe.ucsc.edu> wrote:
> 
>> Good Morning Gordon:
>>
>> I think you have figured this out.  The reason why is because bed items are
>> simply locations and
>> they can overlap in any manner.  WIG items are definite values at locations,
>> and thus you can
>> have only one value at one location.  The wiggle graph can only display one
>> value at one location.
>> If you were to give a single location more than one value, which one would you
>> expect to be
>> graphed ?  That's the difficulty, and hence the error so you can have the
>> opportunity to decide
>> which value you would like to see in that location.
>>
>> --Hiram
>>
>> Gordon Robertson wrote:
>>> Hello
>>>
>>> I have a ~300k-row data file that loads without problems into hg18 if it is
>>> formatted as a BED-track. I'd like to display it as a WIG track as well, and
>>> when I try to load it as a BED-formatted WIG track, the genome browser
>>> refuses to process the file, apparently because some 'end' coords overlap
>>> subsequent 'start' coords:
>>>     "Error File 'h6.wig' - chrom positions not in numerical order at line 86.
>>> previous: 869786 > 869479 <-current"
>>> ...
>>> chr1 869409 869437 7.02055
>>> chr1 869479 869787 6.35444  <<<
>>> chr1 869479 869794 9.46824  <<<
>>> chr1 869838 869989 7.57466
>>> ...
>>>  Do I understand the browser rules for BED and WIG files correctly -- that
>>> BED-formatted BED-track features can overlap, but BED-formatted WIG-track
>>> features cannot overlap? Because the width of the features varies, the
>>> 'variableStep' format is inappropriate.
>>>
>>> Thanks for your help -
>>>
>>> ---
>>> Gordon Robertson
>>> Gene Regulation Informatics
>>> Canada's Michael Smith Genome Sciences Centre
>>> Vancouver BC Canada
>>> www.bcgsc.ca
>>> grobertson at bcgsc.ca
>