Hey Jonathan and Sandra,
So I've been looking at some of the issues you two raised and here are
some comments:
Thanks for the detailed debugging information. I took a quick look at your
sample input files and determined that you can fix the problem by doing
either of the following things:
1. Leave the GFF unchanged but modify the Shape used to draw the
polypeptides. If you go to Preferences, select the "Types" tab and then
"polypeptide" from the "Tier" pull-down menu and then change the Shape to
any of the following your feature should show up (after you click on
"Preview" or "Save", of course):
DoubleHeadedArrow,Triangle,Zigzag,ThinRectangle. At this point your feature
will appear _in the annotation area_.
2. Change the SO type in the GFF file from "polypeptide" to "match". Your
feature will then appear _in the results area_.
#2 seems like the most appropriate course of action given that your GFF3
feature has a "Target" attribute, which is typically only the case for
search hits/matches. Let me know if you have trouble getting either of
these approaches to work. I should mention that I think you may encounter
other quirks with the GFF3 support. One thing I noticed, at least in 1.10.0
is that Apollo seems to rely on a sequence-region pragma to figure out where
the annotations should go, rather than looking at the sequence id of the GFF
features. The effect of this is that if you overlay a GFF file with
annotations from several different chromosomes they will all go into the
current display, unless the appropriate sequence-region pragmas are
included. Another word of caution is that I don't know what, if anything,
Apollo will do with polypeptide entries in the ##FASTA section of the GFF
file, so if you want that sequence to be somehow associated with the loaded
feature you should verify that Apollo is doing what you expect.
I second Jonathan's suggestion to have the type be "match" since the
feature does contain a "Target" attribute. I've made changes to the code
to validate each entry's sequence id against the currently loaded
sequence (in the case of appending data). After some thought, I decided
to just warn the user and skip the entry rather than stop loading all
together (so you could append data that contains features on multiple
genomic regions). Also, for any "match" features, the sequence data
(in this case the polypeptide sequence) is stored in the underlying
FeaturePair object. Note that if the "##sequence-region" pragma has
a mismatching id, appending of data will just stop right away.
BTW Sandra, be aware that with the sequence id checking, the GFF3 you
provided will not load, as the ChadoXML file has the genomic id as
"X_364690_403133" while the GFF3 entry has an id of "X".
I noticed the same thing and I'm not sure what the deal is with that. I'm
compiling on Ubuntu with a non-Sun JVM and don't have that class either.
Any ideas, Ed?
I'm not sure why the developer was importing that class, but seeing as
that the class is not being used anywhere, I went ahead and removed
the declaration. Although as a word of advice, I would highly recommend
against using non Sun Java compilers/JVMs (e.g., gcj) as from experience
they're pretty awful.
I will be commiting the changes shortly.
Cheers,
Ed
_______________________________________________
apollo mailing list
[email protected]
http://mail.fruitfly.org/mailman/listinfo/apollo
