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
