Apollo generates the gff3 with boundaries for the longer feature when two overlap in same reading frame

[jrr-cpt]

@MoffMade @BeaverThing Noticed an error in the coordinates that are generated in the gff3 for a feature when two genes that are in the same reading frame are called. Usually this happens when we are comparing the possible lengths for a particular gene: we call both, check the nucleotides in the start and SD, then delete one. What I noticed in the Spanins Test Genome organism is that if you called the longer possible ORF first, then ended up deleting it, the shorter feature still had the gene coordinates of the longer feature, though child coordinates are correct. I can reproduce this error by simple order of calling and deleting.

For example, I noticed that the output of this OSP tool in the evidence track was extending the feature out in the 5' direction from the start.

This was actually correct because the gff3 for the feature had the longer coordinates:

And by deleting the gene, then calling the MGA (light blue) feature, followed by the Glimmer (dark blue/shorter) feature, both features end up with the same gene coordinates. Then it doesn't matter which gets deleted, because the coordinates are already set.

Perhaps a good question for Apollo/Nathan?

[MoffMade]

As discussed in the meeting earlier, lets put this on hold and test similar situations in the new Apollo version, it may have been handled in the updates.

For now, it looks like you can "reset" the coordinates by selecting the problem feature and hitting one of the "Set translaition start" options in the rightclick menu and then undoing that action. It seems to be due to overlapping gene feature calls in the same reading frame