[maker-devel] Handling of strandedness of est_gff
Carson Holt
carsonhh at gmail.com
Tue Feb 5 08:17:40 MST 2013
MAKER assumes the data in the est_gff is correctly stranded. If not there
is no real way for MAKER to adjust for that as I can show you several
cases where I can get coding models that match the est alignment well on
both strands. MAKER uses exonerate to polish alignments when generated
internally because in cases such as the ones I just described, one strand
will match better only when you account for all splice sites in the model,
but I can't do that type of polishing on gff3 derived alignments, and in
the case of cufflinks, it should already be taking splice sites into
account. Of course if these are single exon alignments then cufflinks
doesn't know which strand to assign them to and I would recommend not
including single exon alignments in the est_gff. Also consider using
trinity over cufflinks, as I've seen more positive results from its
alignments/assemblies of mRNAseq.
Thanks,
Carson
On 13-02-05 10:01 AM, "Mikael Brandström Durling" <mikael.durling at slu.se>
wrote:
>Hi,
>
>while looking into the annotations created by maker I find that there are
>cases where the ab initio prediction sits on one strand of the reference,
>while the est_gff evidence from cufflinks sits on the other strand. In
>this case the aed is rather low, and the predictions seems quite off. Is
>maker taking the strand information of the est_gff into account? If so,
>is it possible to tell maker that the ests are unstranded and only use
>the structural information rather than structure and strand?
>
>Thanks for any advice,
>Mikael
>
>
>_______________________________________________
>maker-devel mailing list
>maker-devel at box290.bluehost.com
>http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
More information about the maker-devel
mailing list