[Bioc-devel] chromosome lengths (seqinfo) for supported BSgenome builds into GenomeInfoDb?

[Kasper Daniel Hansen]

Herve,

This sounds great.  I do think it would be highly advantageous to not use
the internet.  For example, you could imagine using this function everytime
a Granges() is created, and it would be useful not to have internet access
for this.

Best,
Kasper

On Thu, Jun 4, 2015 at 7:28 PM, Hervé Pagès <hpages at fredhutch.org> wrote:

> Hi,
>
> FWIW I started to work on supporting quick generation of a standalone
> Seqinfo object via Seqinfo(genome="hg38") in GenomeInfoDb.
>
> It already supports hg38, hg19, hg18, panTro4, panTro3, panTro2,
> bosTau8, bosTau7, bosTau6, canFam3, canFam2, canFam1, musFur1, mm10,
> mm9, mm8, susScr3, susScr2, rn6, rheMac3, rheMac2, galGal4, galGal3,
> gasAcu1, danRer7, apiMel2, dm6, dm3, ce10, ce6, ce4, ce2, sacCer3,
> and sacCer2. I'll add more.
>
> See ?Seqinfo for some examples.
>
> Right now it fetches the information from internet every time you
> call it but maybe we should just store that information in the
> GenomeInfoDb package as Tim suggested?
>
> H.
>
>
> On 06/03/2015 12:54 PM, Tim Triche, Jr. wrote:
>
>> That would be perfect actually.  And it would radically reduce &
>> modularize maintenance.  Maybe that's the best way to go after all.  Quite
>> sensible.
>>
>> --t
>>
>>  On Jun 3, 2015, at 12:46 PM, Vincent Carey <stvjc at channing.harvard.edu>
>>> wrote:
>>>
>>> It really isn't hard to have multiple OrganismDb packages in place -- the
>>> process of making new ones is documented and was given as an exercise in
>>> the EdX course.  I don't know if we want to institutionalize it and
>>> distribute such -- I think we might, so that there would be Hs19, Hs38,
>>> mm9, etc. packages.  They have very little content, they just coordinate
>>> interactions with packages that you'll already have.
>>>
>>> On Wed, Jun 3, 2015 at 3:26 PM, Tim Triche, Jr. <tim.triche at gmail.com>
>>> wrote:
>>>
>>>  Right, I typically do that too, and if you're working on human data it
>>>> isn't a big deal.  What makes things a lot more of a drag is when you
>>>> work
>>>> on e.g. mouse data (mm9 vs mm10, aka GRCm37 vs GRCm38) where
>>>> Mus.musculus
>>>> is essentially a "build ahead" of Homo.sapiens.
>>>>
>>>> R> seqinfo(Homo.sapiens)
>>>> Seqinfo object with 93 sequences (1 circular) from hg19 genome
>>>>
>>>> R> seqinfo(Mus.musculus)
>>>> Seqinfo object with 66 sequences (1 circular) from mm10 genome:
>>>>
>>>> It's not as explicit as directly assigning the seqinfo from a genome
>>>> that
>>>> corresponds to that of your annotations/results/whatever.  I know we
>>>> could
>>>> all use crossmap or liftOver or whatever, but that's not really the
>>>> same,
>>>> and it takes time, whereas assigning the proper seqinfo for
>>>> relationships
>>>> is very fast.
>>>>
>>>> That's all I was getting at...
>>>>
>>>>
>>>> Statistics is the grammar of science.
>>>> Karl Pearson <http://en.wikipedia.org/wiki/The_Grammar_of_Science>
>>>>
>>>> On Wed, Jun 3, 2015 at 12:17 PM, Vincent Carey <
>>>> stvjc at channing.harvard.edu
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>>  I typically get this info from Homo.sapiens.  The result is parasitic
>>>>> on
>>>>> the TxDb that is in there.  I don't know how easy it is to swap
>>>>> alternate
>>>>> TxDb in to get a different build.  I think it would make sense to
>>>>> regard
>>>>> the OrganismDb instances as foundational for this sort of structural
>>>>> data.
>>>>>
>>>>> On Wed, Jun 3, 2015 at 3:12 PM, Kasper Daniel Hansen <
>>>>> kasperdanielhansen at gmail.com> wrote:
>>>>>
>>>>>  Let me rephrase this slightly.  From one POV the purpose of
>>>>>> GenomeInfoDb
>>>>>> is
>>>>>> clean up the seqinfo slot.  Currently it does most of the cleaning,
>>>>>> but
>>>>>> it
>>>>>> does not add seqlengths.
>>>>>>
>>>>>> It is clear that seqlengths depends on the version of the genome, but
>>>>>> I
>>>>>> will argue so does the seqnames.  Of course, for human, chr22 will not
>>>>>> change.  But what about the names of all the random contigs?  Or for
>>>>>> other
>>>>>> organisms, what about going from a draft genome with 10k contigs to a
>>>>>> more
>>>>>> completely genome assembled into fewer, larger chromosomes.
>>>>>>
>>>>>> I acknowledge that this information is present in the BSgenome
>>>>>> packages,
>>>>>> but it seems (to me) to be very appropriate to have them around for
>>>>>> cleaning up the seqinfo slot.  For some situations it is not great to
>>>>>> depend on 1 GB> download for something that is a few bytes.
>>>>>>
>>>>>> Best,
>>>>>> Kasper
>>>>>>
>>>>>> On Wed, Jun 3, 2015 at 3:00 PM, Tim Triche, Jr. <tim.triche at gmail.com
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>>  It would be nice (for a number of reasons) to have chromosome lengths
>>>>>>> readily available in a foundational package like GenomeInfoDb, so
>>>>>>> that,
>>>>>>> say,
>>>>>>>
>>>>>>> data(seqinfo.hg19)
>>>>>>> seqinfo(myResults) <- seqinfo.hg19[ seqlevels(myResults) ]
>>>>>>>
>>>>>>> would work without issues.  Is there any particular reason this
>>>>>>>
>>>>>> couldn't
>>>>>>
>>>>>>> happen for the supported/available BSgenomes?  It would seem like a
>>>>>>>
>>>>>> simple
>>>>>>
>>>>>>> matter to do
>>>>>>>
>>>>>>> R> library(BSgenome.Hsapiens.UCSC.hg19)
>>>>>>> R> seqinfo.hg19 <- seqinfo(Hsapiens)
>>>>>>> R> save(seqinfo.hg19,
>>>>>>> file="~/bioc-devel/GenomeInfoDb/data/seqinfo.hg19.rda")
>>>>>>>
>>>>>>> and be done with it until (say) the next release or next released
>>>>>>> BSgenome.  I considered looping through the following BSgenomes
>>>>>>>
>>>>>> myself...
>>>>>>
>>>>>>> and if it isn't strongly opposed by (everyone) I may still do exactly
>>>>>>> that.  Seems useful, no?
>>>>>>>
>>>>>>> e.g. for the following 42 builds,
>>>>>>>
>>>>>>> grep("(UCSC|NCBI)", unique(gsub(".masked", "", available.genomes())),
>>>>>>> value=TRUE)
>>>>>>> [1] "BSgenome.Amellifera.UCSC.apiMel2"
>>>>>>>
>>>>>> "BSgenome.Btaurus.UCSC.bosTau3"
>>>>>>
>>>>>>>
>>>>>>> [3] "BSgenome.Btaurus.UCSC.bosTau4"
>>>>>>>
>>>>>> "BSgenome.Btaurus.UCSC.bosTau6"
>>>>>>
>>>>>>>
>>>>>>> [5] "BSgenome.Btaurus.UCSC.bosTau8"
>>>>>>> "BSgenome.Celegans.UCSC.ce10"
>>>>>>>
>>>>>>> [7] "BSgenome.Celegans.UCSC.ce2"         "BSgenome.Celegans.UCSC.ce6"
>>>>>>>
>>>>>>> [9] "BSgenome.Cfamiliaris.UCSC.canFam2"
>>>>>>> "BSgenome.Cfamiliaris.UCSC.canFam3"
>>>>>>> [11] "BSgenome.Dmelanogaster.UCSC.dm2"
>>>>>>> "BSgenome.Dmelanogaster.UCSC.dm3"
>>>>>>> [13] "BSgenome.Dmelanogaster.UCSC.dm6"
>>>>>>>
>>>>>> "BSgenome.Drerio.UCSC.danRer5"
>>>>>>
>>>>>>>
>>>>>>> [15] "BSgenome.Drerio.UCSC.danRer6"
>>>>>>>
>>>>>> "BSgenome.Drerio.UCSC.danRer7"
>>>>>>
>>>>>>>
>>>>>>> [17] "BSgenome.Ecoli.NCBI.20080805"
>>>>>>> "BSgenome.Gaculeatus.UCSC.gasAcu1"
>>>>>>> [19] "BSgenome.Ggallus.UCSC.galGal3"
>>>>>>>
>>>>>> "BSgenome.Ggallus.UCSC.galGal4"
>>>>>>
>>>>>>>
>>>>>>> [21] "BSgenome.Hsapiens.NCBI.GRCh38"
>>>>>>> "BSgenome.Hsapiens.UCSC.hg17"
>>>>>>>
>>>>>>> [23] "BSgenome.Hsapiens.UCSC.hg18"
>>>>>>> "BSgenome.Hsapiens.UCSC.hg19"
>>>>>>>
>>>>>>> [25] "BSgenome.Hsapiens.UCSC.hg38"
>>>>>>> "BSgenome.Mfascicularis.NCBI.5.0"
>>>>>>> [27] "BSgenome.Mfuro.UCSC.musFur1"
>>>>>>>
>>>>>> "BSgenome.Mmulatta.UCSC.rheMac2"
>>>>>>
>>>>>>>
>>>>>>> [29] "BSgenome.Mmulatta.UCSC.rheMac3"
>>>>>>>
>>>>>> "BSgenome.Mmusculus.UCSC.mm10"
>>>>>>
>>>>>>>
>>>>>>> [31] "BSgenome.Mmusculus.UCSC.mm8"
>>>>>>> "BSgenome.Mmusculus.UCSC.mm9"
>>>>>>>
>>>>>>> [33] "BSgenome.Ptroglodytes.UCSC.panTro2"
>>>>>>> "BSgenome.Ptroglodytes.UCSC.panTro3"
>>>>>>> [35] "BSgenome.Rnorvegicus.UCSC.rn4"
>>>>>>>
>>>>>> "BSgenome.Rnorvegicus.UCSC.rn5"
>>>>>>
>>>>>>>
>>>>>>> [37] "BSgenome.Rnorvegicus.UCSC.rn6"
>>>>>>> "BSgenome.Scerevisiae.UCSC.sacCer1"
>>>>>>> [39] "BSgenome.Scerevisiae.UCSC.sacCer2"
>>>>>>> "BSgenome.Scerevisiae.UCSC.sacCer3"
>>>>>>> [41] "BSgenome.Sscrofa.UCSC.susScr3"
>>>>>>>
>>>>>> "BSgenome.Tguttata.UCSC.taeGut1"
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am I insane for suggesting this?  It would make things a little
>>>>>>> easier
>>>>>>>
>>>>>> for
>>>>>>
>>>>>>> rtracklayer, most SummarizedExperiment and SE-derived objects, blah,
>>>>>>>
>>>>>> blah,
>>>>>>
>>>>>>> blah...
>>>>>>>
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> --t
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Statistics is the grammar of science.
>>>>>>> Karl Pearson <http://en.wikipedia.org/wiki/The_Grammar_of_Science>
>>>>>>>
>>>>>>
>>>>>>         [[alternative HTML version deleted]]
>>>>>>
>>>>>> _______________________________________________
>>>>>> Bioc-devel at r-project.org mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>>>
>>>>>
>>>     [[alternative HTML version deleted]]
>>>
>>> _______________________________________________
>>> Bioc-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>> _______________________________________________
>> Bioc-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpages at fredhutch.org
> Phone:  (206) 667-5791
> Fax:    (206) 667-1319
>
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

	[[alternative HTML version deleted]]