I will look into updating gene.pm and see if that works. Ideally, I
> Hi Prachi,
>
> My suggestion is to simplify your track definition and remove perl
> callbacks until you get it working minimally. Additionally, this
> paragraph comes from the description of the gene glyph:
>
> This glyph is designed to work properly with GFF3-style three-tier
> genes, in which the top level feature has the Sequence Ontology type
> of "gene", the second level feature(s) have the SO type "mRNA", and
> the third level feature(s) have the SO type "CDS", "five_prime_utr"
> and "three_prime_utr." Subparts named "UTR" are also honored. The
> feature can contain other subparts as well (e.g. exon, intron,
> translation), but they are currently ignored unless the option
> sub_part is supplied. If the sub_part option is used that feature
> type will be used and CDS and UTR features will be excluded.
> This could be used for specifying that exons be used instead,
> for example.
>
> So, it looks like you need to provide mRNA features as the transcript,
> not "transcript" features. Looking at the code for gene.pm though, I
> find this subroutine:
>
> sub _subfeat {
> my $class = shift;
> my $feature = shift;
>
> if ($feature->primary_tag =~ /^gene/i) {
> my @transcripts;
> for my $t (qw/mRNA tRNA snRNA snoRNA miRNA ncRNA pseudogene/) {
> push @transcripts, $feature->get_SeqFeatures($t);
> }
> return @transcripts if @transcripts;
> return $feature->get_SeqFeatures; # no transcripts?! return
> whatever's there
> }
> elsif ($feature->primary_tag =~ /^CDS/i) {
> my @parts = $feature->get_SeqFeatures();
> return ($feature) if $class->{level} == 0 and !@parts;
> return @parts;
> }
>
> As a pure guess (since I haven't spent any time trying to understand
> this glyph in detail), I think you could add "transcript" to the list
> of transcript types in this method and it might work. If you try that
> and it does work, let me know and I'll add it to the Bio::Graphics
> code.
>
> Scott
>
>
> On Tue, Oct 20, 2009 at 2:55 PM, Prachi Shah <
prachi@...> wrote:
>> Hi Scott,
>>
>> I was using Bio::DB::GFF. Based on your suggestion yesterday, I migrated to
>> Bio::DB::SeqFeature::Store. There I ran into a few issuesdue to the
>> differences between the two adaptors which took some time to sort out. Now,
>> I have loaded my GFF3 file to mysql database using bp_seqfeature_load.pl and
>> that went well. I updated my configuration file to accomodate the difference
>> between the two adaptors. I can now see that the tracks on GBrowse show up
>> and the label/descriptions for individual features also show up but I am
>> still missing a glyph.
>>
>> I am attaching a screenshot of what I see on GBrowse display and below is
>> the track section in my configuration file:
>> [Genes]
>> feature = gene
>> glyph = gene
>> sub_part = exon
>> strand_arrow = 1
>> linewidth = 1
>> height = 6
>> description = \&feat_desc
>> key = Protein-coding Genes
>> font2color = blue
>> fgcolor = black
>> bgcolor = \&orf_color
>> citation = Protein coding genes.
>> label = \&feat_label
>>
>> What am I doing wrong now? There is nothing in the error_logs.
>>
>> Thanks for all your help.
>> Prachi
>>
>>
>> On Mon, Oct 19, 2009 at 11:49 AM, Scott Cain <
scott@...> wrote:
>>>
>>> Hi Prachi,
>>>
>>> Yes, aggregators were developed to "fix" older GFF where explicit
>>> relationships between features where not present. With GFF3, you
>>> don't need aggregators any more.
>>>
>>> What database schema are you using for your data? Bio::DB::GFF or
>>> Bio::DB::SeqFeature::Store (or something else)? If you are using
>>> Bio::DB::GFF, you may have problems since it doesn't support three
>>> levels of parent-child relationships (and thus it has no way of
>>> telling that the genes are related to their exons). If you are using
>>> Bio::DB::SeqFeature::Store, I don't see anything wrong with that track
>>> config, but make sure that you remove the aggregators line from the
>>> conf file, as it sticking around could cause problems.
>>>
>>> When you say it doesn't work, what does that mean/what do you see? Is
>>> there anything in the error log that might shed light on what is
>>> happening?
>>>
>>> Scott
>>>
>>>
>>> On Mon, Oct 19, 2009 at 2:35 PM, Prachi Shah <
prachi@...> wrote:
>>> > Hi Scott,
>>> >
>>> > Yes, I use GFF3 with the ID and Parent tags. Please see the sample data:
>>> > A_fumigatus_chr3 Broad exon 4010522 4014912 . + .
>>> > ID=7000000475797329;Parent=7000000475797328
>>> > A_fumigatus_chr3 Broad exon 4014967 4017637 . + .
>>> > ID=7000000475797330;Parent=7000000475797328
>>> > A_fumigatus_chr3 Broad transcript 4010522 4017637 . + .
>>> > ID=7000000475797328;Parent=7000000475797327
>>> > A_fumigatus_chr3 Broad CDS 4010522 4017637 . + 0
>>> > ID=Afu3g15270;Parent=7000000475797328
>>> > A_fumigatus_chr3 Broad gene 4010522 4017637 . + .
>>> > ID=7000000475797327;Name=nonribosomal peptide synthase (NRPS)%2c
>>> > putative;locus=Afu3g15270
>>> >
>>> >
>>> > The ancestral arrangement is like this:
>>> > gene -------> transcript ---------> exon1
>>> > |--------> exon2
>>> > |--------> CDS
>>> >
>>> > So, are you saying the parental relationships (defined by the ID and
>>> > Parent tags) supersedes aggregators ?
>>> >
>>> > I tried the "gene" glyph but that doesn't seem to work either. Below
>>> > is the track configuration section. Are any of these setting wrong for
>>> > the "gene" glyph?
>>> >
>>> > [Genes]
>>> > feature = gene
>>> > glyph = gene
>>> > sub_part = exon
>>> > strand_arrow = 1
>>> > linewidth = 1
>>> > height = 6
>>> > description = \&feat_desc
>>> > key = Protein-coding Genes
>>> > font2color = blue
>>> > fgcolor = black
>>> > bgcolor = \&orf_color
>>> > citation = Protein coding genes.
>>> > label = \&feat_label
>>> >
>>> > Thanks for your help.
>>> > Prachi
>>> >
>>> > On Mon, Oct 19, 2009 at 10:38 AM, Scott Cain <
scott@...>
>>> > wrote:
>>> >> Hi Prachi,
>>> >>
>>> >> Since you are using the phrase "direct parent", am I to assume that
>>> >> you are using GFF3 with ID and Parent tags? If so, you can't reliably
>>> >> use aggregators at all. I would suggest the gene glyph in that case.
>>> >>
>>> >> Scott
>>> >>
>>> >>
>>> >> On Mon, Oct 19, 2009 at 12:48 PM, Prachi Shah <
prachi@...>
>>> >> wrote:
>>> >>> Hi Scott,
>>> >>>
>>> >>> Thanks for your quick response. Really appreciate it!
>>> >>>
>>> >>> The transcript glyph does not work either. Actually, when I take out
>>> >>> the primary method from my aggregator definition, the glyph
>>> >>> (processed_transcript and transcript) shows up well, but I cannot
>>> >>> access the attributes for label and description. So, the following
>>> >>> aggregrator works well for glyph display:
>>> >>> aggregators = group{exon}
>>> >>>
>>> >>> but not this does not:
>>> >>> aggregators = group{exon/gene}
>>> >>>
>>> >>>
>>> >>> Could this be because the "gene" feature is not a direct parent of
>>> >>> "exon"?
>>> >>>
>>> >>> Thanks,
>>> >>> Prachi
>>> >>>
>>> >>>
>>> >>> P.S. I have successfully used the primary_transcript glyph for
>>> >>> sub-features other than CDS and UTRs, such as, noncoding_exons.
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Mon, Oct 19, 2009 at 9:34 AM, Scott Cain <
scott@...>
>>> >>> wrote:
>>> >>>> Hi Prachi,
>>> >>>>
>>> >>>> The processed_transcript glyph is designed to use with the
>>> >>>> processed_transcript aggregator, which has an mRNA as a parent and
>>> >>>> CDS and
>>> >>>> UTRs as children, but not exons. Try the transcript glyph instead,
>>> >>>> as it is
>>> >>>> designed to use with exons (it wants a transcript feature as the
>>> >>>> parent, but
>>> >>>> it may not matter). Failing that, use the segments glyph. For more
>>> >>>> info on
>>> >>>> the built in aggregators, see the tutorial:
>>> >>>>
>>> >>>>
http://gmod.org/gbrowse-cgi/tutorial/dbgff/tutorial.html#aggregators>>> >>>>
>>> >>>> Scott
>>> >>>>
>>> >>>>
>>> >>>> On Oct 19, 2009, at 12:29 PM, Prachi Shah wrote:
>>> >>>>
>>> >>>>> Hi all,
>>> >>>>>
>>> >>>>> I am trying to setup GBrowse for gene features with the following
>>> >>>>> relationship:
>>> >>>>> gene -----parent of----> transcript ------parent of------> exon(s)
>>> >>>>>
>>> >>>>> and I would like this to show up as a processed_transcript glyph
>>> >>>>> with the
>>> >>>>> exons connected together. I tried constructing an aggregator with
>>> >>>>> the
>>> >>>>> following definition:
>>> >>>>> aggregators = group{exon/gene}
>>> >>>>>
>>> >>>>> I have the "gene" feature as the primary method because I want to
>>> >>>>> access
>>> >>>>> the Name and locus attributes (see sample data below).
>>> >>>>>
>>> >>>>> With this setup the track label and description show up alright but
>>> >>>>> the
>>> >>>>> glyph does not. Any ideas / comments as what I may be doing wrong?
>>> >>>>> Thanks in
>>> >>>>> advance for all the help.
>>> >>>>>
>>> >>>>> Thanks,
>>> >>>>> Prachi
>>> >>>>>
>>> >>>>> --------------------------
>>> >>>>>
>>> >>>>> Here's the track section from the configuration file:
>>> >>>>> [Genes]
>>> >>>>> feature = group
>>> >>>>> glyph = processed_transcript
>>> >>>>> strand_arrow = 1
>>> >>>>> linewidth = 1
>>> >>>>> height = 6
>>> >>>>> description = sub {
>>> >>>>> my $f = shift;
>>> >>>>> return $f->attributes('Name'); }
>>> >>>>> label = sub {
>>> >>>>> my $f = shift;
>>> >>>>> return $f->attributes('locus'); }
>>> >>>>>
>>> >>>>>
>>> >>>>> Here's a sample set of data:
>>> >>>>> A_fumigatus_chr3 Broad exon 4010522 4014912 . + .
>>> >>>>> ID=7000000475797329;Parent=7000000475797328
>>> >>>>> A_fumigatus_chr3 Broad exon 4014967 4017637 . + .
>>> >>>>> ID=7000000475797330;Parent=7000000475797328
>>> >>>>> A_fumigatus_chr3 Broad transcript 4010522 4017637 . + .
>>> >>>>> ID=7000000475797328;Parent=7000000475797327
>>> >>>>> A_fumigatus_chr3 Broad CDS 4010522 4017637 . + 0
>>> >>>>> ID=Afu3g15270;Parent=7000000475797328
>>> >>>>> A_fumigatus_chr3 Broad gene 4010522 4017637 . + .
>>> >>>>> ID=7000000475797327;Name=nonribosomal peptide synthase (NRPS)%2c
>>> >>>>> putative;locus=Afu3g15270
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> ------------------------------------------------------------------------------
>>> >>>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> >>>>> is the only developer event you need to attend this year. Jumpstart
>>> >>>>> your
>>> >>>>> developing skills, take BlackBerry mobile applications to market and
>>> >>>>> stay
>>> >>>>> ahead of the curve. Join us from November 9 - 12, 2009. Register
>>> >>>>> now!
>>> >>>>>
>>> >>>>>
>>> >>>>>
http://p.sf.net/sfu/devconference_______________________________________________>>> >>>>> Gmod-gbrowse mailing list
>>> >>>>>
Gmod-gbrowse@...
>>> >>>>>
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse>>> >>>>
>>> >>>>
>>> >>>> -----------------------------------------------------------------------
>>> >>>> Scott Cain, Ph. D. scott at scottcain dot net
>>> >>>> GMOD Coordinator (
http://gmod.org/) 216-392-3087
>>> >>>> Ontario Institute for Cancer Research
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> ------------------------------------------------------------------------
>>> >> Scott Cain, Ph. D. scott at scottcain
>>> >> dot net
>>> >> GMOD Coordinator (
http://gmod.org/) 216-392-3087
>>> >> Ontario Institute for Cancer Research
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> ------------------------------------------------------------------------
>>> Scott Cain, Ph. D. scott at scottcain
>>> dot net
>>> GMOD Coordinator (
http://gmod.org/) 216-392-3087
>>> Ontario Institute for Cancer Research
>>
>>
>
>
>
> --
> ------------------------------------------------------------------------
> Scott Cain, Ph. D. scott at scottcain dot net
> GMOD Coordinator (
http://gmod.org/) 216-392-3087
> Ontario Institute for Cancer Research
>
is the only developer event you need to attend this year. Jumpstart your
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
gbrowse_screenshot.svg (59K) 