That's awesome. You should have made a special announcement!

Sorry for hijacking the thread,
Michael




On Tue, Apr 30, 2013 at 3:18 PM, Marc Carlson <mcarl...@fhcrc.org> wrote:

>  Hi Michael,
>
> Yes.
>
> library(Homo.sapiens)
> cols(Homo.sapiens)
> txs <- transcripts(Homo.sapiens, columns=c("SYMBOL"))
>
> exs <- exons(Homo.sapiens, columns=c("SYMBOL"))
>
>
>   Marc
>
>
>
> On 04/30/2013 03:07 PM, Michael Lawrence wrote:
>
>  Hi Marc,
>
> Do you know if it is easy yet to get the gene symbols returned as a result
> of e.g. a transcripts() or exons() call?
>
>  Michael
>
>
> On Tue, Apr 30, 2013 at 2:16 PM, Marc Carlson <mcarl...@fhcrc.org> wrote:
>
>> Related to this:
>>
>> I have added getters for seqinfo (and friends) for the OrganismDb
>> objects.  I have not added the setters yet though since that requires some
>> refactoring of what an OrganismDb object actually is internally.  But I
>> intend to do this also.
>>
>>   Marc
>>
>>
>>
>>
>> On 04/25/2013 09:32 AM, Valerie Obenchain wrote:
>>
>>> Hi Vince, Kasper,
>>>
>>> cc'ing Herve and Marc.
>>>
>>> I think we have a couple of things going on so I wanted to clarify. The
>>> 'genome' argument to readVcf() is assigned to the GRanges in rowData with
>>> the "genome<-" setter. This is where .normargGenome() gets called.
>>>
>>> setReplaceMethod("genome", "Seqinfo",
>>>     function(x, value)
>>>     {
>>>         x@genome <- .normargGenome(value, seqnames(x))
>>>         x
>>>     }
>>> )
>>>
>>> If the 'genome' replacement value is named, the name(s) must match the
>>> seqnames, not the build. So we aren't talking about matching compatible
>>> builds,
>>>
>>> fl <- system.file("extdata", "ex2.vcf", package="VariantAnnotation")
>>> vcf <- readVcf(fl, c("b37"="hg19"))  ## this is wrong
>>> vcf <- readVcf(fl, c("hg19"="hg19")) ## also wrong
>>>
>>> Instead the name must be the seqname, the value is the build,
>>>
>>> vcf <- readVcf(fl, c("20"="hg19"))  ## correct
>>> vcf <- readVcf(fl, "hg19")  ## also correct
>>>
>>> This requirement for 'genome' is not well documented on ?readVcf or
>>> ?Seqinfo. We can fix that.
>>>
>>> The second thing is the issue of a flexible mapping between seqinfo
>>> metadata for different institutions. Herve and Marc have worked on this in
>>> AnnotationDbi. They can explain more about the 'SeqnameStyle' and how it
>>> might be used more widely.
>>>
>>>
>>> Val
>>>
>>>
>>> On 04/25/2013 06:54 AM, Kasper Daniel Hansen wrote:
>>>
>>>> An "official" comment on this
>>>>    http://genome.ucsc.edu/cgi-bin/hgGateway?db=hg19
>>>> with some more info in this discussion
>>>>
>>>>
>>>> https://groups.google.com/a/soe.ucsc.edu/forum/?fromgroups=#!topic/genome/hFp-dGG9gBs
>>>>
>>>> Essentially it seems the b37 has been "patched" and this patched
>>>> release is
>>>> not reflected in hg19 but may be (I don't know) reflected in the b37
>>>> download from NCBI
>>>>
>>>> Kasper
>>>>
>>>>
>>>> On Thu, Apr 25, 2013 at 9:49 AM, Kasper Daniel Hansen <
>>>> kasperdanielhan...@gmail.com> wrote:
>>>>
>>>>  I agree with Vincent.  I have seen code from Herve in a package with
>>>>> some
>>>>> standardization of chromosome names, and this code could perhaps be
>>>>> used
>>>>> more widely so we don't have all the problems with chr1 vs chr01 vs 1.
>>>>>
>>>>> However, in this particular case, if Ulrich is actually interested in
>>>>> the
>>>>> mitochondrial genome, he has a problem.
>>>>>
>>>>> hg19, which is the genome version from UCSC is consider equal to NCBIs
>>>>> b37.  However, as far as I understand, UCSC screwed up with the
>>>>> mitochondrial genome and used an old version for their hg19. So the
>>>>> error
>>>>> message is in many ways right here: the two genomes are slightly
>>>>> different
>>>>> because they have different mitochondrial genomes.
>>>>>
>>>>> Kasper
>>>>>
>>>>>
>>>>     [[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
>>
>
>
>

        [[alternative HTML version deleted]]

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

Reply via email to