Talk:Draft Protype for Visualization of phylogenetic data
Vivek, the demo application you put online is very compelling! I am keen on learning about and working with this type of a framework, as it seems rather agile for quickly sketching out new ideas.
I would be particularly interested in finding *new* ways of looking at huge trees (or huge databases of small trees) where the focus is NOT on plotting the 2D "shape" of the tree itself, but rather on identifying other types of plots, tables, or diagrams that would be most useful to the interested biologist / taxonomist. Some potential questions we could begin answering with such a framework:
- At a given point in time, what are the relative sizes of each taxonomic group?
- What percentage of trees (in TreeBASE, for example) lend support to one particular branching pattern over another?
- (this one would directly involve the tree plotting) How does a given taxonomic character change throughout the tree?
These would all involve using either the canvas element or some other visualization API to generate the appropriate charts or plots.
Another idea would be to plot various data alongside the 2D tree:
- Look at extinction rate vs. tree structure -- plot a time-resolved species tree alongside an estimate of extinction rate
- Similarly, historical data for temperature, climate, etc. could be plotted in this fashion. This isn't exactly relevant to NeXML, but it might go along well with the "mash-up" spirit of database interoperability.
Gjuggler@gmail.com 05:57, 4 March 2009 (EST)
Vivek : Hi Greg, Thanks for your response. I am concerned to use Java applet for larger trees or even to visualize other large datasets, because applets relies on the clients hardware capabilities to generate and render drawings. I would suggest a 'Google Map' kind of approach for that.
- Perform all intensive tasks ( tree drawing, tree rendering, character state coloring, continous dataset, etc ) in the server.
- then only pass the image along with position information of nodes or features (image maps) to the client side.
- In the client-side, design the interactions and all the fancy popup panels for user to interact with the data.
For example, for the visualization related question "At a given point in time, what are the relative sizes of each taxonomic group?", my approach would
- Draw a simple prototype of what exactly the user wants in the client side in powerpoint or photoshop (tree with the radius of the nodes relative to the number of taxonomic group)
- Collect all the interface related actions user perform on the dataset or plot (Zoom in, Zoom out, panel to view annotation, Drag the image or select a section in the image, edit options, a popup panel showing the properties o the node)
- Write script in the server side to generate the image similar to that in the prototype that is drawn in step 1. The NeXML data model and API should be used for generating this. (in Java, awt.graphics2D is more than sufficient).
- Pass the image and the control points on the image to the client side (As JSON object to the client side Ajax).
- In the client side, update the image in the <img> tag and create all the control panels on the image..
We could also allow user to enter a PhyloWS service in the client side and the server should handle the request and send the results to the client side. <Canvas> tag drawings could be used to generate simple drawing/controls on the client side or to highlight an arc or circular region on the node of the tree, rather than for drawing the tree.
Note : when I open PhyloWidget in Firefox (MacBookPro 2.4 Ghz with 4 GB ram), it took 4 seconds to load and also shows a flickering which is typical of applets.
Let me know you comments...
--vivek 21:43, 4 March 2009 (EST)
Thanks for your further comments.
Regarding the benefits of server-side and client-side rendering, you do make a good point. I would still argue that there is always some utility for both styles of rendering, depending on the user's needs (just as Google provides three ways of looking at Google Maps: regular online version, a flash-based viewer, and the more "client-side" Google Earth). Especially in terms of redeployment and offline use, applets have a much lower barrier to entry.
BUT, despite my natural inclination towards client-side everything, I am impressed by your demo and would like to help investigate things in this direction.
I can see a potential hackathon project going in one of two ways:
- Providing a "full-service app" for visualization (and limited manipulation) of NeXML data, as in the demo and prototype that you've provided here.
- Providing a tree image generator as a web service in itself, a la Google's URL-based charts API.
In fact, these two approaches could complement each other very well. The rendering service could be one half, and the GWT-based testbed / tree manipulation suite could be the other. The rendering service would be called by the testbed in order to provide the appropriate tree images, and the UI controls would be overlaid using the GWTCanvas utilities.
I would be keen on putting in some time to define the parameters and options involved in rendering the trees, and potentially adapting PhyloWidget's (currently applet-oriented) rendering code into a server-side tree image generator. If done right, we could go part of the way towards defining the set of standard options for visualizing trees, and giving an example web service for how to do it well.
What do you think?
Gjuggler@gmail.com 12:11, 5 March 2009 (EST)