The strand metadata constraint is introduced by the intermediate
GRangesList representation on which coverage is actually calculated.
Perhaps we should be consistent and disallow the use of fixed column names
in the metadata of GAlignments, as well. I'm kind of surprised that
readGAlignments does not just drop the request for what="strand", since it
includes it as a fixed column anyway.


On Thu, Feb 27, 2014 at 11:00 PM, chris warth <cswarth@gmail.com> wrote:

> > GenomicAlignments is mostly a reorganization of pre-existing
> functionality.
> > You should be able to call coverage() directly on your GAlignments, or on
> > the BamFile itself, with full support for cigar strings. Also, it is
> > sufficient to call readGAlignments(), i.e., no need for "FromBam".
> >
>
> Thanks for this, I tried calling coverage() on GAlignments before and
> it wouldn't work for me, but looking closer I now understand the
> error.
>
>  > class(myalignments)
>  [1] "GAlignments"
>  attr(,"package")
>  [1] "GenomicRanges"
>
>  > coverage(myalignments)
>  Error in coverage(grglist(x, drop.D.ranges = drop.D.ranges), shift =
> shift,  :
>   error in evaluating the argument 'x' in selecting a method for
> function  'coverage': Error in validObject(.Object) :
>   invalid class "GRangesList" object: 'mcols(x)' cannot have columns
> named  "seqnames",  "ranges", "strand", "start", "end", "width",  or
> "element"
>
>
> Eliminating the metadata (what = c("pos", "qwidth", "strand")) in the
> alignments allows coverage() to work now.
>
> Why in the world does coverage() care if the alignments have strand
> metadata?
>

	[[alternative HTML version deleted]]

