[Bioperl-l] SearchIO to GFF (was: Getting'features'fromSearchIO?)

Chris Fields cjfields at illinois.edu
Thu May 14 14:14:54 UTC 2009


Go for it (as long as it passes regression tests).

chris

On May 14, 2009, at 9:07 AM, Mark A. Jensen wrote:

> I'll patch in the fix with a cluck that these are undefined, just  
> so's it doesn't slip
> through Bioperl's fingers (if no objections in the next 10min).
> ----- Original Message ----- From: "Jason Stajich" <jason at bioperl.org>
> To: "Mark A. Jensen" <maj at fortinbras.us>; "Dan Bolser" <dan.bolser at gmail.com 
> >
> Cc: "Chris Fields" <cjfields at illinois.edu>; "BioPerl List" <bioperl-l at lists.open-bio.org 
> >
> Sent: Wednesday, May 13, 2009 2:34 AM
> Subject: Re: [Bioperl-l] SearchIO to GFF (was:  
> Getting'features'fromSearchIO?)
>
>
>> Not looking at the code so I can't be sure, but I think since there  
>> is  no sequence in the blasttable format and I think %cons or %id  
>> is  calculated from some of the numbers that are taken from  
>> underlying  sequence data in the alignment.  I don't know why that  
>> would trip up  tile_hsps necessarily but maybe that's not where the  
>> errors are coming  from.
>>
>> I've generally solved these conversions with simpler perl scripts   
>> rather than searchio since I usually want speed for this kind of  
>> stuff  -- so I convert all the data into blast m9 format   
>> (FASTA,SSEARCH,WUBLAST, BLAST) and then have a simple parser that   
>> converts the m9 (without searchio) into the appropriate GFF with  
>> or  without additional bells and whistles.
>>
>> Dan ---
>> I am slowly cleaning up and migrating more of the pipelines that  
>> we  use to generate polished GFF for loading into Gbrowse.  You  
>> should  just set a goal of making good GFF3 and many of the  
>> visualization and  query issues go away.
>>
>> For genomes I tend to have a separate scaffold file which is just  
>> the  1 line per chromosome/scaffold/contig listing.
>> Then a file for each analysis ie. Protein to genome BLAST, EST to   
>> genome, remapped Pfam domains to genome coordinates, gene  
>> predictions,  etc. Keep it simple at first you know what you've  
>> updated when  something stops working the way you expect.
>>
>> -jason
>> On May 12, 2009, at 7:00 PM, Mark A. Jensen wrote:
>>
>>> I dislike my patch, because it doesn't get to the bottom of why
>>> data members associated with numbers of conserved sites return
>>> from eval's undefined; it seems clear from the code that this is
>>> unexpected. Please excuse my naivete--why would this happen
>>> only in the blasttable format, and why hasn't this thing clucked   
>>> before?
>>> ----- Original Message -----
>>> From: Jason Stajich
>>> To: Mark A. Jensen
>>> Cc: Chris Fields ; BioPerl List ; Dan Bolser
>>> Sent: Tuesday, May 12, 2009 7:07 PM
>>> Subject: Re: [Bioperl-l] SearchIO to GFF (was: Getting  
>>> 'features'fromSearchIO?)
>>>
>>>
>>> I really don't think tile_hsps should be used on BLAST data  
>>> folks,  it is a pretty blind approach.
>>> If you really want the right answer you need to do -links with WU-  
>>> BLAST  or FASTA.
>>> Been discussed a few times on the mailing list.
>>>
>>>
>>> Good to fix the code bug I guess to avoid the warnings, but  
>>> unless  you are going to walk through all the HSPs and extract  
>>> the  consistent paths wrt query I think you'll have loops, etc in  
>>> there  which will make Hit->percent_id non-accurate.
>>>
>>>
>>> -jason
>>>
>>>
>>> On May 12, 2009, at 1:06 PM, Mark A. Jensen wrote:
>>>
>>>
>>>   Patch below (to SearchUtils.pm) fixes the non-numeric warnings  
>>> on  Dan's data, but something deeper may be going on.
>>>   Also get many of the following warnings, haven't looked at it   
>>> closely:
>>>
>>>   --------------------- WARNING ---------------------
>>>   MSG: Removing score value(s)
>>>   ---------------------------------------------------
>>>
>>>   PATCH:
>>>
>>>   Index: SearchUtils.pm
>>>    
>>> ===================================================================
>>>   --- SearchUtils.pm (revision 15674)
>>>   +++ SearchUtils.pm (working copy)
>>>   @@ -252,8 +252,8 @@
>>>          }
>>>
>>>          $qctg_dat{ "$frame$strand" }->{'length_aln_query'} += $_-
>>> >{'stop'} - $_->{'start'} + 1;
>>>   -        $qctg_dat{ "$frame$strand" }->{'totalIdentical'}   += $_-
>>> >{'iden'};
>>>   -        $qctg_dat{ "$frame$strand" }->{'totalConserved'}   += $_-
>>> >{'cons'};
>>>   +        $qctg_dat{ "$frame$strand" }->{'totalIdentical'}   += $_-
>>> >{'iden'} || 0;
>>>   +        $qctg_dat{ "$frame$strand" }->{'totalConserved'}   += $_-
>>> >{'cons'} || 0;
>>>          $qctg_dat{ "$frame$strand" }->{'qstrand'}   = $strand;
>>>      }
>>>
>>>   @@ -407,9 +407,12 @@
>>>              };
>>>              if($@) { warn "\a\n$@\n"; }
>>>              else {
>>>   +  # make sure numerical
>>>   +  $_->{'iden'} ||= 0;
>>>   +  $_->{'cons'} ||= 0;
>>>                  $_->{'start'} = $start; # Assign a new start   
>>> coordinate to the contig
>>>   -                $_->{'iden'} += $numID; # and add new data to  
>>> #identical, #conserved.
>>>   -                $_->{'cons'} += $numCons;
>>>   +                $_->{'iden'} += ($numID||0); # and add new  
>>> data  to #identical, #conserved.
>>>   +                $_->{'cons'} += ($numCons||0);
>>>                  push(@{$_->{hsps}}, $hsp);
>>>                  $overlap     = 1;
>>>              }
>>>   @@ -424,9 +427,13 @@
>>>              };
>>>              if($@) { warn "\a\n$@\n"; }
>>>              else {
>>>   +  # make sure numerical
>>>   +  $_->{'iden'} ||= 0;
>>>   +  $_->{'cons'} ||= 0;
>>>   +
>>>                  $_->{'stop'}  = $stop; # Assign a new stop   
>>> coordinate to the contig
>>>   -                $_->{'iden'} += $numID; # and add new data to  
>>> #identical, #conserved.
>>>   -                $_->{'cons'} += $numCons;
>>>   +                $_->{'iden'} += ($numID||0); # and add new  
>>> data  to #identical, #conserved.
>>>   +                $_->{'cons'} += ($numCons||0);
>>>                  push(@{$_->{hsps}}, $hsp);
>>>                  $overlap    = 1;
>>>              }
>>>   @@ -461,8 +468,8 @@
>>>                          };
>>>                          if($@) { warn "\a\n$@\n"; }
>>>                          else {
>>>   -                            $ids  += $these_ids;
>>>   -                            $cons += $these_cons;
>>>   +                            $ids  += ($these_ids||0);
>>>   +                            $cons += ($these_cons||0);
>>>                          }
>>>
>>>                          last if $hsp_start == $u_start;
>>>   @@ -490,8 +497,8 @@
>>>                          };
>>>                          if($@) { warn "\a\n$@\n"; }
>>>                          else {
>>>   -                            $ids  += $these_ids;
>>>   -                            $cons += $these_cons;
>>>   +                            $ids  += ($these_ids||0);
>>>   +                            $cons += ($these_cons||0);
>>>                          }
>>>
>>>                          last if $hsp_end == $u_stop;
>>>
>>>   ----- Original Message ----- From: "Chris Fields" <cjfields at illinois.edu
>>> >
>>>   To: "Mark A. Jensen" <maj at fortinbras.us>
>>>   Cc: "BioPerl List" <bioperl-l at lists.open-bio.org>; "Dan Bolser" <dan.bolser at gmail.com
>>> >
>>>   Sent: Tuesday, May 12, 2009 10:04 AM
>>>   Subject: Re: [Bioperl-l] SearchIO to GFF (was: Getting  
>>> 'features'fromSearchIO?)
>>>
>>>
>>>
>>>     More complicated than that, I'm afraid.  We should try to fix   
>>> that at the source of the problem.
>>>
>>>
>>>
>>>     This appears to stem from SearchUtils HSP tiling, which in   
>>> turn utilizes HSPI::matches(), which in turn checks  
>>> num_identical/  num_conserved. My guess is, since this is  
>>> blasttable format, one  of  these isn't set and thus is returning  
>>> the wrong value.  I'll  attempt  to track it down today, but it  
>>> may take some time.
>>>
>>>
>>>
>>>     chris
>>>
>>>
>>>
>>>     On May 12, 2009, at 8:29 AM, Mark A. Jensen wrote:
>>>
>>>
>>>
>>>       This sounds like a
>>>
>>>
>>>
>>>       $sum = eval join( '+', @a);
>>>
>>>
>>>
>>>       problem, which can be fixed with
>>>
>>>
>>>
>>>       $sum = eval join('+', map { $_ || () } @a) ;
>>>
>>>
>>>
>>>       MAJ
>>>
>>>       ----- Original Message ----- From: "Dan Bolser" <dan.bolser at gmail.com
>>> >
>>>
>>>       To: "Chris Fields" <cjfields at illinois.edu>
>>>
>>>       Cc: "BioPerl List" <bioperl-l at lists.open-bio.org>
>>>
>>>       Sent: Tuesday, May 12, 2009 9:17 AM
>>>
>>>       Subject: Re: [Bioperl-l] SearchIO to GFF (was: Getting   
>>> 'features' fromSearchIO?)
>>>
>>>
>>>
>>>
>>>
>>>       2009/5/12 Chris Fields <cjfields at illinois.edu>:
>>>
>>>         Fixed that in svn. We're all still learning the ropes...
>>>
>>>
>>>
>>>       In that case, I'm seeing multiple instances of...
>>>
>>>
>>>
>>>       Argument "" isn't numeric in addition (+) at Bio/Search/  
>>> SearchUtils.pm line 256
>>>
>>>       Argument "" isn't numeric in addition (+) at Bio/Search/  
>>> SearchUtils.pm line 412
>>>
>>>       Argument "" isn't numeric in addition (+) at Bio/Search/  
>>> SearchUtils.pm line 429
>>>
>>>       Argument "" isn't numeric in addition (+) at Bio/Search/  
>>> SearchUtils.pm line 465
>>>
>>>       Argument "" isn't numeric in addition (+) at Bio/Search/  
>>> SearchUtils.pm line 473
>>>
>>>       Argument "" isn't numeric in addition (+) at Bio/Search/  
>>> SearchUtils.pm line 494
>>>
>>>       Argument "" isn't numeric in addition (+) at Bio/Search/  
>>> SearchUtils.pm line 502
>>>
>>>
>>>
>>>
>>>
>>>       Hmm... I was about to go on to complain about the weird GFF   
>>> that I was
>>>
>>>       seeing, but suddenly it looks OK. My bioperl install must   
>>> think your
>>>
>>>       standing over my shoulder and is therefore behaving itself!
>>>
>>>
>>>
>>>
>>>
>>>       Thanks again for all the help,
>>>
>>>       Dan.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>         chris
>>>
>>>
>>>
>>>         On May 12, 2009, at 5:55 AM, Dan Bolser wrote:
>>>
>>>
>>>
>>>           2009/5/12 Dan Bolser <dan.bolser at gmail.com>:
>>>
>>>
>>>
>>>             Unfortunately bp_search2gff.pl is giving me errors:
>>>
>>>
>>>
>>>             bp_search2gff.pl --version 3 -i BlastResults/  
>>> blast_table_filtered  -f
>>>
>>>             blasttable -o BlastResults/blast_table_filtered.gff - 
>>> t  hit
>>>
>>>             --match --target --component
>>>
>>>
>>>
>>>             --------------------- WARNING ---------------------
>>>
>>>             MSG: Removing score value(s)
>>>
>>>             ---------------------------------------------------
>>>
>>>             Can't locate object method "remove_tags" via package
>>>
>>>             "Bio::SeqFeature::Similarity" at
>>>
>>>             /local/Scratch/dbolser/perl5/lib/perl5/Bio/SeqFeature/  
>>> Generic.pm  line
>>>
>>>             393, <GEN1> line 5.
>>>
>>>
>>>
>>>
>>>
>>>           I'm just learning the ropes...
>>>
>>>
>>>
>>>           --- ~/perl5/lib/perl5/Bio/SeqFeature/Generic.pm~  
>>> 2009-05-11
>>>
>>>           15:25:55.000000000 +0100
>>>
>>>           +++ ~/perl5/lib/perl5/Bio/SeqFeature/Generic.pm 2009-05-12
>>>
>>>           11:52:41.000000000 +0100
>>>
>>>           @@ -390,7 +390,7 @@
>>>
>>>           }
>>>
>>>           if ($self->has_tag('score')) {
>>>
>>>           $self->warn("Removing score value(s)");
>>>
>>>           - $self->remove_tags('score');
>>>
>>>           + $self->remove_tag('score');
>>>
>>>           }
>>>
>>>           $self->add_tag_value('score',$value);
>>>
>>>           }
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>             Anyone seen this before?
>>>
>>>
>>>
>>>             Cheers,
>>>
>>>             Dan.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>             2009/5/12 Dan Bolser <dan.bolser at gmail.com>:
>>>
>>>
>>>
>>>               Thanks for the info guys, I think I was naively   
>>> hoping that the
>>>
>>>               feature would know how to cast itself as a   
>>> 'SeqFeature' (GFF).
>>>
>>>
>>>
>>>               I think I understand the problem better now, so  
>>> I'll  try to summarise:
>>>
>>>
>>>
>>>               There is no standard way to encode a HSP as a  
>>> feature  (not least
>>>
>>>               because there are two choices about which sequence   
>>> (query or the  hit)
>>>
>>>               it should be attached to). BioPerl will try, but  
>>> the  result will  not
>>>
>>>               be "well structured" SeqFeatures or "well formed" GFF.
>>>
>>>
>>>
>>>
>>>
>>>               From what I read I guess it should be possible to   
>>> standardize this
>>>
>>>               mapping (based on something in one of the examples  
>>> or  the 'search2gff'
>>>
>>>               script), assuming you specify weather you want   
>>> features put on the
>>>
>>>               query or on the hit.
>>>
>>>
>>>
>>>               At some point last year I was trying out the   
>>> bp_search2gff.pl and my
>>>
>>>               own code to write a GFF file for loading and  
>>> viewing  by Gbrowse.  At
>>>
>>>               that time I gave up, as nothing seemed to be  
>>> working.  I was hoping
>>>
>>>               that doing this at a lower level (i.e. never  
>>> writing  any GFF myself)
>>>
>>>               it would stand a better chance of working.
>>>
>>>
>>>
>>>               Also I was thinking that Gbrowse, if given a  
>>> SeqFeature::Store,  could
>>>
>>>               autoconfigure its interface to some degree. I guess   
>>> its back to  the
>>>
>>>               docs ;-)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>               I'll keep trying and see if I can get anywhere.
>>>
>>>
>>>
>>>               Thanks again,
>>>
>>>               Dan.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>               References for the above:
>>>
>>>
>>>
>>>               2009/5/11 Jason Stajich <jason at bioperl.org>:
>>>
>>>
>>>
>>>                 otherwise you need to be converting the HSPs into  
>>> seqfeatures  with the
>>>
>>>                 right associated information (i.e. the tag/value   
>>> pairs that are  in the 9th
>>>
>>>                 column) in order to have well structured data in   
>>> the database.
>>>
>>>
>>>
>>>                 You can get the individual features from the   
>>> feature pair with
>>>
>>>                 $hsp->query or $hsp->hit which can also be passed   
>>> to a GFF writer (or call
>>>
>>>                 $hsp->hit->gff_string). Note that since the data   
>>> storage is not structured
>>>
>>>                 in a GFF3 like-way this won't immediately produce   
>>> well formed  GFF3 for the
>>>
>>>                 9th column.
>>>
>>>
>>>
>>>
>>>
>>>               2009/5/11 Chris Fields <cjfields at illinois.edu>:
>>>
>>>
>>>
>>>                 The main problem is the mapping is subjective  
>>> based  on what your
>>>
>>>                 reference sequence is within the BLAST run (e.g.   
>>> whether it is  the query or
>>>
>>>                 the hit), and is something that can't be   
>>> automatically discerned. I ended
>>>
>>>                 up rolling my own with SeqFeature::Store (just   
>>> mapped the relevant data to
>>>
>>>                 Bio::DB::SeqFeatures), but I have long wanted to   
>>> fix up the relevant scripts
>>>
>>>                 to integrate my changes in, just haven't had the  
>>> time
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>           _______________________________________________
>>>
>>>           Bioperl-l mailing list
>>>
>>>           Bioperl-l at lists.open-bio.org
>>>
>>>           http://lists.open-bio.org/mailman/listinfo/bioperl-l
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>       _______________________________________________
>>>
>>>       Bioperl-l mailing list
>>>
>>>       Bioperl-l at lists.open-bio.org
>>>
>>>       http://lists.open-bio.org/mailman/listinfo/bioperl-l
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>
>>>     Bioperl-l mailing list
>>>
>>>     Bioperl-l at lists.open-bio.org
>>>
>>>     http://lists.open-bio.org/mailman/listinfo/bioperl-l
>>>
>>>
>>>
>>>
>>>   _______________________________________________
>>>   Bioperl-l mailing list
>>>   Bioperl-l at lists.open-bio.org
>>>   http://lists.open-bio.org/mailman/listinfo/bioperl-l
>>>
>>>
>>>
>>> Jason Stajich
>>> jason at bioperl.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> Jason Stajich
>> jason at bioperl.org
>>
>>
>>
>>
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>>
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l




More information about the Bioperl-l mailing list