jbrowse
jbrowse copied to clipboard
GMOD
"virtual tracks" as a mechanism for initiating analyses
"virtual tracks" are tracks which display the results of running xrate on a window. As long as lazy loading (LH #4) is in place (along with tiled images), you can map tiles to windows, and implement a just-in-time version of windowlicker, quite straightforwardly.
This ticket has 0 attachment(s).
Ian is the main driving force behind this one, so he's the best one to talk to about it. xrate is a tool that Ian wrote that generates annotations (sequence features) from multiple sequence alignments; when I was in the lab, we used it to look for (predict) ncRNAs. windowlicker was a program that drove xrate by feeding regions ("windows") of the alignment to xrate.
To get a track with xrate predictions currently, you'd have to run windowlicker/xrate ahead of time to generate a bunch of annotations and then feed those annotations into the x-to-json.pl code. The goal with "virtual tracks" is to avoid doing that work up front, and only run xrate (or some other analysis program) on a region of the genome once that region has been requested by the client. Then the results of the analysis could be sent to the client as the track data for that region.
One reason to only do the analysis/annotation on-the-fly would be if it's very expensive to do the analysis for the whole genome, and you expect to only look at a small fraction of it. Another reason would be if you want to play with the input parameters for the analysis and visualize the result of your changes.
One of the things that I think you'd have to figure out as a part of this would be what happens at the boundaries of windows when the user scrolls through them. For example, if there's an ncRNA that spans the edge of the region that gets fed to xrate, then xrate won't predict it. The windows that windowlicker feeds to xrate overlap; you could do something similar for virtual tracks, but then you have some output annotations that are potentially redundant between different windows. Then I think you have three choices:
- just show all of the redundant annotations in the jbrowse client (meaning that a single annotated region would show up multiple times if it was in the window overlap area; that wouldn't be my choice, but it's the simplest to implement)
- somehow de-duplicate those redundant annotations to only show the "unique" ones (would have to be heuristic, I think)
- throw away all of the data from one window when the user scrolls near the edge of it, and get all new data for a new window centered on the region the user is viewing (probably the best solution; the only drawback is that the features would get re-layed-out when that happens. That re-layout would make some features move vertically, which might be confusing if you didn't know what was going on, but if you expected it, then it might be fine. Smooth visual continuity, as a way of helping the user build an internal mental model of where seq features are relative to one another, is a big part of the point of JBrowse in my mind, so the re-layout bugs me, but maybe the virtual track advantages are worth it, or maybe there's a way around it)
I think you've probably seen a demo of Galaxy's trackster, where some tracks can be dynamically filtered; the user can move a slider that controls some filtering parameter and see the result of the change in real time. I think that's pretty cool; those visual changes probably also require a re-layout, but those changes are specifically driven by the user, and they convey information, unlike any re-layout that would happen in virtual tracks.