Hi Duke, We are now able to reproduce what you describe. The default number of items to display for bigBed tracks is 250, while bed tracks can display an unlimited number of items (until the maximum total image height is reached). You can change the default number of items to display by adding "maxItems=#" to your track line when you are loading your custom track, where # is the new default number of items to display.
Please note that your browser may be unable to load the image if there are too many items in one location. We still recommend using bedItemOverlapCount to help users visualize bed files with many items in them. I hope this information is helpful. Please feel free to contact the mail list again if you require further assistance. Best, Mary ------------------ Mary Goldman UCSC Bioinformatics Group On 8/25/10 4:09 PM, Mary Goldman wrote: > 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
