On Tue, Oct 26, 2010 at 7:32 AM, Paul Shannon <pshannon@systemsbiology.org>wrote: > Hi Michael, > > strand = '*' solves the 'm' and 'p' suffixes. Thanks. > > This leads to another oddity. When I expand my GRange -- the one passed to > broserView -- to include all of chromosome 1, I get this error: > > Error in .exportForFormat(format) : > No export function for 'bedLines' found > > I find -- loosely speaking -- that this error comes up whenever I ask to > view more than half of chromosome one. > > I report this in the same (possibly unclarifying) was as the 'm' and 'p' > report. That is, I don't have a small reproducible example. Maybe you can > recognize the problem from my short description instead. > > I think I just committed a fix for this. This also will change/fix the behavior that was resulting in the "m" and "p" tracks. Basically, when automatically selecting an upload format, rtracklayer will fallback to BED if data is not strand disjoint, i.e., if there are any overlapping features, they must be on separate strands. In this case, there's no need for "m" and "p" tracks, because BED tracks store the track for each feature. There was a bug introduced into this logic that caused the "m" and "p", as well as the "bedLines" bug you reference above. I backported this fix to the release version; it will show up with version 1.10.2. Thanks, Michael Thanks, > > - Paul > > On Oct 25, 2010, at 10:16 PM, Michael Lawrence wrote: > > > > > > > On Mon, Oct 25, 2010 at 1:33 PM, Paul Shannon < > pshannon@systemsbiology.org> wrote: > > I've tried hard to come up with a minimal example of this -- some > fragment of code to reproduce the error -- but I haven't figured out yet how > to do that. So instead, and thinking that a brief report might be useful, > and will possibly trigger something in Michael's mind, I send this narrative > email instead. > > > > I create a track with this command: > > > > track (session, 'exonHits') = grange # a GRangesForUCSCGenome object > > > > Then I ask to look at the track: > > > > view <- browserView (session, range.to.view, full='exonHits', > dense='ruler', hide=trackNames (session)) > > > > The problem is that sometimes I get this error: > > > > Error in resolveTrackIndex(x, i) : Unknown track(s): exonHits > > > > When I look for the 'exonHits' track, I learn that there are actually two > of them, each with a suffix: "exonHits m" and "exonHits p" > > > > > grep ('exonHits', trackNames (session.sub), ignore.case=T, v=T) > > exonHits m exonHits p > > "ct_exonHitsm_7841" "ct_exonHitsp_7844" > > > > I can use these odd, modified track names, and display the desired: > > > > view <- browserView (session, range.to.view, full='exonHits m', > dense='ruler', hide=trackNames (session)) > > > > But it seems rather suspicious. Is there any reason for the 'm' and 'p' > suffixes? > > > > > > You've caught another undocumented feature. The graph formats like "wig" > or "bedGraph" do not encode a strand. Since UCSC supports multiple tracks, > if values come from multiple strands, we split them up, for the (m)inus and > (p)lus strands. If this is not desirable, just set the strand on all > features to "*". > > > > Thanks, > > > > - Paul > > > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > 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]]