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]]

