Re: [Gmod-ajax] JBrowse track groupings

[Brenton G. <brg...@gm...>]

I think this would be one option, though it would be best to retain  
the ability to turn individual tracks on or off.  For simplicity sake,  
there are times when viewing 12 embryonic tracks gets overwhelming and  
having just 1 or 2 is sufficient to compare embryos to adults, for  
instance.

So, one thing the modENCODE gbrowse site has is on button to click on  
or off a whole set of tracks, and other buttons to click on or off the  
individual subtracks.  Something like this would be ideal....

Disk space is starting to become an issue - I recently started making  
the wiggle track images at half the default height in order to save on  
some disk space (I haven't calculated or compared the size difference,  
but assumed there would be).  For the fly genome, at 150 MB, it isn't  
so bad, but tracks for the human genome are much larger and it is much  
more of an issue.



On Sep 29, 2009, at 11:00 AM, Mitch Skinner wrote:

> On 09/29/2009 07:36 AM, Brenton Graveley wrote:
>> One thing that would be very useful for users like me who have a  
>> lot of tracks s the ability to select entire groups of tracks to  
>> load at once instead of having to do it individually.  For  
>> instance, our modENCODE browser has 30 different RNA-Seq tracks  
>> from different timepoints throughout Drosophila development.  If  
>> there was a way to load all 12 embryonic time points at once it  
>> would be great.
>
> I've been thinking about this and I have some questions :)
>
> One alternative that was high on my list was to do something like  
> what GBrowse does on the modENCODE server:
> http://modencode.oicr.on.ca/cgi-bin/gb2/gbrowse/fly/?start=123000;stop=180000;ref=2L;width=800;version=100;flip=0;grid=1;id=405c399cbe0d255c1a2d44e9a4f1e306;label=EMBRYO_SG_Total
>
> There are two things going on there; 1. conveying quantitative data  
> with color (lighthouse #7), and 2. subtracks that you manipulate  
> (turn on and off, re-order) together.
>
> One possibility that would be easy to implement client-side would be  
> just to have one image track with several subtracks in each image.   
> A nice feature of that approach is that it would reduce disk usage  
> on the server (which I've been concerned about) to some extent by  
> reducing the number of images (there's some filesystem overhead  
> associated with each image file, so fewer larger files are better  
> than more numerous smaller files).  Has disk space been an issue for  
> you?
>
> A drawback of putting all the subtracks into the same image track  
> would be that you couldn't turn the subtracks on and off  
> individually.  Do you always (or almost always) want to view all the  
> time points (or, say, all 12 embryonic time points) together, or do  
> you sometimes want to reorder them or turn them on and off  
> individually?
>
>>  Perhaps one way to do this would be to have a menu type thing on  
>> the left where you could have nested tracks.  So, perhaps you could  
>> have one track listed as "Development" and dragging this to the  
>> right would load all 30 time points.  Alternatively, there could be  
>> an arrow that you could click on and it would display the next set  
>> of groupings (e.g., Embryos, Larvae, Pupae, Adults).  Again, you  
>> could either drag one of these to the browser window to load the  
>> whole set or click on an arrow to show the next set of grouping  
>> (e.g., the individual tracks in each group).  I have absolutely no  
>> clue how easy or difficult something like this would be to  
>> implement, but it could be quite useful, especially since we will  
>> have many more tracks (~200 in the next year or so) to add to the  
>> browser.
>
> Some kind of hierarchy in the available track list is definitely  
> will-do functionality.  The modENCODE people have been telling me  
> the same thing, that they'll have lots and lots of tracks soon.  A  
> sense of when it'll happen is helpful for prioritizing that  
> functionality relative to everything else people are asking for, so  
> thanks for the time/track-count estimate.
>
> Mitch