On Mon, Oct 25, 2010 at 10:45 AM, Paul Shannon <pshannon@systemsbiology.org>wrote: > Hi Michael, > > Thanks for your reply. Very helpful. > > My first and main problem with learning rtracklayer was the complexity of > the first example in the vignette. It's a great example, but so hefty, and > so much dependent upon data reduction unrelated to the browser tracks > (limma, for instance), that it obscured for me the simple powerful commands > and capabilities you provide. There also seems to be rather a shortage of > examples in the man pages. > > The lack of examples is a good point. The vignette was sort of meant to show a complete analysis, so there's going to be added complexity. > Another place I got confused was in creating a GRange object to set the > range of the browserView. I passed in the same GRange object I had used in > my call to GRangesForUCSCGenome. It took me a while to figure out why I get > 21 browser tabs in response! Then I woke up, doing this instead: > > gr.chr1 <- GRangesForUCSCGenome ('hg18', exon.chrom.names, exon.ranges, > exon.strand, name, score) > # note: range has just one element > range.to.view <- GRanges (seqnames='chr1', range = IRanges (min (start > (ranges (gr.chr1))), max (end (ranges (gr.chr1)))), span='*') > > I guess I am confused here. The gr.chr1 should open a view for each exon. Do you only have 21 exons? Btw, the second line can be simplified to: range.to.view <- range(gr.chr1) > session <- browserSession ('UCSC') > track (session, 'exonHits') <- gr.chr1 > Could be simplified: session$exonHits <- gr.chr1 > view <- browserView (session, range.to.view, full='exonHits', dense=c > ('chainNetPanTro2', 'chainNetMm9'), hide=trackNames (session)) > > I also scratched my head for a while over the 'seqnames' argument to > GRanges. I naively thought these would be the names of the features I was > laying down in the track, only to eventually figure out that chromosome > names were needed. > > Is it possible to control the color of features displayed in a track? > > This is done through the trackLine. See class?TrackLine. Since you're starting with GRanges, it's easiest just to specify trackline parameters during the upload, e.g.: track(session, "exonHits", color = "blue") <- gr.chr1 Does rtracklayer choose a bed tract when no metadata is supplied in the > GRanges object? And a wiggle track if there is numerical metadata? That's basically it. It might use bedGraph for numerical data that does not compress well into wig. See help(export.ucsc). > Does a 'score' column have special meaning? It does for exporting data. All formats have a "score" column, which is mapped to/from the "score" column in the RangedData or GRanges. > Can we set the max and min of a wiggle track? Right now they are > calculated from scores in my GRanges object. > > This is another track line parameter, called viewLimits. See class?GraphTrackLine. Something like: track(session, "wiggle", viewLimits = c(0, 100)) <- wiggle I hope all this makes sense. > > - Paul > > > On Oct 25, 2010, at 10:16 AM, Michael Lawrence wrote: > > > > > > > On Mon, Oct 25, 2010 at 9:37 AM, Paul Shannon < > pshannon@systemsbiology.org> wrote: > > I have climbed what, for me, has been a difficult learning curve with > rtracklayer. Now that I understand it better, I really like it. It's a > very useful package. > > > > > > It would be good to hear what you found to be difficult. > > > > I have a few remaining questions about controlling which tracks I see, > and what view mode they are in (dense, squish, pack, or full). > > How do I implicitly or explicitly hide all tracks, except for a select > few, when creating a BrowserView? And how can I subsequently modify the > view mode of selected tracks? > > > > 1) When my UCSC browser session has some previously viewed tracks on by > default, these remain visible when I create a new view: > > > > view <- browserView (session, range.to.view, full='exonHits', dense=c > ('chainNetPanTro2', 'chainNetMm9')) > > > > I see these three tracks, plus a half-dozen others left over from > previous browsing. > > > > Instead, I wish to tell the browser "hide all tracks except those I > explicitly mention', perhaps like this: > > > > view <- browserView (session, range.to.view, full='exonHits', dense=c > ('chainNetPanTro2', 'chainNetMm9'), hide='everythingElse') > > > > > > Everything in "..." is passed to the ucscTrackModes function. This > function favors "full" over "hide" (sorry, this was not documented), so you > could do something like: > > > > view <- browserView (session, range.to.view, full='exonHits', dense=c > ('chainNetPanTro2', 'chainNetMm9'), hide=trackNames(session)) > > > > Another option would be to use the 'track' parameter, of browserView, > which lists the tracks that should be included in the view. This is merged > with the mode parameters, with the mode parameters taking precedence, so > this would also do the trick, I think: > > > > view <- browserView (session, range.to.view, track = character(), > full='exonHits', dense=c ('chainNetPanTro2', 'chainNetMm9')) > > > > 2) My second question: how do I communicate the specific view mode when > calling the 'trackNames' method? trackNames will hide everything besides > what I explicitly name (a workaround for question 1, above), like this: > > > > trackNames (view) <- c ('exonHits', 'chainNetPanTro2', > 'chainNetMm9') > > > > But this brings it two problems. I cannot control the mode of these > tracks (dense, squish, pack, full). > > > > This is the ucscTrackModes function, e.g.: > > > > ucscTrackModes(view)[c('exonHits', 'chainNetPanTro2', 'chainNetMm9')] <- > c("full", "dense", "dense") > > > > > > And then this method creates a new tab in my browser every time I call > it. (Chrome on OS X 10.6) So every time I want a particular view, with > particular tracks, I need two calls: > > > > view <- browserView (....) > > trackNames (view) <- (<some track="" names="">) > > > > and I get two tabs, the first of which I always delete. > > > > > > There's really no easy way to avoid this, given our lack of control over > the web browser. The current solution is to combine everything into a single > call, as with your first question. > > > > I have pored over the browserView and trackNames man pages, peeked at the > source, all to no avail. > > > > > > I think the rtracklayer documentation needs to be rewritten. At the time > I was not aware of how to effectively document S4 APIs. Following the > Biostrings/IRanges style would be better, I think. > > > > Sorry, > > Michael > > > > Any advice? > > > > - Paul > > > > ---- SessionInfo (following a recent update.packages ()) > > > > > > R version 2.12.0 (2010-10-15) > > Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) > > > > locale: > > [1] en_US.utf-8/en_US.utf-8/C/C/en_US.utf-8/en_US.utf-8 > > > > attached base packages: > > [1] stats graphics grDevices utils datasets methods base > > > > other attached packages: > > [1] GenomicFeatures_1.1.11 rtracklayer_1.10.0 > RCurl_1.4-3 bitops_1.0-4.1 > > [5] BSgenome.Hsapiens.UCSC.hg18_1.3.16 > BSgenome.Mmusculus.UCSC.mm9_1.3.16 BSgenome_1.17.5 > Biostrings_2.18.0 > > [9] GenomicRanges_1.2.0 IRanges_1.8.0 > org.Pt.eg.db_2.4.1 org.Hs.eg.db_2.4.6 > > [13] org.Mm.eg.db_2.4.1 RSQLite_0.9-2 > DBI_0.2-5 AnnotationDbi_1.11.8 > > [17] Biobase_2.10.0 RUnit_0.4.26 > > > > loaded via a namespace (and not attached): > > [1] biomaRt_2.6.0 tools_2.12.0 XML_3.2-0 > > _______________________________________________ > > Bioconductor mailing list > > Bioconductor@stat.math.ethz.ch > > https://stat.ethz.ch/mailman/listinfo/bioconductor > > Search the archives: > http://news.gmane.org/gmane.science.biology.informatics.conductor > > > > [[alternative HTML version deleted]]