Web-apollo-meeting-2011-4-11

From GMOD
Jump to: navigation, search

Jay

  • Trying to get Tomcat set up--having to do it manually. He's going to talk to some groups that use Chado with some questions about how people are setting up references to their Chado instances.
  • He's looking at setting up theirs with XML lookup.
  • He'll probably commit the Wave (?) query code on Wed.
  • Gregg is curious about performance of the range queries. Jay will let him know.

Gregg: Graphs on Steroids

  • demo: genomancer.elasticbeanstalk.com
  • Follow these steps to do demo.
  • Take off user-created annotation track (temporarily causing problems for viewing other tracks such as graph tracks). Drag it off and reload.
  • Zoom in until you're seeing about 100,000 bases, then go to 0 to see first 100K bases. Center around 75,000.
  • Be sure you have the conservation track up--uses standard JBrowse image tiles
  • Drag over CanvasTrack test track (takes a while to load).
    • If it looks a bit off (this can happen if you resize the browser)--e.g. peaks don't line up with conservation track--try reloading.
  • This is a totally different way of rendering graphs. Loads up wiggle file (rather than images) from the server side and renders on HTML5 canvases.
  • . Zoom out so you see more than 100K bases. You'll see that the CanvasTrack test track ends at 100K, because that's how much is in the wiggle file. Note that it still renders pretty fast, even when you zoom out. That's because it compiled summaries of the data when you first loaded, so it doesn't have to render all the points.
  • Double-click on CanvasTrack test label. You get a graph adjustment widget with a color chooser. Lets you customize view in realtime! Can set graph range and style as well as color.
    • Changing graph range can, e.g., let you see more detail in an area where there are small peaks.
      • Not that interesting for this particular test track, bcs range is fairly confined, but for tracks like HTS density tracks, where the range is big, constraining the range can be very useful.
    • Changing graph style: if you're zoomed out (so there are a bunch of datapoints per pixel), try picking "AvgBar + MaxBar". For the image tiles, those are always pre-rendered (server side) as an average. This style is showing that plus also the max value at that pixel (in a desaturated background color).
    • Behind the scenes, this is a modular architecture, so you can plug in different renderers. Right now, there are five different javascript classes for the five different renderers. There are many others we could add.
      • AvgBar + MinPoint + MaxPoint: min shown as little speckle in average bar (which is desaturated).
      • Gregg's favorite graph style: AvgRange + MinMaxRange. To see this, first zoom out until you have at least 5 bases/pixel. (E.g., show 60K-80K.) Shows line for the average, and a grayscale bar behind that for the min to max range for each pixel. This is especially useful where the data gets noisy.
      • Last style (which he doesn't really like): AvgLine (looks very dim). This shows some of the limitation of Canvas and how it deals with transformations. If one of your dimensions is a long space transformed into a short space, it tends to get antialiased into oblivion.
      • For many kinds of data, you might not care about the minimum, in which case AvgBar + MaxBar is good. But if you want to see the min and the max and the average, AvgBar + MinPoint + MaxPoint is the best.
  • Gregg will check in this work, but there's still a lot to do in terms of being able to import lots of data in a lazy fashion. JBrowse's image tile stuff deals with that because it's pre-rendered and you just load what you need at a particular resolution, so Gregg needs to do similar things on the client side with the raw data. He's hoping to explore other kinds of exploratory data analysis capabilities like on-the-fly thresholding, etc.
  • To make graph style widget go away, double-click again and it folds back up into the track label. (Nifty Javascript trick.)
  • Right now, demo is kind of fragile (you need to follow the exact steps described above) but Gregg will be improving that in the next few days.

Ed: where is the data coming from? Trellis?
Gregg: made the conservation track by pulling down a big Wiggle file from UCSC and processing with a perl script (?) to generate a slice of the Wiggle data and put it on the elasticbeanstalk server. (There is no lazy data loading right now.) The intent is that user should be able to load local Wiggle files from their own machine. People shouldn't have to rely entirely on the server having all the data, esp. for experimental data.
Companies prefer this--don't have to push their data out to a public server just to view it.
Gregg is enthusiastic about Canvas as an alternative way of presenting the graph data; however, it's not supported by older browsers. (Consensus is that that's not a big problem--users can download a new browser free. Would be nice if it failed gracefully--e.g. a grayed-out track, and if you try to drag it it says, "You need to download a new browser".)

?...Thomas Down, Dalliance genome browser... ? (I missed this bit.)

  • Gregg and Ed will Skype later in the week (maybe Wed. or Thurs.) about some annotation editing UI stuff.

Ed

  • Has been working on Undo/Redo.
  • It's working pretty well. History-based, has persistence. Even if server crashes or you close your browser, it saves history. Ed set up a framework to keep track of histories.
  • Undo/redo concept is hard when you have multiple users editing multiple copies of the same feature at the same time. What does undo even mean? We decided that the system should create a history for each feature (transcript) and all the users who edit that feature will share that history, so if a user undoes something, it will go back in that shared history. However, we run into some issues. Some operations--e.g. split generates two transcripts. What if you then edit each transcript, and then try to undo? We try to consolidate changes, but some changes can't be consolidated. This is more complicated with our data models than it is with just text.
  • Undo is working; redo is mostly there.
  • Will need to constrain size of history (e.g., last 50 changes).
  • Architecture: separate history db. History for each transcript. Keeps track of where you are on the "stack" (but in order to optimize memory use, it's not actually implemented as a stack). Easy to get rid of whole history (by wiping out history db) w/o affecting annotations.

Server

  • Server hardware--not here yet?
    • Would be nice to move off elasticbeanstalk.
    • Ed will ping Seth to see what the status is.

Chris C

  • Suzi mentioned yrGate--another Web-based annotation editor (aimed at plant annotation). http://www.plantgdb.org/prj/yrGATE/
    • Not going the same route as we are with Ajax/Javascript--it's mostly server-side stuff.
    • You can click on an image map, and it knows which exon you clicked and can add it to the model.
    • Gregg has asked Ann Loraine (who does a lot of plant annotation stuff) what she knows about it.
    • We can look at it for ideas.
  • zedMap: can copy and paste genomic sequence (?) into window. yrGate has something similar. Another window has NCBI nomenclature that you can copy and paste.
  • Let us know what you like (or don't like) about yrGate.
  • Gregg; Has anyone thought more about the Annotation Jamboree idea?
  • Chris E: We should talk to Suzi about it.
  • Gregg: We concluded that we should do it connected to some meeting--maybe next January? (There's a meeting in May that would be appropriate, but that's too soon.)