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

[Michael Lawrence]

On Fri, Mar 9, 2018 at 12:36 PM, Cook, Malcolm  wrote:

> Hi,
>
>
>  > -Original Message-
>  > From: Bioc-devel  On Behalf Of
>  > Michael Lawrence
>  > Sent: Friday, March 09, 2018 1:49 PM
>  > To: Paul Shannon 
>  > Cc: Gabe Becker ; bioc-devel@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.
>
>
Sure, and we'd want the API to support that as well (like epiviz does now).


> ~malcolm_c...@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
>  > 
>  > 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
>  > 
>  > > wrote:
>  > > >
>  > > > On Thu, Mar 8, 2018 at 12:29 AM, Paul Shannon <
>  > > pshan...@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@r-project.org mailing list
>  > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>  > >
>  > >
>  >
>  >  [[alternative HTML version deleted]]
>  >
>  > ___
>  > Bioc-devel@r-project.org mailing list
>  > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Cook, Malcolm]

Hi,


 > -Original Message-
 > From: Bioc-devel  On Behalf Of
 > Michael Lawrence
 > Sent: Friday, March 09, 2018 1:49 PM
 > To: Paul Shannon 
 > Cc: Gabe Becker ; bioc-devel@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_c...@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
 > 
 > 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
 > 
 > > wrote:
 > > >
 > > > On Thu, Mar 8, 2018 at 12:29 AM, Paul Shannon <
 > > pshan...@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@r-project.org mailing list
 > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
 > >
 > >
 > 
 >  [[alternative HTML version deleted]]
 > 
 > ___
 > Bioc-devel@r-project.org mailing list
 > https://stat.ethz.ch/mailman/listinfo/bioc-devel
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Cook, Malcolm]

Hello,

Jumping in the conversation perhaps late.

If it helps the effort, below are some IGV related R functions I've used in the 
past to good effect communicating with IGV running on local/remote host and 
issuing GOTO and Save Snapshot commands.

They use utils::write.socket

One things that helped my experience greatly was ensuring socket always gets 
closed.


### IGV Interaction


library(functional)

OKCmd.socket<-function(socket,cmds,OK="^OK\\s*"){
  ## PURPOSE: write each cmd in , a character vector, to the
  ##  (appending newlines), warning for those that don't
  ## return  (such as IGV responds)
  lapply(cmds,function(cmd) {
write.socket(socket,paste(cmd,"\n"))
result=read.socket(socket)
if(1 != regexpr(OK,result))
  warning(OK,' was expected in OKCmd.socket while executing [',cmd,'] but 
received [',result,']')
result
  })
}

IGV.make.socket<-
  ## PURPOSE: a version of make.socket which abides to IGV's default
  ## port convention.
  Curry(make.socket,port=60151)

IGV.tell<-function(cmds,...) {
  ## PURPOSE: send all the  to IGV on port determined by <...>,
  ## warning if unexpected IGV response, and being careful to cleanup
  ## by closing the socket.
  message(cmds)
  with(list(s=IGV.make.socket(...)),{
on.exit(close.socket(s))
OKCmd.socket(s,cmds)
  })}

attr(IGV.tell,'ex')<-function(){
  IGV.tell('goto B52','myComputer.myInstitute.org')
  IGV.tell('goto chr4:1234:12345')
  }

sanitize.path<-function(path) {
   ## YMMV
path<-gsub('%','',path,perl=TRUE)
path<-gsub('\\|',' by ',path,perl=TRUE) # good choice?
path<-gsub('[\\,]','',path,perl=TRUE)
path<-gsub('\\/','\\;',path,perl=TRUE)
path<-gsub('\\n',' ',path,perl=TRUE)
path
}

IGVSaveSnapshots<-structure(
function (region
  ,dir='./'
  ,filename=gsub(':','@',sanitize.path(region))
  ,type='png'
  ,filepath=sprintf('%s.%s',filename,type)
  ,...) {
## PURPOSE: create snapshots of  in  in IGV socket
## behind host/port in   NB: the dir must be relative to the
## host on which IGV is running, which may not exist on localhost.
IGV.cmds.gosnap<-function(x,filepath)
c(sprintf("goto %s",x)
  ,sprintf("snapshot %s" ,filepath)
  )
IGV.tell(c(
sprintf("snapshotDirectory %s",dir)
,mapply(IGV.cmds.gosnap,region,filepath)
)
   ,...)
  sprintf("%s/%s",dir,filepath)
},ex=function(){
## 1) Take two snapshots using IGV running on remote host

IGVSaveSnapshots(dir='/Volumes/Users/lab_project/SR_Prot_projects/iClip/myGenes/'
 ,c('ns1'# can be a gene name...
,'X:123-1234' # ...or locus
)
 ,'M0050U1ZE6')

IGVSaveSnapshots(dir='ion\\projects\\mec\\ShilatifardLab\\analysis\\fec\\triptolide\\fig'
 ,region=c(
  ## can be...:
  'chrX:123-1234' # ...a locus
#,'ASNS'     # .. a gene name...
          )
 ,type='svg'
 ,'LA10MJDPKM5.sgc.loc')
})

~malcolm_c...@stowers.org

 > -Original Message-
 > From: Bioc-devel  On Behalf Of Paul
 > Shannon
 > Sent: Friday, March 09, 2018 1:58 PM
 > To: Michael Lawrence 
 > Cc: Gabe Becker ; bioc-devel@r-project.org; Paul
 > Shannon 
 > Subject: Re: [Bioc-devel] IGV - a new package in preparation
 > 
 > Thanks, Michael.
 > 
 > httpuv, to which Hector made crucial contributions, makes it easy to send
 > data directly between R and the browser, using websockets.   I resort to
 > files, however, because when the data, rendered as json, exceeds 500k, the
 > websocket hangs.  I never identified the weak spot.   Some Juypter
 > developers recently had good luck with binary websocket data exchange.  I
 > am cautious, though, about pushing limits and using the latest websocket
 > extension, and found the fallback to local files quite adequate for now.
 > 
 > I’ll look at ucsc.R.
 > 
 > - Paul
 > 
 > 
 > > On Mar 9, 2018, at 11:48 AM, Michael Lawrence
 >  wrote:
 > >
 > > Couple of things

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

[Michael Lawrence]

Yea I wouldn't use JSON, particularly "row-oriented" JSON, as a means of
scalable data transmission.

On Fri, Mar 9, 2018 at 11:57 AM, Paul Shannon 
wrote:

> Thanks, Michael.
>
> httpuv, to which Hector made crucial contributions, makes it easy to send
> data directly between R and the browser, using websockets.   I resort to
> files, however, because when the data, rendered as json, exceeds 500k, the
> websocket hangs.  I never identified the weak spot.   Some Juypter
> developers recently had good luck with binary websocket data exchange.  I
> am cautious, though, about pushing limits and using the latest websocket
> extension, and found the fallback to local files quite adequate for now.
>
> I’ll look at ucsc.R.
>
> - Paul
>
>
> > On Mar 9, 2018, at 11:48 AM, Michael Lawrence 
> wrote:
> >
> > 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.
> >
> > 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 <
> pshan...@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 
> wrote:
> > >
> > > On Thu, Mar 8, 2018 at 12:29 AM, Paul Shannon <
> pshan...@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@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> >
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Paul Shannon]

