Problem with temporary GFF file #12
Comments
|
I can take a look if you can send me "lifted.gff3". |
|
That would be great! |
|
I am seeing the same problem as well... need anymore test data? |
|
I think the specific issue with these parents not being defined happens due to them being in the unlifted file For example I had child features with Parent=SP_0.1_T008586-R3 in lifted.gff3 but then unlifted.gff3 had the actual parent where ID=PKINGS_0.1_T008586-R3 |
|
That is expected as liftOver reads gff line by line and not the transcript as a whole. flo's process_gff method tries to fix such inconsistencies in liftOver's output. So the final output from flo should not be an invalid gff.
… On 27 Jun 2017, at 22:20, Colin Diesh ***@***.***> wrote:
I think the specific issue with these parents not being defined happens due to them being in the unlifted file
For example I had child features with Parent=SP_0.1_T008586-R3 in lifted.gff3 but then unlifted.gff3 had the actual parent where ID=PKINGS_0.1_T008586-R3
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Ah...I think I remember at one point writing a script to synthesize a parent features for features without parents for something like this...is that what process_gff does? |
|
That, and eliminating transcripts that mapped partly to different scaffolds.
… On 28-Jun-2017, at 12:09 AM, Colin Diesh ***@***.***> wrote:
Ah...I think I remember at one point writing a script to synthesize a parent features for features without parents for something like this...is that what process_gff does?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFhBewAkK8sd0zhbCArJP81gDicmpKOks5sIYuogaJpZM4N5hgT>.
|
|
Gotcha...I was considering maybe using crossmap, but it looks like it has the same issue Maybe need to convert from gff to something else, bed12 or similar |
There was a bug. I have made some changes. Can you give it a spin? @blackFirefly - please see my email |
|
@yeban I believe it is working better now, it now gets to the genometools stage, but the genometools ends up crashing Could maybe ask their team about it, error message isn't easy to interpret |
|
At least one thing that could be suspicious is that there are still lines that exist without parents. If I save the file from
|
Following up on SHA: b629cb9 and trying to address: #12. Notable changes: 1. We allow transcripts to be annotated as mRNA, transcript, or gene. Yet, for reconstructed transcripts the script would always use 'mRNA' type. Fix that. 2. Features that could not be processed are now put on stderr. This is captured by the pipeline to provide lifted_but_rejected.gff. Signed-off-by: Anurag Priyam <anurag.priyam@qmul.ac.uk>
|
@blackFirefly's problem was partly flo and partly the gff. The former is now fixed. @cmdcolin I can't be sure what the problem is without looking at the input / lifted gff. Please could you open a new issue with test data? |
I tried flo yesterday, but it ended up in an error. It seems like there is a problem in a temorary GFF file?
So the question is if the program or my input GFF is the problem?
It created a file called "lifted.gff3" and one called "unlifted.gff3". Both of them are filled. But there is also a third file "Aarabicum.v2.5.gff-liftover-aethionema-arabicum_v3.0.fasta.gff3" which is empty.
Here are the last lines flo printed:
The text was updated successfully, but these errors were encountered: