On 01/08/2016 01:09 PM, Michael Lawrence wrote:
That is one solution. But everyone using that genome would need to
reset the seqlevels to the "standard" ones. In this specific case, is
there any reason not to just use the BSgenome for GRCh38?
I agree. Maybe we don't need seqlevels<-,TwoBitFile
That is one solution. But everyone using that genome would need to
reset the seqlevels to the "standard" ones. In this specific case, is
there any reason not to just use the BSgenome for GRCh38?
On Fri, Jan 8, 2016 at 11:04 AM, Hervé Pagès wrote:
> Hi Jo, Michael,
>
> What about implementing a se
Hi Jo, Michael,
What about implementing a seqlevels() setter for TwoBitFile objects? All
you need for this is an extra slot for storing the user-supplied
seqlevels. Note that in general the seqlevels() setter allows more than
renaming the seqlevels. It also allows dropping, adding, and shuffling
I agree, I would not modify the file content. At present it is however not
possible to use e.g. getSeq on these TwoBitFiles, since the chromosome names in
the submitted GRanges (e.g. 1) do not match the seqnames/seqinfo of the
TwoBitFile. I don’t know if a seqnames or seqinfo method stripping of
This is perhaps something that could be handled when population the
hub, but I'm not sure how rtracklayer could automatically derive the
chromosome names.
On Fri, Jan 8, 2016 at 2:37 AM, Rainer Johannes
wrote:
> dear all,
>
> I just run into a problem with a TwoBitFile I fetched from AnnotationHu
dear all,
I just run into a problem with a TwoBitFile I fetched from AnnotationHub. I was
fetching a TwoBitFile with the genomic DNA sequence, as provided by Ensembl:
> library(AnnotationHub)
> ah <- AnnotationHub()
> tbf <- ah[["AH50068”]]
> head(seqnames(seqinfo(tbf)))
[1] "1 dna:chromosome c