[Bioc-devel] IGV - a new package in preparation

Hi,

 > -----Original Message-----
 > From: Bioc-devel <bioc-devel-bounces at r-project.org> On Behalf Of
 > Michael Lawrence
 > Sent: Friday, March 09, 2018 1:49 PM
 > To: Paul Shannon <pshannon at systemsbiology.org>
 > Cc: Gabe Becker <becker.gabe at gene.com>; bioc-devel at r-project.org
 > Subject: Re: [Bioc-devel] IGV - a new package in preparation
 >
 > Couple of things:
 >
 > 1) Check out epivizr and the surrounding infrastructure (maybe Hector

can

 > chime in). It's able to serve up data directly from R; would be nice if

we

 > could do that with IGV, instead of writing out to files. That would

require

 > it to talk to some standard API, like the old DAS.

One value of writing to files is that if IGV is running on remote host
then retrieval via byte-range encoding continues to just work.

Of course this is dependent upon what you are trying to do.

~malcolm_cook at stowers.org

 >
 > 2) The rtracklayer API is in rtracklayer/R/browser.R. See ucsc.R for how
 > that is implemented for UCSC.
 >
 > On Fri, Mar 9, 2018 at 9:59 AM, Paul Shannon
 > <pshannon at systemsbiology.org>
 > wrote:
 >

 > > Thanks, Levi. Your comments, and Gabe?s are very helpful, getting me

to

 > > consider things I have overlooked.
 > >
 > > Support for GenomicRanges is essential, as you and Gabe point out.
 > >
 > > In all cases IGV will convert a GRanges object to an appropriate

track,

 > > then write it out as a temporary file.  igv supports bed, gff, gff3,

gtf,

 > > wig, bigWig, bedGraph, bam, vcf, and seg formats, and a variety of
 > > sources:  files via http, google cloud storage, GA4GH; recent limited
 > > support has been provided for direct javascript data.   Maybe someday
 > > AnnotationHub?
 > >
 > > GenomicRanges as I understand them are very flexible, not subclassed

 > into

 > > types as are track formats.  So I propose that in many cases it will

be he

 > > user?s responsibility to specify track type, call the appropriate
 > > constructor, maybe specify column names so that the right scores can

be

 > > extracted from the mcols - whose names are, so far as I know, are not
 > > standardized.
 > >
 > > If the GRanges object is too big - greater than a densely packed

 > megabase,

 > > for instance, igv works best if the track file is indexed and served

up by

 > > an index- and CORS-savvy webserver.   Thus the IGV should politely

fail -

 > > or at least issue a warning -  when encounters big tracks.  This ?too

big?

 > > threshold may change over time.
 > >
 > > Reading through Michael?s rtracklayer vignette I came across this:
 > >
 > >    The rtracklayer package currently interfaces with the UCSC

web-based

 > > genome browser.
 > >    Other packages may provide drivers for other genome browsers

through

 > a

 > > plugin system.
 > >
 > > Can anyone (maybe Michael himself?) comment on how I can evaluate an
 > > rtracklayer plugin strategy for igv?
 > >
 > >  - Paul
 > >
 > >

 > > > On Mar 9, 2018, at 4:15 AM, Levi Waldron

 > <lwaldron.research at gmail.com>

 > > wrote:

 > > >
 > > > On Thu, Mar 8, 2018 at 12:29 AM, Paul Shannon <

 > > pshannon at systemsbiology.org> wrote:

 > > > Thanks, Gabe.
 > > >
 > > > You make an excellent point: bioc objects get first class support.

In

 > > some instance, base R data types deserve that also, and data.frames

lead

 > > the list for me, being useful, concise, universally available,

expressive.

 > > >
 > > > So perhaps not ?data.frames replaced by? but ?accompanied by?

 > > appropriate bioc data types?

 > > >
 > > >  - Paul
 > > >
 > > > Definitely +1 for supporting GenomicRanges, including what's in

 > genome()

 > > and mcols(). There's a demo of an rtracklayer -> GRanges -> UCSC

genome

 > > browser workflow in the rtracklayer vignette that I've made use of. I
 > > wouldn't necessarily say *don't* support data.frame, but I would

certainly

 > > encourage Bioc users to import data with rtracklayer instead of

generic

 > > read* functions, and to take advantage of the vast AnnotationHub and
 > > OrganismDbi-based annotations which provide GenomicRanges objects.

 > > >
 > > > Thanks and looking forward to it!
 > > >

 > >
 > > _______________________________________________
 > > Bioc-devel at r-project.org mailing list
 > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
 > >
 > >

 >
 >      [[alternative HTML version deleted]]
 >
 > _______________________________________________
 > Bioc-devel at r-project.org mailing list
 > https://stat.ethz.ch/mailman/listinfo/bioc-devel