[Bioc-devel] on to AnnotationTrack with rtracklayer [was Re: IGV VCF demo, other suggestions? [was Re: IGV - a new package in preparation]]

I have now implemented VCF tracks for IGV, supporting both 

   a local VCF object read and filtered by the VariantAnnotation package, and
   a remote webserver-hosted vcf file.   

In normal use I expect (and recommend) that the local VCF object will be relatively small (< 1Mb, < 50 samples - or some tradeoff of those approximate numbers), and that the genome scale vcf file is accompanied by an index.  

I am now turning to annotation tracks: bed, bed9, gff, gff3, gtf.  rtracklayer provides a good set of importers for these formats, and S4 classes to represent them (apparently all are subclasses of GenomicRanges): 
 
   BEDFile (3 required fields, up to 9 optional fields - https://genome.ucsc.edu/FAQ/FAQformat.html#format1)
   GFFFile (includes gff, gff3, gtf)

I propose to support four different representations of these data in R:

   data.frame
   the two rtracklayer classes
   a url pointing to a web-hosted and indexed annotation

The AnnotationTrack constructor accepts all three in the ?annotation? parameter, a simple version of which (with many parameters defaulted) is:

  track <- AnnotationTrack(trackName, annotation, color, displayMode)

The annotation parameter will be inspected by the constructor: is it a data.frame? a BEDFile?  a GFFFile?  a url?

The local data is reformatted as needed into a file with a format igv.js understands - native bed and gff text files - then passed to igv as a local url. Remote urls are transmitted without change.

Does this sound right?  If you have a minute to comment, now is a good time to offer critique and suggestions on annotation tracks.

Next up after the AnnotationTrack class will be alignment (bam) tracks and, if I get to it before package submission data, a ?seg? track for segmented copy number data.

Last week Gabe asked:

If myigv represents the  IGV session/state, then add_track(myigv, vcfobj) could call down to add_track(myigv,VariantTrack(vcf)) so you'd get the default behaviors. you could also support add_track(myigv, vcf, title = "bla", homVarColor = "whateverman") which would call down to add_track(myigv, VariantTrack(vcf, title = "bla", homVarColor = "whateverman?))

This is easy to do (I'm assume the IGVSession class name but replace it with whatever class add_track is endomorphic in...):
  setMethod("add_track", signature = c("IGVSession", "VCF"), function(igv, track, ...) add_track(igv, VariantTrack(track, ...)))
  setMethod("add_track", signature = c("IGVSession", "BAM", function(igv, track, ...) add_track(igv, AlignmentTrack(track, ...)))

This would, as Michael points out, give you the default values of the parameter when you just call add_track(myigv, vcfobj)

I hope I don?t sound disrespectful by describing these shorter methods as only syntactic simplifications with a little S4 dispatch thrown in.    They have value, for sure, but are they not just a relatively thin layer on top of the classes I am writing now?   *If* that description is accurate, then I?d rather consider adding them later, after the nuts and bolts and basic operations are all written, tested, and subjected to a few months of user QC.  I admit that I also prefer the greater operational clarity which for me, with my plodding brain, comes from using by explicit data types and explicit constructors.)  

 - Paul

On Mar 14, 2018, at 1:05 PM, Michael Lawrence <lawrence.michael at gene.com> wrote:

Agreed about encapsulating plot parameters. I was thinking in terms of user convenience, relying on defaults.

On Wed, Mar 14, 2018 at 12:40 PM, Paul Shannon <paul.thurmond.shannon at gmail.com> wrote:
Hi Michael,

Set me straight if I got this wrong.   You suggest:

There should be no need to explicitly construct a track; just rely on dispatch and class semantics, i.e., passing a VCF object to add_track() would create a variant track automatically.

But wouldn?t

   displayTrack(vcf)

preclude any easy specification of options - which vary across track types - which are straightforward, easily managed and checked, by a set of track constructors?

Two examples:

   displayTrack(VariantTrack(vcf, title=?mef2c eqtl?, height=?300?, homrefColor=?lightGray?,
                             homVarColor=?darkRed?, hetVarColor=?lightRed?))

   displayTrack(AlignmentTrack(x, title=?bam 32?, viewAsPairs=TRUE, insertionColor=?black?))


So I suggest that the visualization of tracks has lots of track-type-specific settings which the user will want to control, and which would be messy to handle with an open-ended set of optional ??? args to a dispatch-capable single ?displayTrack? method.

 - Paul