bigWig (and bigBed) files must be URL resources. They are not files to be passed whole to our server. The benefit is the saving in transport time. Only the bits that are needed for a particular view in the browser are transported as needed. The bits transferred accumulate in a cache at our end so that subsequence views of the same data require no transfer at all.
--Hiram David Hoover wrote: > While we're talking about this, is it possible to upload a bigWig file > into custom tracks using the same mechanism as a wig file, or must the > file be on a remote server and accessed through a URL? > > Hiram Clawson wrote: >> Good Morning David: >> >> Are you talking about the database contents of >> the wiggle data, or the source ascii files that >> are given to wigEncode ? >> >> If they are just the source ascii files, they >> can all go together with 'cat': >> $ cat files*.wig > result.wig >> >> If they have custom track and browser lines in them: >> $ egrep -v "^track|^browser" files*.wig > result.wig >> >> Or, all these can be sent into wigEncode: >> $ egrep -v "^track|^browser" files*.wig | wigEncode stdin result.wig >> result.wib >> >> We now try to distinguish source files with the suffix: >> .wigFixed or .wigVar >> for fixedStep or variableStep wiggle ascii data. >> >> You may also be interested in the more efficient >> encoding mechanism of wigToBigWig and the resulting .bw >> file which can be a URL resource. See also: >> http://genome.ucsc.edu/goldenPath/help/bigWig.html >> This encoder works for bedGraph file types too and is >> much more efficient: >> http://genome.ucsc.edu/goldenPath/help/bedgraph.html >> >> --Hiram >> >> David Hoover wrote: >>> I have multiple .wig files, one for each chromosome. Is there source >>> code for an executable to concatenate the .wig files into a single >>> .wig file? >>> >>> David Hoover >>> Helix Systems Staff >>> http://helix.nih.gov > _______________________________________________ Genome maillist - [email protected] https://lists.soe.ucsc.edu/mailman/listinfo/genome
