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