Great! The provided information is very helpful. Thank you very much Mary.

D.

On 8/25/10 8:05 PM, Mary Goldman wrote:
> 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

Reply via email to