Hi Duke, We are currently unable to reproduce what you describe. Can you please send us a bed file that displays differently as a bigBed file? It would ideal if this bed file had data in a just a small chromosome range so that it was not so big.
Best, Mary --------------------- Mary Goldman UCSC Bioinformatics Group On 8/19/10 8:37 AM, Duke wrote: > Hi Hiram, > > On 8/19/10 11:24 AM, Hiram Clawson wrote: > >> Good Morning Duke: >> >> Your track has too many items in the location of view to display them. >> The genome browser lowers its visibility until it fits comfortably. >> In the worst case, it will only display in 'dense'. >> > So why the bed file acts normally, but the bigBed does not? I think > bigBed is a compressed version of bed, so it should act the same as bed. > > Thanks, > > D. > > >> You can make a density graph of your track with the kent src utility: >> bedItemOverlapCount >> in: src/hg/bedItemOverlapCount/ to get an idea of the pile ups. >> >> --Hiram >> >> ----- Original Message ----- >> From: "Duke"<[email protected]> >> To: [email protected] >> Sent: Thursday, August 19, 2010 8:16:44 AM GMT -08:00 US/Canada Pacific >> Subject: Re: [Genome] bigBed always be pack >> >> On 8/19/10 9:56 AM, Duke wrote: >> >>> Hi all, >>> >>> I tried to convert a bed file to bigbed, and visualized it on our local >>> UCSC mirror, but unfortunately no matter how I change the setting, the >>> track always stayed at pack. It seems that full or squish does not do >>> anything with the track. Since the track and the file are in our local >>> server, I can not post link here at the moment, but I will consider >>> loading to external host if needed. The bigBedInfo command shows: >>> >>> $ bigBedInfo adipose-uni.bowtie.bb >>> version: 4 >>> isCompressed: yes >>> isSwapped: 0 >>> itemCount: 19,132,866 >>> primaryDataSize: 148,503,559 >>> primaryIndexSize: 1,208,984 >>> zoomLevels: 10 >>> chromCount: 25 >>> basesCovered: 49,603,138 >>> meanDepth (of bases covered): 12.343004 >>> minDepth: 1.000000 >>> maxDepth: 183964.000000 >>> std of depth: 257.659587 >>> >>> so I think there is nothing wrong with it. Do I have to do something >>> else, or did I do something wrong? >>> >> Sorry, it should not be "always". Actually if I set the bigBed to >> /full/, it is only be /full/ in some range and/or locations. Most of >> other cases, it stays at /pack/ visibility. The corresponding bed file >> acts correctly (meaning /full/ is /full/ :D). Is this expected or there >> is an option that I have missed? >> >> Thanks, >> >> D. >> >> _______________________________________________ >> Genome maillist - [email protected] >> https://lists.soe.ucsc.edu/mailman/listinfo/genome >> >> > _______________________________________________ > Genome maillist - [email protected] > https://lists.soe.ucsc.edu/mailman/listinfo/genome > _______________________________________________ Genome maillist - [email protected] https://lists.soe.ucsc.edu/mailman/listinfo/genome
