[Gmod-ajax] JBrowse: Track Pull-down Menus, Gene Features, and Histogram Generation

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Gmod-ajax] JBrowse: Track Pull-down Menus, Gene Features, and Histogram Generation

Aurash A Mohaimani
Greetings from a fellow JBrowse user!

I've run into a number of issues with a local JBrowse installation for the research group I'm working with that we haven't been able to fully troubleshoot, either from the documentation or from experimentation with native JBrowse features.

First, track pull-down menus appear to scale with the length of a track's "formal name"--that is, the value associated with its "key" in either the "tracks.conf" or "trackList.json" configuration files. For tracks with very long names, this semi-opaque pull-down menu begins to occupy large horizontal swaths of the screen and can obscure entire features from end-users, resulting in a significantly disrupted genome browsing experience.

Second, I've noticed that for "CanvasFeatures" GFF3-parsed tracks (using "flatfile-to-json.pl"), features with type equal to "gene" (in other words, gene features) appear to require "child" features that link back to their parent gene(s) [such as an mRNA feature linking back to its parent gene] in order to even display as an actual gene feature. In the absence of child features, a parent gene in JBrowse 1.11.2 will simply display as copies of itself--that is, the gene name will be duplicated multiple times along the horizontal length of the gene across a given chromosomal location. Further, this bug seems to arbitrarily elongate "childless" gene features beyond their natural length.

As an aside, our group's working installation of GBrowse does *not* require gene features to possess children referencing their parent, so many of our pseudogene entries appear as other genes would. We have been able to correct this anomaly in JBrowse by retrofitting our GFF3-generating pipeline to generate "dummy" pseudogene child entries that reference their [actual] parents such that our pseudogene entries now display as actual features for "CanvasFeatures" tracks.

Third, we've attempted to take advantage of the [very nifty] histogram-generating capacity that JBrowse offers with its GFF3/generic feature tracks. This is really helpful in gauging the number of genes at a given location when examining an entire chromosome's length, but we've unfortunately noticed regions where, upon gross inspection, the generated histogram attempts to tell users that no genes are located within a given region, but upon zooming into the "zero genes region", we find actual genes present.

Might this be related to the manner in which the histogram is generated? For example, if a given gene is too short (say 20-30 kilobases) when looking at a chromosome-wide view that span 200-300 megabases, does JBrowse ignore these (relatively) "short" genes in its histogram tallying?

Would really appreciate clarification on any of these issues!

Aurash

------------------------------------------------------------------------------
_______________________________________________
Gmod-ajax mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-ajax
Reply | Threaded
Open this post in threaded view
|

Re: JBrowse: Track Pull-down Menus, Gene Features, and Histogram Generation

Colin
Hi Aurash,
Thanks for the feedback. These are good issues that you brought up. Some of them have already been brought up on our github issue tracker but i'll walk through them here.

For your first issue I don't think there's a fix yet. There's an open issue now here https://github.com/GMOD/jbrowse/issues/490
I guess we just have to figure out the right user interface design to implement it.


For the CanvasFeatures issue with pseudogenes, I am assuming that your gff has "gene" features with "exon" children? One possibility of this config without modifying the original gff file is to add transcript types is having {'transcriptType': 'gene', 'subParts': 'exon', 'glyph':'JBrowse/View/FeatureGlyph/ProcessedTranscript'}.  if you have a mix of gene->exon types and gene->transcript->exon types this has problems though, so you may need to fix your gff in that case.


For the histogram problem, there is a open issue about this here https://github.com/GMOD/jbrowse/issues/474 but I also want to comment on this with another related issue. There is an issue in jbrowse 1.11.2 and 1.11.3 where the CanvasFeature type tracks aren't able to download the pre-generated histogram data from the server by default, which means that histograms are calculated on the client side "on-the-fly" by downloading all the ffeature data, which is slow. This is actually fixed in jbrowse 1.11.4  https://github.com/GMOD/jbrowse/issues/475, but you can set histograms.binsPerBlock=25 (or "histograms" { "binsPerBlock": 25 } in trackList.json format.) on your CanvasFeatures tracks to fix it in the older versions that you're running as well.
So, essentially, you're right that the on-the-fly histograms  have issues, but the pre-generated ones are more efficient for users, and they don't suffer the same problems that the on-the-fly histograms have.

Hope that makes sense. Let me know if there are any other questions.

-Colin



On Mon, Jul 7, 2014 at 2:07 PM, Aurash A Mohaimani <[hidden email]> wrote:
Greetings from a fellow JBrowse user!

I've run into a number of issues with a local JBrowse installation for the research group I'm working with that we haven't been able to fully troubleshoot, either from the documentation or from experimentation with native JBrowse features.

First, track pull-down menus appear to scale with the length of a track's "formal name"--that is, the value associated with its "key" in either the "tracks.conf" or "trackList.json" configuration files. For tracks with very long names, this semi-opaque pull-down menu begins to occupy large horizontal swaths of the screen and can obscure entire features from end-users, resulting in a significantly disrupted genome browsing experience.

Second, I've noticed that for "CanvasFeatures" GFF3-parsed tracks (using "flatfile-to-json.pl"), features with type equal to "gene" (in other words, gene features) appear to require "child" features that link back to their parent gene(s) [such as an mRNA feature linking back to its parent gene] in order to even display as an actual gene feature. In the absence of child features, a parent gene in JBrowse 1.11.2 will simply display as copies of itself--that is, the gene name will be duplicated multiple times along the horizontal length of the gene across a given chromosomal location. Further, this bug seems to arbitrarily elongate "childless" gene features beyond their natural length.

As an aside, our group's working installation of GBrowse does *not* require gene features to possess children referencing their parent, so many of our pseudogene entries appear as other genes would. We have been able to correct this anomaly in JBrowse by retrofitting our GFF3-generating pipeline to generate "dummy" pseudogene child entries that reference their [actual] parents such that our pseudogene entries now display as actual features for "CanvasFeatures" tracks.

Third, we've attempted to take advantage of the [very nifty] histogram-generating capacity that JBrowse offers with its GFF3/generic feature tracks. This is really helpful in gauging the number of genes at a given location when examining an entire chromosome's length, but we've unfortunately noticed regions where, upon gross inspection, the generated histogram attempts to tell users that no genes are located within a given region, but upon zooming into the "zero genes region", we find actual genes present.

Might this be related to the manner in which the histogram is generated? For example, if a given gene is too short (say 20-30 kilobases) when looking at a chromosome-wide view that span 200-300 megabases, does JBrowse ignore these (relatively) "short" genes in its histogram tallying?

Would really appreciate clarification on any of these issues!

Aurash

------------------------------------------------------------------------------
_______________________________________________
Gmod-ajax mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-ajax


------------------------------------------------------------------------------

_______________________________________________
Gmod-ajax mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-ajax