Hi Brooke, Hmmm, I'm a bit surprised by this response... all the behavior I had observed was consistent with a problem in setting the span correctly, so I didn't think there was anything wrong with changing the step. I also tried the second example as a custom track, and agree that it doesn't work... But, if I explicitly set the span to 1, then it does work.
I just finished a genome-wide analysis that produces fixedStep wig files (with steps that change, but the span always specified as 1), and then converts to bigwig with wigToBigWig. It seemed to work fine and I have these displayed on the browser and I haven't noticed any problems. Is it the opinion of your engineers that I should reformat my fixedStep files to use a constant step size, and re-generate the bigwigs, or can they confirm that wigToBigWig works with varying steps? Thanks, Melissa On Mon, Apr 23, 2012 at 6:47 PM, Brooke Rhead <[email protected]> wrote: > Hi Melissa, > > We agree that the first example does look like a bug in the > wigToBigWig/bigWigToWig programs, and I have filed a bug report. > > The logic of the second example makes sense to me, too, but I have confirmed > with our engineers that it won't make sense to the software, which isn't set > up to use different step sizes in a single fixedStep wiggle track. I also > tried loading example 2 as a custom track, and, though no errors are > reported, only the first part of the data is displayed. > > We plan to: (1) improve our documentation, and specify on our wiggle page > that a single step size must be used throughout a fixedStep file, and (2) > improve our wiggle validators so that multiple step sizes trigger a more > informative error sooner. > > Sorry for the inconvenience this has caused, and thank you for helping us > improve the tools! Let us know if you have any other questions or comments. > > -- > Brooke Rhead > UCSC Genome Bioinformatics Group > > > > On 4/20/12 7:29 AM, Melissa Jane Hubisz wrote: >> >> Hi Pauline, >> Thanks for the response. What about the first example I sent: >> [mt269@swiftgen results]$ cat test.wig >> fixedStep chrom=chr1 start=1 step=2 >> 0.1 >> [mt269@swiftgen results]$ wigToBigWig test.wig hg19_chrom_sizes.txt >> test.bw >> [mt269@swiftgen results]$ bigWigToWig test.bw /dev/stdout >> fixedStep chrom=chr1 start=1 step=2 span=2 >> 0.1 >> >> Here, the span in the original file should be 1, since it isn't >> specified, but after running wigToBigWig and bigWigToWig, the span is >> 2. This seems like incorrect behavior to me. >> >> The second example I sent was over-simplified, but I think it makes >> sense. Why would the step sizes have to be equal? Say I have wig >> values at positions 1,3,5,7, 8, and 12 each with a span of 1. There >> is no data at positions 2,4,6,9,10,11. I have code which turns this >> into a fixedStep wig file as follows: >> fixedStep chrom=1 start=1 step=2 >> pos1Val >> pos3Val >> pos5Val >> pos7Val >> fixedStep chrom=1 start=8 step=4 >> pos8Val >> pos12Val >> >> If I do this, wigToBigWig throws an error and complains that there is >> more than one value for position 8. It seems to be doing this because >> it assumes the span is 2, rather than the default of 1, which doesn't >> make sense to me. >> Thanks, >> Melissa >> >> >> >> On Thu, Apr 19, 2012 at 6:40 PM, Pauline Fujita<[email protected]> >> wrote: >>> >>> Hello Melissa, >>> >>> Looking at your input: >>> >>> >>> fixedStep chrom=chr1 start=1 step=2 >>> >>> 0.1 >>> >>> fixedStep chrom=chr1 start=2 step=1 >>> >>> 0.2 >>> >>> >>> the step sizes must be equal for the input to make sense. If I set step=1 >>> on >>> both lines this runs and returns the same output but with span=1 as >>> advertised. >>> >>> Hopefully this information was helpful and answers your question. If you >>> have further questions or require clarification feel free to contact the >>> mailing list at [email protected]. >>> >>> Regards, >>> >>> Pauline Fujita >>> UCSC Genome Bioinformatics Group >>> http://genome.ucsc.edu >>> >>> >>> >>> On 4/17/12 10:53 AM, Melissa Jane Hubisz wrote: >>> >>> Hi UCSC, >>> I ran into a behavior with wigToBigWig that seems like a bug. If a >>> span is not specified in fixedStep wig format, it assumes that the >>> span is the same as the step, rather than the documented default of 1: >>> >>> [mt269@swiftgen results]$ cat test.wig >>> fixedStep chrom=chr1 start=1 step=2 >>> 0.1 >>> [mt269@swiftgen results]$ wigToBigWig test.wig hg19_chrom_sizes.txt >>> test.bw >>> [mt269@swiftgen results]$ bigWigToWig test.bw /dev/stdout >>> fixedStep chrom=chr1 start=1 step=2 span=2 >>> 0.1 >>> >>> This is the situation that initially caused problems for me: >>> [mt269@swiftgen results]$ cat test2.wig >>> fixedStep chrom=chr1 start=1 step=2 >>> 0.1 >>> fixedStep chrom=chr1 start=2 step=1 >>> 0.2 >>> [mt269@swiftgen results]$ wigToBigWig test2.wig hg19_chrom_sizes.txt >>> test2.bw >>> There's more than one value for chr1 base 2 (in coordinates that start >>> with >>> 1). >>> >>> If I manually set span=1 in my files it works OK (i think). Is this a >>> bug, or am I once again plagued by a mis-understanding of wig >>> coordinates? >>> Thanks, >>> Melissa >>> _______________________________________________ >>> Genome-mirror mailing list >>> [email protected] >>> https://lists.soe.ucsc.edu/mailman/listinfo/genome-mirror >> >> _______________________________________________ >> Genome maillist - [email protected] >> https://lists.soe.ucsc.edu/mailman/listinfo/genome _______________________________________________ Genome maillist - [email protected] https://lists.soe.ucsc.edu/mailman/listinfo/genome
