by Robert Kuhn August 12, 2015
The UCSC Genome Browser is great tool for visualizing your data alongside a ton of data from all over the place. Perhaps, at long last, you have loaded up a gene set, the supporting mRNAs and maybe the SNPs from OMIM or dbSNP, and the Conservation track to make a great point.
Now you want to save that thought, or share it with a colleague, or make a slide for a meeting, or publish it in a paper. Saving your screenthought can take two forms: static or dynamic. You can snap and save a picture of the screen, or you can share a link to an active Genome Browser. We’ll talk about both approaches here and discuss some of the advantages and pitfalls of each.
Share a static image. You can always take a screen grab and throw it onto a slide with little effort. The screen resolution is fine for a slide, because your computer and your slide will both be 72 or 96 dpi. But, if you try that for a publication, your image will have to be really small (scale down 3x in each dimension to get 300 dpi for print) or it will be unacceptably fuzzy.
To get high resolution images for publication, use the Browser’s .pdf export function to allow the vector-graphics image to scale to full journal size and resolution. Look for the .pdf output in the “View” pulldown menu at the top of the Browser page. Both the chromosome ideogram and the main Browser graphic can be saved in this fashion.
Share a dynamic session, but DO NOT copy a URL. To save a dynamic screen session that would allow you or others to look around, add more data tracks, check out other genes, etc., you might be tempted to simply copy the URL from your Firefox or Chrome web browser. That might even seem to work OK at first, but it is in fact not a stable link and can lead to weird Browser behavior. Worse, you may not even be sharing what you think you are, and will never know it.
Let’s break down a URL as copied directly from my Firefox and see how it plays out.
This URL contains a parameter, hgsid, which is actually a pointer to a row in a UCSC database identifying your session and keeping the state of all your variables (we borrowed the name “cart”). If you send this URL to someone, yet keep browsing around, your cart will continue to change as you work, and your friend will see the latest state your Genome Browser is in when she clicks the link. The original state of your cart when you shared the URL is long gone before she sees it.
Your shared URL might even appear to work OK because two of the variables in the URL, db (database) and position, will override values stored in your cart (cart variables are separated by an ampersand). Your friend will see the right genome assembly (db variable) and location (position variable) and think she’s seeing what you want. But, if you have turned any data tracks on or off in the interim, or removed a custom track, those changes will also be part of what she sees. The original state is lost. A different colleague could click the link at some other time and see something different still.
As an experiment, here is that same URL in a form you can click or copy/paste into your web browser:
Does it look like this?
That’s what it looked like when I shared the URL. Your click will show the 5’ end of the FGFR1 gene region on human assembly hg19 (because the URL has explicitly included db and position variables), but who knows what tracks might be turned on or off in the interim? Whatever the last person to click it did to it will rule. Every person who reads this blog and clicks the link can change the track configuration for whomever comes next. Only the db and position are going to persist.
Quick-and-dirty URL hack. If you really want a quick-and-dirty way to share a link, here are a couple of suggestions. You could send the link as it is above, then strip a few characters out of the hgsid in the URL in your own browser and refresh. Because the new long hgsid string will not exist in our database, you will be assigned a new hgsid and the state of the old one will stick – until your friend starts messing with it. Or you could strip out the hgsid parameter entirely and add in other parameters that define the tracks you want to turn on, e.g.:
That will better define the tracks you want, but it is neither as stable nor as easy as saving a Session. You can use “hide,” too, to be sure certain tracks are turned off. Read more about configuring your links here.
Share a stable dynamic Session. The best way to save a train of thought in a stable fashion is via the Saved Session tools under the “My Data” pulldown menu. A Saved Session acts as a stable snapshot of all the details of your Browser view. Saving a thought using this feature requires a login, but it allows you to save the state of a Browser session (semi)-permanently. Anyone viewing your session will be able to further browse around the genome without affecting the session you saved. After you have saved a session, you will see a “Browser” link that can be copied and shared.
For example, to load the view above as a stable session, try this link (no login is required to view some else’s Saved Session):
Although anyone with this URL can view this session, no one can change it unless logged in as user “SessionGallery.”
In the past we endeavored to save the Session for at least 3-4 months after the last time it was viewed, and custom tracks in sessions were subject to persist for at least 48 hours after the last time they were viewed. We have now moved to not remove session data, unless deleted, and to not remove custom tracks in sessions. We still encourage people to save their Session cart to a local file using the “Save Settings” feature (and to keep backups of all their custom tracks on a local machine). That way, you can load your Session settings any time and onto any copy of the Browser (such as to the European mirror or a local Genome Browser-in-a-Box) and avoid any possible loss of data due to unforeseen circumstances. We do the best we can to maintain our servers so that you do not lose your sessions, but computers are only human and they break.
Really stable sessions. If you are looking to create a permanent link for a publication, you should consider hosting your downloaded Session and any of your own custom data on a server you control (such as in a Track Hub). It will still be loaded onto the UCSC Genome Browser, but you are not at the mercy of California earthquakes, wildfires or crashed servers (except for your own). You can read more about building links to remotely hosted user information here and on our Session’s Gallery page here.
On both pages you can learn about the following parameters for forming links to launch sessions from your hub:
We hope we have given you some food for thought about how to make the Genome Browser more useful in your work. Using a reliable method for saving and sharing sessions is great way to avoid the frustration of lost data and misleading links. Stay tuned for more useful Browser tips in future blogs.