On Sun, Dec 2, 2012 at 3:43 PM, Tim Triche, Jr. <tim.triche@gmail.com>wrote:

> So, a trackHub as spec'd by UCSC ends up being a DAG.  It may not be
> strictly directed, even; I'm pondering that.  The file under a hub's root
> is title genomesall.txt and tells what trackDb is associated with a genome.
>  Loading the corresponding trackDb file provides a bunch of information
> about the available data tracks for the hub, in a plain-text tab-delimited
> format sort of like MAGE-tab or what have you.  Or perhaps more like Python
> code (spaces seem to matter).  Whatever.
>
> The single (only?) most important bit of a trackHub's information is the
> bigDataUrl, but not entirely unimportant is the track name (duh), the
> parent track (which is where I'm going next) and the shortLabel/longLabel
> fields.  The 'type' field is also handy since it usually indicates whether
> something is a bigWig, bigBed, BAM, or (something else) file.
>
> More questions:
>
> 1) try to store a trackHub's structure as a graph?  It's enticing but I'm
> not sure how much I care, really I just want the data.
>

Probably not as a general graph. A simple tree of objects should suffice.


> 2) is this already done inside rtracklayer such that I can cannibalize
> existing code?  I've only just started looking around.
>
>
You might check out the Quickload support (from the IGB project). It is
very similar in structure and spirit to the UCSC track hub stuff.

As far as bigBed, it's certainly possible, but it would require bringing
quite a bit more of the Kent library into rtracklayer and writing the
necessary wrappers. BigBED is more complicated than bigWig. For my use
cases, using tabix on top of a BED has been sufficient. UCSC-specific stuff
is probably all one will find only in bigBed.

Thanks a lot for looking into this,
Michael


Thanks again,
>
> --t
>
>
>
>
> On Sun, Dec 2, 2012 at 3:23 PM, Tim Triche, Jr. <tim.triche@gmail.com
> >wrote:
>
> > I'm looking through the rtracklayer directory in SVN, specifically src,
> > and finding common files shared between bigWig and bigBed.  It looks like
> > bigBed isn't supported yet, however, so I'm thinking of hacking up bigWig
> > to do something similar.  How close is/was bigBed support, and if anyone
> > was/is working on it, are there any things I should look out for in order
> > to save some time?
> >
> > The trackHub I'm most interested in using stores their bigData as bigBed,
> > and at the moment it seems that import()'ing a bigBed isn't going to
> > happen, so if I can take advantage of remote access, so much the better.
> >
> > Thanks in advance,
> >
> > --t
> >
> >
> >
> > --
> > *A model is a lie that helps you see the truth.*
> > *
> > *
> > Howard Skipper<
> http://cancerres.aacrjournals.org/content/31/9/1173.full.pdf>
> >
> >
>
>
> --
> *A model is a lie that helps you see the truth.*
> *
> *
> Howard Skipper<
> http://cancerres.aacrjournals.org/content/31/9/1173.full.pdf>
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

	[[alternative HTML version deleted]]