Thanks, Michael.

httpuv, to which Hector made crucial contributions, makes it easy to send data 
directly between R and the browser, using websockets.   I resort to files, 
however, because when the data, rendered as json, exceeds 500k, the websocket 
hangs.  I never identified the weak spot.   Some Juypter developers recently 
had good luck with binary websocket data exchange.  I am cautious, though, 
about pushing limits and using the latest websocket extension, and found the 
fallback to local files quite adequate for now.

I’ll look at ucsc.R.

- Paul


> On Mar 9, 2018, at 11:48 AM, Michael Lawrence  
> wrote:
> 
> 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.
> 
> 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  
> 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  
> > wrote:
> >
> > On Thu, Mar 8, 2018 at 12:29 AM, Paul Shannon  
> > 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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 
> 

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Michael Lawrence]

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.

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 
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 
> wrote:
> >
> > On Thu, Mar 8, 2018 at 12:29 AM, Paul Shannon <
> pshan...@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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Paul Shannon]

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  wrote:
> 
> On Thu, Mar 8, 2018 at 12:29 AM, Paul Shannon  
> 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Levi Waldron]

On Thu, Mar 8, 2018 at 12:29 AM, Paul Shannon 
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!

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Paul Shannon]

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  

> On Mar 7, 2018, at 2:40 PM, Gabe Becker  wrote:
> 
> Paul,
> 
> Sounds cool! My one note after a quick first pass is that here: 
> 
> On Wed, Mar 7, 2018 at 2:15 PM, Paul Shannon  
> wrote:
> Note that though igv.js typically gets its track data from CORS/indexed 
> webservers, the IGV package will also support locally created R data.frames 
> describing either bed or wig tracks - annotation and quantitative, 
> respectively - without any need to host those tracks on a pre-existing 
> webserver.  httpuv includes a minimal webserver which can adequately serve 
> the temporary files IGV creates from your data.frames.
> 
> It seems to me that those data.frames should be replaced with the core 
> Bioconductor object classes which represent the types of information being 
> displayed.  You might look to epivizr for  inspiration here, which (IIRC) 
> allows "tracks" within epiviz to be backed by bioconductor objects.
> 
> Best,
> ~G
> 
> 
>  - Paul
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 
> 
> 
> -- 
> Gabriel Becker, Ph.D
> Scientist
> Bioinformatics and Computational Biology
> Genentech Research

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Gabe Becker]

Paul,

Sounds cool! My one note after a quick first pass is that here:

On Wed, Mar 7, 2018 at 2:15 PM, Paul Shannon 
wrote:
>
> Note that though igv.js typically gets its track data from CORS/indexed
> webservers, the IGV package will also support locally created R data.frames
> describing either bed or wig tracks - annotation and quantitative,
> respectively - without any need to host those tracks on a pre-existing
> webserver.  httpuv includes a minimal webserver which can adequately serve
> the temporary files IGV creates from your data.frames.
>

It seems to me that those data.frames should be replaced with the core
Bioconductor object classes which represent the types of information being
displayed.  You might look to epivizr for  inspiration here, which (IIRC)
allows "tracks" within epiviz to be backed by bioconductor objects.

Best,
~G

>
>
>  - Paul
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
Gabriel Becker, Ph.D
Scientist
Bioinformatics and Computational Biology
Genentech Research

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel