[maker-devel] Maker-derived CDS GFF3 phase column

Carson Holt carsonhh at gmail.com
Wed May 22 10:39:53 MDT 2013


Ok.  It's available for download.

--Carson


From:  Rob Syme <rob.syme at gmail.com>
Date:  Wednesday, 22 May, 2013 12:04 AM
To:  Carson Holt <carsonhh at gmail.com>
Cc:  <maker-devel at yandell-lab.org>
Subject:  Re: [maker-devel] Maker-derived CDS GFF3 phase column

Fantastic. I thought that might have been the problem.

Looking forward to 2.28. Thanks!

Rob


On Wed, May 22, 2013 at 10:32 AM, Carson Holt <carsonhh at gmail.com> wrote:
> It looks like the phase was calculated from the wrong strand orientation.  I
> believe I have corrected this now.  I'm checking a few more things, but I'll
> have 2.28 as the latest release likely tomorrow with the cumulative bug fixes
> since the last release.
> 
> Thanks,
> Carson
> 
> 
> 
> From:  Rob Syme <rob.syme at gmail.com>
> Date:  Tuesday, 21 May, 2013 1:57 AM
> To:  <maker-devel at yandell-lab.org>
> Subject:  [maker-devel] Maker-derived CDS GFF3 phase column
> 
> Hi all
> 
> By my reading of the GFF3 spec
> (http://sequenceontology.org/resources/gff3.html), I'm getting gff3 from Maker
> that has odd data in the phase column.
> 
> For example, see some example Maker output at
> https://gist.github.com/robsyme/5617399
> 
> There are two exons, 5617 <- 5737 and 5793 <- 5953 with phases 0 and 2,
> respectively. Both exons are in the reverse strand.
> 
> From the spec, phase indicates "the number of bases that should be removed
> from the beginning of this feature to reach the first base of the next codon",
> and for "reverse strand features, phase is counted from the end field".
> 
> In the case of the 3' exon (5793 <- 5953), the end field (the 5th column) is
> 5953. 
> The base at the end field is the first base of the translated CDS, so there
> should be no bases removed "to reach the first base of the next codon". I
> suggest that this phase should be 0, not 2.
> 
> There is an illustration of the feature at http://i.imgur.com/DKLxnSf.png.
> 
> The output gff3 is correct if "the number of bases that should be removed from
> the beginning of this feature to reach the first base of the next codon" is
> measured from the 'left-hand' end of this feature (the start field) rather
> than the end field.
> 
> Has anybody else ran into this problem or am I misreading the gff3 spec?
> 
> Rob Syme
> PhD Student
> Curtin University
> 
> 
> 
> 
> _______________________________________________ maker-devel mailing list
> maker-devel at box290.bluehost.comhttp://box290.bluehost.com/mailman/listinfo/mak
> er-devel_yandell-lab.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20130522/74b8200a/attachment-0003.html>


More information about the maker-devel mailing list