Skip to content
Snippets Groups Projects
Commit c67d1160 authored by edgrif's avatar edgrif
Browse files

moved to 2007

parent cf47b0aa
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 0 additions and 4682 deletions
ZMAP_LACE_PROJECT/zmap_lace.2007_01_11 deleted 100755 → 0
+ 0
− 203
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Thurs 11th January 2007
Attendees: jla1, jgrg, kj2, edgrif
1) otterlace + zmap progress
============================
latest test_otterlace
---------------------
- we have a new release of zmap, jgrg just needs to check a couple of things
and then we give it to Liz to try. jgrg & edgrif need to do release notes to
accompany this release.
High priority
-------------
1/ multiple alignments: edgrif is about a third of the way through
implementing a more general way of displaying arbitrary blocks. This is a high
priority item.
Medium priority
---------------
1/ Saturated_EST bug: because of some ambiguity if tag usage in acedb methods
these don't get shown in the right way. This will be properly fixed when we
have zmap styles which are completely separate from acedb methods.
2/ DNA finder - Needs to show its find results location on the zmap as in
fmap, would be nice to be colour coded depending on the strand. The finder
needs to be extended to also do protein searches, edgrif will talk to kj2
about this and clarify what's required.
Searching should be restricted to any marked region is one is set, edgrif to
do this.
3/ Differentiation between swissprot and trembl - separate columns or
different shading within that column (?)
This is a data issue, we could easily colour these entries differently if that
was what was wanted by giving them seperate methods. We'll do this when
edgrif/rds have written the new style code to replace acedb methods.
4/ kj2 would like more information available for features such as the species
and the DE lines. edgrif said they could display this via the current
mechanism of mouse-over popups in the "Info" line at the top of the ZMap. jgrg
is going to make sure this information is in the acedb objects so it can be
exported to zmap.
5/ zmap needs to get sequences that are in acedb from there for blixem, means
issuing a call to the server to get them but this is possible. NOTE that some
sequences are _only_ in acedb.
6/ we need a "back" button, the new zoom functions help with this though.
7/ kj2 said she would like to be able to select a contiguous set of hits and
use them to create a new transcript (much like the "Create Temp Gene" function
in acedb Gene Finder. edgrif and jgrg will look at the code required to do
this.
8/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults. edgrif or rds will do this.
9/ edgrif said users could now click on features to delete them. kj2 said she
would like a stack of sets of deleted features that she could step back
through, edgrif to implement this.
10/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
11/ jgrg pointed out a bug in the menu which has a "mark" but not an "unmark"
item. Also, selecting "Set feature for Bump" only marks the selected exon, not
the whole transcript. edgrif will fix these.
12/ jla1 asked if we could make the lines joining up matches much thinner and
have an invisible background that allows easy clicking. edgrif will do this.
13/ Kerstin needs some acedb keyset like functions in lace to allow her to
perform operations on multiple features. jgrg to discuss/implement with kj2.
Low priority
------------
1/ Feature highlight colour has been fixed but it doesn't work that well for
transcripts where often there is only an outline, we need to highlight more
intelligently so that for features that do not have a fill colour we do
highlight by filling the boxes.
2/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
3/ cannot currently cursor through features in a column, there are some
technical problems here to do with raising items so they are visible.
4/ edgrif fixed a performance problem when drawing _all_ homol matches as
gapped. But this relies on slop factor set for the 'Gapped' tag in the
method, edgrif will sort this out with jgrg.
5/ alternative translations: edgrif about half way through code to do this.
Builds
------
- we now have the mac machine for overnight/regular builds but are having some
library problems which we hope to sort out, in the meantime we can do "hand"
builds via the laptop.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
multiple species
----------------
jgrg, edgrif, lg4 and rds met to discuss this and we need to revist it to
check on progress. It requires some alterations to lace infrastructure to
support editting multiple species.
jla1 asked if we could get some kind of demo going for a workshop on the
20/21st Jan, edgrif and jgrg will see what can be done.
================== from last time =================================================
James and Ed need to discuss how this will be done. Zmap can display multiple
sequences in one zmap window but there will need to changes to the supporting
infrastructure including:
- should the species go in one or multiple acedb databases
- the lace <-> zmap protocol needs to allow specification of
multiple sequence display.
- lace needs to allow the user to pick multiple species
jla1 said a better test than Charlie and NOD mouse is Richard and haplotypes
of which he may have up to 6 (!). jla1 said is there any limit to number,
edgrif said "no, only machine memory....". To quickly test this edgrif will
get data from Richard and try it out to look at performance. Simplest way is
to just display data as is, this mimics what Richard does currently in
fmap. edgrif said that if we used Compara alignment data we could just display
the "sub-blocks" of the alignments that actually contained data. This would
produce much more compact displays.
================== from last time =================================================
2) Other matters
================
sorry, this section is rather sparse...give me more information if you need
to.
- script for EMBL dumping: needs testing by Jen. James thinks this all
works. There was a discussion about submissions more generally and it was
agreed that all regions going into VEGA should be submitted. This let into a
request for some kind of "Clone status" flag. jgrg said there used to be one
and that it should be recreated.
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
jgrg to think about this.
3) Next Meeting
===============
Will be at 2pm, 24/01/2007.
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_01_24 deleted 100755 → 0
+ 0
− 239
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Thurs 11th January 2007
Attendees: jla1, jgrg, kj2, edgrif
1) otterlace + zmap progress
============================
latest test_otterlace
---------------------
- we have a new release of zmap, jgrg just needs to check a couple of things
and then we give it to Liz to try. jgrg & edgrif need to do release notes to
accompany this release.
Demo to havana
--------------
A lively discussion on a number of items including:
- where to find the docs we have written for zmap. DONE edgrif
- showing alignment information for hits of a match in a list/edit window. DONE edgrif
- how to tell otterlace that there has been a multiple select by the user.
- sorting of dna matches, Adam would like the current 5' exon style sort.
- fixed/frozen columns like in excel ?
- order of split windows, the bumped window should be on the right when a
vertical split is done.
- windows can be unlocked but can they be relocked ?
- locus readability DONE rds
- drag of mark region
- zoom to show all protein when 3 frame translation is displayed.
- select features by lasso
- more zoom increments
- proteins should be bumped by best score (not how acedb works in fact) DONE edgrif
- put exons in capitals in exported sequence and consider allowing option
of coloured coded export.
High priority
-------------
1/ multiple alignments: edgrif is about a third of the way through
implementing a more general way of displaying arbitrary blocks. This is a high
priority item.
Medium priority
---------------
1/ Saturated_EST bug: because of some ambiguity if tag usage in acedb methods
these don't get shown in the right way. This will be properly fixed when we
have zmap styles which are completely separate from acedb methods.
2/ DNA finder - Needs to show its find results location on the zmap as in
fmap, would be nice to be colour coded depending on the strand. The finder
needs to be extended to also do protein searches, edgrif will talk to kj2
about this and clarify what's required.
Searching should be restricted to any marked region is one is set, edgrif to
do this.
3/ Differentiation between swissprot and trembl - separate columns or
different shading within that column (?)
This is a data issue, we could easily colour these entries differently if that
was what was wanted by giving them seperate methods. We'll do this when
edgrif/rds have written the new style code to replace acedb methods.
4/ kj2 would like more information available for features such as the species
and the DE lines. edgrif said they could display this via the current
mechanism of mouse-over popups in the "Info" line at the top of the ZMap. jgrg
is going to make sure this information is in the acedb objects so it can be
exported to zmap.
5/ zmap needs to get sequences that are in acedb from there for blixem, means
issuing a call to the server to get them but this is possible. NOTE that some
sequences are _only_ in acedb.
6/ we need a "back" button, the new zoom functions help with this though.
7/ kj2 said she would like to be able to select a contiguous set of hits and
use them to create a new transcript (much like the "Create Temp Gene" function
in acedb Gene Finder. edgrif and jgrg will look at the code required to do
this.
8/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults. edgrif or rds will do this.
9/ edgrif said users could now click on features to delete them. kj2 said she
would like a stack of sets of deleted features that she could step back
through, edgrif to implement this.
10/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
11/ jgrg pointed out a bug in the menu which has a "mark" but not an "unmark"
item. Also, selecting "Set feature for Bump" only marks the selected exon, not
the whole transcript. edgrif will fix these.
12/ jla1 asked if we could make the lines joining up matches much thinner and
have an invisible background that allows easy clicking. edgrif will do this.
13/ Kerstin needs some acedb keyset like functions in lace to allow her to
perform operations on multiple features. jgrg to discuss/implement with kj2.
Low priority
------------
1/ Feature highlight colour has been fixed but it doesn't work that well for
transcripts where often there is only an outline, we need to highlight more
intelligently so that for features that do not have a fill colour we do
highlight by filling the boxes.
2/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
3/ cannot currently cursor through features in a column, there are some
technical problems here to do with raising items so they are visible.
4/ edgrif fixed a performance problem when drawing _all_ homol matches as
gapped. But this relies on slop factor set for the 'Gapped' tag in the
method, edgrif will sort this out with jgrg.
5/ alternative translations: edgrif about half way through code to do this.
Builds
------
- we now have the mac machine for overnight/regular builds but are having some
library problems which we hope to sort out, in the meantime we can do "hand"
builds via the laptop.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
multiple species
----------------
jgrg, edgrif, lg4 and rds met to discuss this and we need to revist it to
check on progress. It requires some alterations to lace infrastructure to
support editting multiple species.
jla1 asked if we could get some kind of demo going for a workshop on the
20/21st Jan, edgrif and jgrg will see what can be done.
================== from last time =================================================
James and Ed need to discuss how this will be done. Zmap can display multiple
sequences in one zmap window but there will need to changes to the supporting
infrastructure including:
- should the species go in one or multiple acedb databases
- the lace <-> zmap protocol needs to allow specification of
multiple sequence display.
- lace needs to allow the user to pick multiple species
jla1 said a better test than Charlie and NOD mouse is Richard and haplotypes
of which he may have up to 6 (!). jla1 said is there any limit to number,
edgrif said "no, only machine memory....". To quickly test this edgrif will
get data from Richard and try it out to look at performance. Simplest way is
to just display data as is, this mimics what Richard does currently in
fmap. edgrif said that if we used Compara alignment data we could just display
the "sub-blocks" of the alignments that actually contained data. This would
produce much more compact displays.
================== from last time =================================================
2) Other matters
================
sorry, this section is rather sparse...give me more information if you need
to.
- script for EMBL dumping: needs testing by Jen. James thinks this all
works. There was a discussion about submissions more generally and it was
agreed that all regions going into VEGA should be submitted. This let into a
request for some kind of "Clone status" flag. jgrg said there used to be one
and that it should be recreated.
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
jgrg to think about this.
3) Next Meeting
===============
Will be at 2pm, 24/01/2007.
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_02_01 deleted 100755 → 0
+ 0
− 203
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Thurs 11th January 2007
Attendees: jla1, jgrg, kj2, edgrif
1) otterlace + zmap progress
============================
latest test_otterlace
---------------------
- we have a new release of zmap, jgrg just needs to check a couple of things
and then we give it to Liz to try. jgrg & edgrif need to do release notes to
accompany this release.
High priority
-------------
1/ multiple alignments: edgrif is about a third of the way through
implementing a more general way of displaying arbitrary blocks. This is a high
priority item.
Medium priority
---------------
1/ Saturated_EST bug: because of some ambiguity if tag usage in acedb methods
these don't get shown in the right way. This will be properly fixed when we
have zmap styles which are completely separate from acedb methods.
2/ DNA finder - Needs to show its find results location on the zmap as in
fmap, would be nice to be colour coded depending on the strand. The finder
needs to be extended to also do protein searches, edgrif will talk to kj2
about this and clarify what's required.
Searching should be restricted to any marked region is one is set, edgrif to
do this.
3/ Differentiation between swissprot and trembl - separate columns or
different shading within that column (?)
This is a data issue, we could easily colour these entries differently if that
was what was wanted by giving them seperate methods. We'll do this when
edgrif/rds have written the new style code to replace acedb methods.
4/ kj2 would like more information available for features such as the species
and the DE lines. edgrif said they could display this via the current
mechanism of mouse-over popups in the "Info" line at the top of the ZMap. jgrg
is going to make sure this information is in the acedb objects so it can be
exported to zmap.
5/ zmap needs to get sequences that are in acedb from there for blixem, means
issuing a call to the server to get them but this is possible. NOTE that some
sequences are _only_ in acedb.
6/ we need a "back" button, the new zoom functions help with this though.
7/ kj2 said she would like to be able to select a contiguous set of hits and
use them to create a new transcript (much like the "Create Temp Gene" function
in acedb Gene Finder. edgrif and jgrg will look at the code required to do
this.
8/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults. edgrif or rds will do this.
9/ edgrif said users could now click on features to delete them. kj2 said she
would like a stack of sets of deleted features that she could step back
through, edgrif to implement this.
10/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
11/ jgrg pointed out a bug in the menu which has a "mark" but not an "unmark"
item. Also, selecting "Set feature for Bump" only marks the selected exon, not
the whole transcript. edgrif will fix these.
12/ jla1 asked if we could make the lines joining up matches much thinner and
have an invisible background that allows easy clicking. edgrif will do this.
13/ Kerstin needs some acedb keyset like functions in lace to allow her to
perform operations on multiple features. jgrg to discuss/implement with kj2.
Low priority
------------
1/ Feature highlight colour has been fixed but it doesn't work that well for
transcripts where often there is only an outline, we need to highlight more
intelligently so that for features that do not have a fill colour we do
highlight by filling the boxes.
2/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
3/ cannot currently cursor through features in a column, there are some
technical problems here to do with raising items so they are visible.
4/ edgrif fixed a performance problem when drawing _all_ homol matches as
gapped. But this relies on slop factor set for the 'Gapped' tag in the
method, edgrif will sort this out with jgrg.
5/ alternative translations: edgrif about half way through code to do this.
Builds
------
- we now have the mac machine for overnight/regular builds but are having some
library problems which we hope to sort out, in the meantime we can do "hand"
builds via the laptop.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
multiple species
----------------
jgrg, edgrif, lg4 and rds met to discuss this and we need to revist it to
check on progress. It requires some alterations to lace infrastructure to
support editting multiple species.
jla1 asked if we could get some kind of demo going for a workshop on the
20/21st Jan, edgrif and jgrg will see what can be done.
================== from last time =================================================
James and Ed need to discuss how this will be done. Zmap can display multiple
sequences in one zmap window but there will need to changes to the supporting
infrastructure including:
- should the species go in one or multiple acedb databases
- the lace <-> zmap protocol needs to allow specification of
multiple sequence display.
- lace needs to allow the user to pick multiple species
jla1 said a better test than Charlie and NOD mouse is Richard and haplotypes
of which he may have up to 6 (!). jla1 said is there any limit to number,
edgrif said "no, only machine memory....". To quickly test this edgrif will
get data from Richard and try it out to look at performance. Simplest way is
to just display data as is, this mimics what Richard does currently in
fmap. edgrif said that if we used Compara alignment data we could just display
the "sub-blocks" of the alignments that actually contained data. This would
produce much more compact displays.
================== from last time =================================================
2) Other matters
================
sorry, this section is rather sparse...give me more information if you need
to.
- script for EMBL dumping: needs testing by Jen. James thinks this all
works. There was a discussion about submissions more generally and it was
agreed that all regions going into VEGA should be submitted. This let into a
request for some kind of "Clone status" flag. jgrg said there used to be one
and that it should be recreated.
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
jgrg to think about this.
3) Next Meeting
===============
Will be at 2pm, 24/01/2007.
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_02_23 deleted 100755 → 0
+ 0
− 360
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Friday 23rd February 2007
Attendees: lw2, jgrg, th, edgrif
1) otterlace + zmap progress
============================
jla1 sent a list of bugs reported by users for the latest test_otterlace
system, I have incorporated these below with comments:
High priority
-------------
1/ multiple alignments: edgrif is about a third of the way through
implementing a more general way of displaying arbitrary blocks. This is a high
priority item.
2/ Rev strand issues:
>> Saving gives wrong co-ordinates, object goes to the wrong
>> location ??..sorted by re-synch (possible fixed for next release?)
this is fixed
>> Using evidence for co-ordinates wrong, 3 frame translation wrong (maybe
>> fixed in next realease).
No one has mentioned this until now, edgrif/rds to investigate
Medium priority
---------------
1/ Saturated_EST bug: because of some ambiguity if tag usage in acedb methods
these don't get shown in the right way. This will be properly fixed when we
have zmap styles which are completely separate from acedb methods.
edgrif is implementing the new styles now.
2/ DNA finder - Needs to show its find results location on the zmap as in
fmap, would be nice to be colour coded depending on the strand. The finder
needs to be extended to also do protein searches. Searching should be
restricted to any marked region is one is set, edgrif to do this.
edgrif is implementing protein search now, location results to come (note that
currently the user is shown a list of all hits and clicking on a hit takes
the user to that hit).
3/ kj2 would like more information available for features such as the species
and the DE lines. edgrif said they could display this via the current
mechanism of mouse-over popups in the "Info" line at the top of the ZMap. jgrg
is going to make sure this information is in the acedb objects so it can be
exported to zmap.
jgrg, lw2 and edgrif to meet to establish "policy" for which data is displayed
by zmap and which by lace. edgrif said that they will need to establish a
"tag - value" system to make information display more generalised.
4/ zmap needs to get sequences that are in acedb from there for blixem, means
issuing a call to the server to get them but this is possible. NOTE that some
sequences are _only_ in acedb.
5/ kj2 said she would like to be able to select a contiguous set of hits and
use them to create a new transcript (much like the "Create Temp Gene" function
in acedb Gene Finder.
rds code will allow lace to do this, jgrg to sort out lace implementation to
build the transcript.
6/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif or rds will do this.
7/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
8/ jgrg pointed out a bug in the menu which has a "mark" but not an "unmark"
item. Also, selecting "Set feature for Bump" only marks the selected exon, not
the whole transcript. edgrif will fix these.
9/ Kerstin needs some acedb keyset like functions in lace to allow her to
perform operations on multiple features. jgrg to discuss/implement with kj2.
jgrg and edgrif agreed that the way to do this is to allow users to "detach"
lace from a database, the user then uses xace to do their keyset stuff and
then lace reattaches. This is viable because most users do not do this
kind of operation so why spend large amounts of time reimplementing xace
function.
10/ Display comes up full screen and if you click on it or resize it before
>> it loads the data it will crash.
the resizing is fixed, but it still comes up full screen. Ed coded this to
come up full size of the screen in only the vertical direction and about 60%
in the horizontal. Unfortunately a bug in gnome window managed for the debian
version we're using mean it's full screen in both. This is not an issue if
using KDE or gnoe under ubuntu for example. edgrif will fix resizing for
faulty window managers + investigate the crash.
11/>> 3. Can't get otterid in zmap.
>>
>> 4. Halfwise hits: No info when you click on them.
>>
These are both data display issues and will be covered by item 3/ above.
12/ >> 5. No crosshairs.
just needs user to use correct short cut, all in the help pages.
13/ >> 6. Can't display Swissport and TrEmbl in one blixem in zmap.
>> Is this because they are now in separate columns?
Yes, edgrif will alter code so that for proteins user has choice of one of
these columns or both when invoking blixem. In an ideal world we would allow
user to select multiple columns on which to run blixem, edgrif might do this
if simple.
14/ >> 7. Clone boundaries unclear.
This is a user issue, the information is available from zmap and lace now.
15/ >> 8. Evidence co-ordinates come up as genomic co-ordinates (rather than cDNA
>> base numbers) aren't visible on alignments (also clicking on evidence
>> centres the display).
OK, issue here is that coord data is not displayed by lace so needs to be
displayed by zmap when displaying an alignment feature. edgrif/rds will fix.
16/ >> 9. Highlighting an object hides the CDS.
This will be fixed when new styles come in.
17/ >> 10. Bumping:
>> Gaps between columns need to be removed.
>> Coloured bars are incorrect when in reverse.
>> Need to discuss how to prioritise bumping i.e. most 5^Ò first as in fmap.
edgrif will sort out gaps stuff, needs to be bigger for transcripts but is
already zero for matches, perceived gap is because matches have different
widths according to score.
18/ >> 11. Gene finder not there!
This is probably an otterlace setup bug...
19/ >> 12. Evidence does not display that it has been used with an associated
>> object.
Requires lace to pass zmap extra information, jgrg to work on this.
20/ >> 13. 3-frame and DNA does not get highlighted when you click on
evidence,
>> object or prediction.
edgrif to check with rds if this working, it should be.
21/ >> 14. V-split issues (update of v-split window?):
>> If you save an existing object again, you will get a duplicated object.
>> Cannot display CDS in V-split, have to remove v-split window then save CDS.
>> Duplicated objects (shadowing) when saving to existing objects in 2nd
>> window (correct in 1st window), solved by re-synch.
>> Very unstable when using v-split.
Looks like a problem with updating multiple windows, edgrif/rds to fix.
22/ >> 15. Clicking on gene predictions doesn't let you paste co-ordinates in
>> spandit window on both strands.
About 50% coded, will possibly require coding from James although I'm
hoping not.
23/ >> 16. Protein CDS includes includes stop codon in the aa count.
edgrif will fix.
24/ >> 17. Flanking region of marked area needs to be increased.
User can already do this via lasso mechanism.
Low priority
------------
1/ Feature highlight colour has been fixed but it doesn't work that well for
transcripts where often there is only an outline, we need to highlight more
intelligently so that for features that do not have a fill colour we do
highlight by filling the boxes.
this will be fixed when edgrif has finished the new styles.
2/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
3/ cannot currently cursor through features in a column, there are some
technical problems here to do with raising items so they are visible.
4/ edgrif fixed a performance problem when drawing _all_ homol matches as
gapped. But this relies on slop factor set for the 'Gapped' tag in the
method.
edgrif will sort this out with jgrg, it just requires that the slop factor
is set in the relevant methods.
5/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
6/ we need a "back" button, the new zoom functions make this a lower priority
than before.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
Builds
------
- we now have the mac machine for overnight/regular builds but are having some
library problems which we hope to sort out, in the meantime we can do "hand"
builds via the laptop. We continue to suffer from the macs not properly being
on the network in the sense of being able to see nfs mounted home directories.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
multiple species
----------------
jgrg, edgrif, lg4 and rds met to discuss this and we need to revist it to
check on progress. It requires some alterations to lace infrastructure to
support editting multiple species.
edgrif has inserted the code to allow the user (i.e. lace) to specify that
particular sequences be fetched from particular servers. This allows zmap to
display different species/haplotypes/whatever in split windows. Once the
multiple alignment code is done then then could also be displayed in one
window.
The below notes from a previous meeting are still relevant:
==============================================================================
James and Ed need to discuss how this will be done. Zmap can display multiple
sequences in one zmap window but there will need to changes to the supporting
infrastructure including:
- should the species go in one or multiple acedb databases
- the lace <-> zmap protocol needs to allow specification of
multiple sequence display.
- lace needs to allow the user to pick multiple species
jla1 said a better test than Charlie and NOD mouse is Richard and haplotypes
of which he may have up to 6 (!). jla1 said is there any limit to number,
edgrif said "no, only machine memory....". To quickly test this edgrif will
get data from Richard and try it out to look at performance. Simplest way is
to just display data as is, this mimics what Richard does currently in
fmap. edgrif said that if we used Compara alignment data we could just display
the "sub-blocks" of the alignments that actually contained data. This would
produce much more compact displays.
================== from last time =================================================
2) Other matters
================
Both these items are still pending:
- script for EMBL dumping: needs testing by Jen. James thinks this all
works. There was a discussion about submissions more generally and it was
agreed that all regions going into VEGA should be submitted. This let into a
request for some kind of "Clone status" flag. jgrg said there used to be one
and that it should be recreated.
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
jgrg to think about this.
3) Next Meeting
===============
Will be at XXXXXXXXX
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_03_14 deleted 100755 → 0
+ 0
− 264
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Wednesday 14th March 2007
Attendees: lw2, jgrg, th, edgrif, te3, st3
Steve Trevanion started attending the meetings today to provide a closer link
between annotation efforts in havana/zebra fish and the Vega web site.
1) otterlace + zmap progress
============================
High priority
-------------
1/ Can't get otterid in zmap.
2/ Halfwise hits: No info when you click on them.
3/ Need to redo bumping yet again, Adam has surveyed Havana and says
they "want it to work like it always did". edgrif to sort this out.
Included in this will be taking into account the strand of the nucleotide
sequence. Also the width of matches needs to be checked, its not informative
enough at the moment.
4/ Evidence does not display that it has been used with an associated object.
5/ Clicking on gene predictions doesn?t let you paste co-ordinates in spandit
window on both strands.
6/ highlighting of exons/cds/dna/protein etc does not work.
Medium priority
---------------
1/ Saturated_EST bug: because of some ambiguity if tag usage in acedb methods
these don't get shown in the right way. This will be properly fixed when we
have zmap styles which are completely separate from acedb methods.
edgrif is implementing the new styles now.
2/ DNA finder - Needs to show its find results location on the zmap as in
fmap, would be nice to be colour coded depending on the strand. The finder
needs to be extended to also do protein searches. Searching should be
restricted to any marked region is one is set, edgrif to do this.
edgrif is implementing protein search now, location results to come (note that
currently the user is shown a list of all hits and clicking on a hit takes
the user to that hit).
3/ kj2 would like more information available for features such as the species
and the DE lines. edgrif said they could display this via the current
mechanism of mouse-over popups in the "Info" line at the top of the ZMap. jgrg
is going to make sure this information is in the acedb objects so it can be
exported to zmap.
jgrg, lw2 and edgrif to meet to establish "policy" for which data is displayed
by zmap and which by lace. edgrif said that they will need to establish a
"tag - value" system to make information display more generalised.
4/ zmap needs to get sequences that are in acedb from there for blixem, means
issuing a call to the server to get them but this is possible. NOTE that some
sequences are _only_ in acedb.
5/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif or rds will do this.
6/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
7/ jgrg pointed out a bug in the menu which has a "mark" but not an "unmark"
item. Also, selecting "Set feature for Bump" only marks the selected exon, not
the whole transcript. edgrif will fix these.
8/ Kerstin needs some acedb keyset like functions in lace to allow her to
perform operations on multiple features. jgrg to discuss/implement with kj2.
jgrg and edgrif agreed that the way to do this is to allow users to "detach"
lace from a database, the user then uses xace to do their keyset stuff and
then lace reattaches. This is viable because most users do not do this
kind of operation so why spend large amounts of time reimplementing xace
function.
9/ Highlighting an object hides the CDS.
This will be fixed when new styles come in.
Low priority
------------
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ cannot currently cursor through features in a column, there are some
technical problems here to do with raising items so they are visible.
3/ edgrif fixed a performance problem when drawing _all_ homol matches as
gapped. But this relies on slop factor set for the 'Gapped' tag in the
method.
edgrif will sort this out with jgrg, it just requires that the slop factor
is set in the relevant methods.
4/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
5/ we need a "back" button, the new zoom functions make this a lower priority
than before.
Mulitple alignments
-------------------
multiple alignments: edgrif is about a third of the way through
implementing a more general way of displaying arbitrary blocks. This is a high
priority item.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
a plan for extracting the smap code from acedb and making it a stand alone
package.
Builds
------
- ISG have now built us a separate software stack of the latest stable GTK
realease. We are moving our builds to use this on Linux and the Mac.
- there is still a problem that we do not have a mac on the network that can
so proper single sign on, home directories etc etc.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
multiple species
----------------
jgrg, edgrif, lg4 and rds met to discuss this and we need to revist it to
check on progress. It requires some alterations to lace infrastructure to
support editting multiple species.
edgrif has inserted the code to allow the user (i.e. lace) to specify that
particular sequences be fetched from particular servers. This allows zmap to
display different species/haplotypes/whatever in split windows. Once the
multiple alignment code is done then then could also be displayed in one
window.
The below notes from a previous meeting are still relevant:
==============================================================================
James and Ed need to discuss how this will be done. Zmap can display multiple
sequences in one zmap window but there will need to changes to the supporting
infrastructure including:
- should the species go in one or multiple acedb databases
- the lace <-> zmap protocol needs to allow specification of
multiple sequence display.
- lace needs to allow the user to pick multiple species
jla1 said a better test than Charlie and NOD mouse is Richard and haplotypes
of which he may have up to 6 (!). jla1 said is there any limit to number,
edgrif said "no, only machine memory....". To quickly test this edgrif will
get data from Richard and try it out to look at performance. Simplest way is
to just display data as is, this mimics what Richard does currently in
fmap. edgrif said that if we used Compara alignment data we could just display
the "sub-blocks" of the alignments that actually contained data. This would
produce much more compact displays.
================== from last time =================================================
2) Other matters
================
Both these items are still pending:
- script for EMBL dumping: needs testing by Jen. James thinks this all
works. There was a discussion about submissions more generally and it was
agreed that all regions going into VEGA should be submitted. This let into a
request for some kind of "Clone status" flag. jgrg said there used to be one
and that it should be recreated.
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
jgrg to think about this.
3) Next Meeting
===============
Will be at 2pm, 28th March 2007
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_04_13 deleted 100755 → 0
+ 0
− 300
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Friday 13th April 2007
Attendees: lw2, jgrg, rds, te3, kj2
1) otterlace + zmap progress
============================
High priority
-------------
1/ Can't get otterid in zmap.
kj2 raised the point that searching zmap/lace for a otter id is a
requirement. ZFIN Requests are based on otter ids. jgrg suggested
lace is a good place to implement this. lace knows the data best, can
search for otter id and instruct zmap to spotlight the feature.
Displaying the information in zmap depends on the ability to show tag
- value (below).
2/ Halfwise hits: No info when you click on them.
rds asked if they have a URL object. lw2 pointed out that a domain
description is more important than the URL as it takes time to go to
the webpage for each hit. jgrg suggested it's another use for the tag
- value system (below)
3/ Need to redo bumping yet again, Adam has surveyed Havana and says
they "want it to work like it always did". edgrif to sort this out.
Included in this will be taking into account the strand of the nucleotide
sequence. Also the width of matches needs to be checked, its not informative
enough at the moment.
edgrif has added a further menu option to the bump menu to include
this fMap style bumping. This new version is currently available in
otterlace. The hits are sorted by strand first and then by the
position and overlap with the marked region. This is effectively what
fMap does as it has an implicit marked region which is the area of the
display it's zoomed into.
4/ Evidence does not display that it has been used with an associated object.
We need something to replace the xref of fmap which is displayable in
the treeview. Disucssion on whether the new styles are enough
followed, but although showing evidence in the same column goes some
way, an explicit link would be better. kj2 remarked that some method
of removing the feature from the display once it has been used as
evidence, allowing the visualisation of what's left to build objects
with, could be the ideal solution.
5/ Clicking on gene predictions doesn't let you paste co-ordinates in spandit
window on both strands.
we believe this is fixed.
6/ highlighting of exons/cds/dna/protein etc does not work.
rds has 2/3 of the code for this done. Some of this depends on the new
zmap styles.
Medium priority
---------------
1/ Saturated_EST bug: because of some ambiguity if tag usage in acedb methods
these don't get shown in the right way. This will be properly fixed when we
have zmap styles which are completely separate from acedb methods.
edgrif has implemented the new styles now. Needs discussion with jgrg
on how and when to do the big switch.
2/ DNA finder - Needs to show its find results location on the zmap as in
fmap, would be nice to be colour coded depending on the strand. The finder
needs to be extended to also do protein searches. Searching should be
restricted to any marked region is one is set, edgrif to do this.
edgrif is implementing protein search now, location results to come (note that
currently the user is shown a list of all hits and clicking on a hit takes
the user to that hit).
3/ kj2 would like more information available for features such as the species
and the DE lines. edgrif said they could display this via the current
mechanism of mouse-over popups in the "Info" line at the top of the ZMap. jgrg
is going to make sure this information is in the acedb objects so it can be
exported to zmap.
jgrg, lw2 and edgrif to meet to establish "policy" for which data is displayed
by zmap and which by lace. edgrif said that they will need to establish a
"tag - value" system to make information display more generalised.
rds to set up meeting.
4/ zmap needs to get sequences that are in acedb from there for blixem, means
issuing a call to the server to get them but this is possible. NOTE that some
sequences are _only_ in acedb.
5/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif or rds will do this.
nothing done, but it was noted that NO enduser configuration of
colours should be possible!
6/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
7/ jgrg pointed out a bug in the menu which has a "mark" but not an "unmark"
item. Also, selecting "Set feature for Bump" only marks the selected exon, not
the whole transcript. edgrif will fix these.
rds mentioned there's a possibility that this has been fixed by edgrif.
8/ Kerstin needs some acedb keyset like functions in lace to allow her to
perform operations on multiple features. jgrg to discuss/implement with kj2.
jgrg and edgrif agreed that the way to do this is to allow users to "detach"
lace from a database, the user then uses xace to do their keyset stuff and
then lace reattaches. This is viable because most users do not do this
kind of operation so why spend large amounts of time reimplementing xace
function.
9/ Highlighting an object hides the CDS.
Should be fixed, and depends on the new styles.
10/ Annotation needs to have a history across assembly changes.
kj2 requested that when an assembly changes the objects which get
transferred should have a history as to what they were (otter id)
previously. lw2 remarked that it's possible to search for the old id
in the lace interface, but impossible to retrieve the old object and
display it. jgrg acknowledged there is a bug in the lace searching,
but that providing the history would be difficult. Further
discussion/thought on how to implement this is needed.
Low priority
------------
Consensus was nothing has changed in this section.
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ cannot currently cursor through features in a column, there are some
technical problems here to do with raising items so they are visible.
3/ edgrif fixed a performance problem when drawing _all_ homol matches as
gapped. But this relies on slop factor set for the 'Gapped' tag in the
method.
edgrif will sort this out with jgrg, it just requires that the slop factor
is set in the relevant methods.
4/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
5/ we need a "back" button, the new zoom functions make this a lower priority
than before.
Mulitple alignments
-------------------
multiple alignments: edgrif is about a third of the way through
implementing a more general way of displaying arbitrary blocks. This is a high
priority item.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
a plan for extracting the smap code from acedb and making it a stand alone
package.
Builds
------
- ISG have now built us a separate software stack of the latest stable GTK
realease. We are moving our builds to use this on Linux and the Mac.
- there is still a problem that we do not have a mac on the network that can
so proper single sign on, home directories etc etc.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
multiple species
----------------
jgrg, edgrif, lg4 and rds met to discuss this and we need to revist it to
check on progress. It requires some alterations to lace infrastructure to
support editting multiple species.
edgrif has inserted the code to allow the user (i.e. lace) to specify that
particular sequences be fetched from particular servers. This allows zmap to
display different species/haplotypes/whatever in split windows. Once the
multiple alignment code is done then then could also be displayed in one
window.
The below notes from a previous meeting are still relevant:
==============================================================================
James and Ed need to discuss how this will be done. Zmap can display multiple
sequences in one zmap window but there will need to changes to the supporting
infrastructure including:
- should the species go in one or multiple acedb databases
- the lace <-> zmap protocol needs to allow specification of
multiple sequence display.
- lace needs to allow the user to pick multiple species
jla1 said a better test than Charlie and NOD mouse is Richard and haplotypes
of which he may have up to 6 (!). jla1 said is there any limit to number,
edgrif said "no, only machine memory....". To quickly test this edgrif will
get data from Richard and try it out to look at performance. Simplest way is
to just display data as is, this mimics what Richard does currently in
fmap. edgrif said that if we used Compara alignment data we could just display
the "sub-blocks" of the alignments that actually contained data. This would
produce much more compact displays.
================== from last time =================================================
2) Other matters
================
Both these items are still pending:
- script for EMBL dumping: needs testing by Jen. James thinks this all
works. There was a discussion about submissions more generally and it was
agreed that all regions going into VEGA should be submitted. This let into a
request for some kind of "Clone status" flag. jgrg said there used to be one
and that it should be recreated.
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
jgrg to think about this.
3) Next Meeting
===============
Will be at 2pm, 25th April 2007
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_04_23 deleted 100755 → 0
+ 0
− 234
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Wednesday 23rd April 2007
Attendees: jgrg, edgrif, te3, st3
1) otterlace + zmap progress
============================
High priority
-------------
1/ Can't get otterid in zmap.
kj2 raised the point that searching zmap/lace for a otter id is a requirement.
ZFIN Requests are based on otter ids. jgrg suggested lace is a good place to
implement this. lace knows the data best, can search for otter id and instruct
zmap to spotlight the feature. Displaying the information in zmap depends on
the ability to show tag - value (below).
2/ Display of tag-values by zmap
edgrif, jgrg, rds and lg4 have met and agreed a plan for this. edgrif is
implementing a new version of the individual feature display code which will
do the following:
- make reuse of existing feature windows the default to avoid loads of
windows.
- make the feature display window into a "tabbed" style window to avoid the
window being too huge.
- add tag-value information that will be cut/pastable in a generalised way
that is readily extensible
An important development of this is the realisation that instead of passing
all information across via the server for every feature, zmap will ask lace
for the information for the individual feature. This is more flexible and
avoids excessive amounts of data being passed across when zmap starts up.
The following are all candidates to be displayed:
- Halfwise hits (rds asked if they have a URL object. lw2 pointed out that a
domain description is more important than the URL as it takes time to go to
the webpage for each hit.
- kj2 would like more information available for features such as the species
and the DE lines. edgrif said they could display this via the current
mechanism of mouse-over popups in the "Info" line at the top of the ZMap. jgrg
is going to make sure this information is in the acedb objects so it can be
exported to zmap.
- Evidence does not display that it has been used with an associated object.
We need something to replace the xref of fmap which is displayable in the
treeview. Disucssion on whether the new styles are enough followed, but
although showing evidence in the same column goes some way, an explicit link
would be better. kj2 remarked that some method of removing the feature from
the display once it has been used as evidence, allowing the visualisation of
what's left to build objects with, could be the ideal solution.
3/ highlighting of exons/cds/dna/protein etc does not work.
rds has 2/3 of the code for this done. Some of this depends on the new zmap
styles.
4/ New zmap styles
edgrif has now implemented this (with inheritance), jgrg and edgrif need
to decide when to do the big swop.
This will fix the following problems:
Saturated_EST bug: because of some ambiguity if tag usage in acedb methods
these don't get shown in the right way. This will be properly fixed when we
have zmap styles which are completely separate from acedb methods.
Medium priority
---------------
1/ DNA finder - Needs to show its find results location on the zmap as in
fmap, would be nice to be colour coded depending on the strand. The finder
needs to be extended to also do protein searches. Searching should be
restricted to any marked region is one is set, edgrif to do this.
edgrif is implementing protein search now, location results to come (note that
currently the user is shown a list of all hits and clicking on a hit takes
the user to that hit).
2/ zmap needs to get sequences that are in acedb from there for blixem, means
issuing a call to the server to get them but this is possible. NOTE that some
sequences are _only_ in acedb.
3/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif or rds will do this.
nothing done, but it was noted that NO enduser configuration of
colours should be possible!
4/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
5/ Annotation needs to have a history across assembly changes.
kj2 requested that when an assembly changes the objects which get
transferred should have a history as to what they were (otter id)
previously. lw2 remarked that it's possible to search for the old id
in the lace interface, but impossible to retrieve the old object and
display it. jgrg acknowledged there is a bug in the lace searching,
but that providing the history would be difficult. Further
discussion/thought on how to implement this is needed.
Low priority
------------
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ cannot currently cursor through features in a column, there are some
technical problems here to do with raising items so they are visible.
3/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
4/ we need a "back" button, the new zoom functions make this a lower priority
than before.
Mulitple alignments
-------------------
multiple alignments: edgrif is about a third of the way through implementing a
more general way of displaying arbitrary blocks. This will become a high
priority item as we move to haplotypes etc.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
a plan for extracting the smap code from acedb and making it a stand alone
package.
Builds
------
- We now have the latest GTK (2.10) for linux and are moving to it. We need to
move to it for macs as well.
- there is still a problem that we do not have a mac on the network that can
so proper single sign on, home directories etc etc.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
2) Other matters
================
Both these items are still pending:
- script for EMBL dumping: needs testing by Jen. James thinks this all
works. There was a discussion about submissions more generally and it was
agreed that all regions going into VEGA should be submitted. This let into a
request for some kind of "Clone status" flag. jgrg said there used to be one
and that it should be recreated.
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
jgrg to think about this.
3) Next Meeting
===============
Will be at 2pm, 9th May 2007
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_05_09 deleted 100755 → 0
+ 0
− 234
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Wednesday 23rd April 2007
Attendees: jgrg, edgrif, te3, st3
1) otterlace + zmap progress
============================
High priority
-------------
1/ Can't get otterid in zmap.
kj2 raised the point that searching zmap/lace for a otter id is a requirement.
ZFIN Requests are based on otter ids. jgrg suggested lace is a good place to
implement this. lace knows the data best, can search for otter id and instruct
zmap to spotlight the feature. Displaying the information in zmap depends on
the ability to show tag - value (below).
2/ Display of tag-values by zmap
edgrif, jgrg, rds and lg4 have met and agreed a plan for this. edgrif is
implementing a new version of the individual feature display code which will
do the following:
- make reuse of existing feature windows the default to avoid loads of
windows.
- make the feature display window into a "tabbed" style window to avoid the
window being too huge.
- add tag-value information that will be cut/pastable in a generalised way
that is readily extensible
An important development of this is the realisation that instead of passing
all information across via the server for every feature, zmap will ask lace
for the information for the individual feature. This is more flexible and
avoids excessive amounts of data being passed across when zmap starts up.
The following are all candidates to be displayed:
- Halfwise hits (rds asked if they have a URL object. lw2 pointed out that a
domain description is more important than the URL as it takes time to go to
the webpage for each hit.
- kj2 would like more information available for features such as the species
and the DE lines. edgrif said they could display this via the current
mechanism of mouse-over popups in the "Info" line at the top of the ZMap. jgrg
is going to make sure this information is in the acedb objects so it can be
exported to zmap.
- Evidence does not display that it has been used with an associated object.
We need something to replace the xref of fmap which is displayable in the
treeview. Disucssion on whether the new styles are enough followed, but
although showing evidence in the same column goes some way, an explicit link
would be better. kj2 remarked that some method of removing the feature from
the display once it has been used as evidence, allowing the visualisation of
what's left to build objects with, could be the ideal solution.
3/ highlighting of exons/cds/dna/protein etc does not work.
rds has 2/3 of the code for this done. Some of this depends on the new zmap
styles.
4/ New zmap styles
edgrif has now implemented this (with inheritance), jgrg and edgrif need
to decide when to do the big swop.
This will fix the following problems:
Saturated_EST bug: because of some ambiguity if tag usage in acedb methods
these don't get shown in the right way. This will be properly fixed when we
have zmap styles which are completely separate from acedb methods.
Medium priority
---------------
1/ DNA finder - Needs to show its find results location on the zmap as in
fmap, would be nice to be colour coded depending on the strand. The finder
needs to be extended to also do protein searches. Searching should be
restricted to any marked region is one is set, edgrif to do this.
edgrif is implementing protein search now, location results to come (note that
currently the user is shown a list of all hits and clicking on a hit takes
the user to that hit).
2/ zmap needs to get sequences that are in acedb from there for blixem, means
issuing a call to the server to get them but this is possible. NOTE that some
sequences are _only_ in acedb.
3/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif or rds will do this.
nothing done, but it was noted that NO enduser configuration of
colours should be possible!
4/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
5/ Annotation needs to have a history across assembly changes.
kj2 requested that when an assembly changes the objects which get
transferred should have a history as to what they were (otter id)
previously. lw2 remarked that it's possible to search for the old id
in the lace interface, but impossible to retrieve the old object and
display it. jgrg acknowledged there is a bug in the lace searching,
but that providing the history would be difficult. Further
discussion/thought on how to implement this is needed.
Low priority
------------
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ cannot currently cursor through features in a column, there are some
technical problems here to do with raising items so they are visible.
3/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
4/ we need a "back" button, the new zoom functions make this a lower priority
than before.
Mulitple alignments
-------------------
multiple alignments: edgrif is about a third of the way through implementing a
more general way of displaying arbitrary blocks. This will become a high
priority item as we move to haplotypes etc.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
a plan for extracting the smap code from acedb and making it a stand alone
package.
Builds
------
- We now have the latest GTK (2.10) for linux and are moving to it. We need to
move to it for macs as well.
- there is still a problem that we do not have a mac on the network that can
so proper single sign on, home directories etc etc.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
2) Other matters
================
Both these items are still pending:
- script for EMBL dumping: needs testing by Jen. James thinks this all
works. There was a discussion about submissions more generally and it was
agreed that all regions going into VEGA should be submitted. This let into a
request for some kind of "Clone status" flag. jgrg said there used to be one
and that it should be recreated.
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
jgrg to think about this.
3) Next Meeting
===============
Will be at 2pm, 23rd May 2007
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_06_06 deleted 100755 → 0
+ 0
− 265
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Wednesday 6th June 2007
Attendees: jgrg, edgrif, te3, st3............
1) otterlace + zmap progress
============================
High priority
-------------
0/ Performance
Issue raised by Laurens and others that we have "turned a blind eye to" until
now.
- basic performance
We knew there was a problem in glib, part of the gtk library we use for graphics.
This is now fixed and produces dramatic speed ups in parsing of data in zmap.
In addition as we have now moved on to gtk 2.10 we use their new improved slice
allocator for memory allocation which improves performance substantially.
- a new canvas
rds has been looking at alternative canvas implementations which offer an MVC
model. He has managed to get goocanvas developers to fix some bugs and make
some changes to support our needs.
the goocanvas MVC model will mean we do not have to copy data to split windows
meaning greatly reduced memory usage.
the goocanvas will cope automatically with the X Windows window size limit, this
combined with changes in the gtk scrolling model means we will be able to do away
with having two scroll bars.
We plan to introduce this in the Autumn.
1/ Can't get otterid in zmap.
kj2 raised the point that searching zmap/lace for a otter id is a requirement.
ZFIN Requests are based on otter ids. jgrg suggested lace is a good place to
implement this. lace knows the data best, can search for otter id and instruct
zmap to spotlight the feature. Displaying the information in zmap depends on
the ability to show tag - value (below).
2/ Display of tag-values by zmap
I'm working on this now......
edgrif, jgrg, rds and lg4 have met and agreed a plan for this. edgrif is
implementing a new version of the individual feature display code which will
do the following:
- make reuse of existing feature windows the default to avoid loads of
windows.
- make the feature display window into a "tabbed" style window to avoid the
window being too huge.
- add tag-value information that will be cut/pastable in a generalised way
that is readily extensible
An important development of this is the realisation that instead of passing
all information across via the server for every feature, zmap will ask lace
for the information for the individual feature. This is more flexible and
avoids excessive amounts of data being passed across when zmap starts up.
The following are all candidates to be displayed:
- Halfwise hits (rds asked if they have a URL object. lw2 pointed out that a
domain description is more important than the URL as it takes time to go to
the webpage for each hit.
- kj2 would like more information available for features such as the species
and the DE lines. edgrif said they could display this via the current
mechanism of mouse-over popups in the "Info" line at the top of the ZMap. jgrg
is going to make sure this information is in the acedb objects so it can be
exported to zmap.
- Evidence does not display that it has been used with an associated object.
We need something to replace the xref of fmap which is displayable in the
treeview. Disucssion on whether the new styles are enough followed, but
although showing evidence in the same column goes some way, an explicit link
would be better. kj2 remarked that some method of removing the feature from
the display once it has been used as evidence, allowing the visualisation of
what's left to build objects with, could be the ideal solution.
3/ highlighting of exons/cds/dna/protein etc does not work.
rds has fixed this...yippeeee
4/ New zmap styles
edgrif has now implemented this (with inheritance), jgrg and edgrif need
to decide when to do the big swop.
This will fix the following problems:
Saturated_EST bug: because of some ambiguity if tag usage in acedb methods
these don't get shown in the right way. This will be properly fixed when we
have zmap styles which are completely separate from acedb methods.
Medium priority
---------------
0/ Homology gaps display - in future homolgy gaps will not be displayed
normally. Instead they will be displayed when the user bumps a column.
This will save a lot of mostly wasted processing, especially if the user
makes use of the "mark" method of restricting how much is bumped.
1/ DNA finder - Needs to show its find results location on the zmap as in
fmap, would be nice to be colour coded depending on the strand. The finder
needs to be extended to also do protein searches. Searching should be
restricted to any marked region is one is set, edgrif to do this.
edgrif is implementing protein search now, location results to come (note that
currently the user is shown a list of all hits and clicking on a hit takes
the user to that hit).
2/ zmap needs to get sequences that are in acedb from there for blixem, means
issuing a call to the server to get them but this is possible. NOTE that some
sequences are _only_ in acedb.
3/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif or rds will do this.
nothing done, but it was noted that NO enduser configuration of
colours should be possible!
4/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
5/ Annotation needs to have a history across assembly changes.
kj2 requested that when an assembly changes the objects which get
transferred should have a history as to what they were (otter id)
previously. lw2 remarked that it's possible to search for the old id
in the lace interface, but impossible to retrieve the old object and
display it. jgrg acknowledged there is a bug in the lace searching,
but that providing the history would be difficult. Further
discussion/thought on how to implement this is needed.
Low priority
------------
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ cannot currently cursor through features in a column, there are some
technical problems here to do with raising items so they are visible.
3/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
4/ we need a "back" button, the new zoom functions make this a lower priority
than before.
Multiple alignments
-------------------
multiple alignments: edgrif is about a third of the way through implementing a
more general way of displaying arbitrary blocks. This will become a high
priority item as we move to haplotypes etc.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
a plan for extracting the smap code from acedb and making it a stand alone
package.
Builds
------
- We now have the latest GTK (2.10) for linux and are moving to it. We need to
move to it for macs as well.
- there is still a problem that we do not have a mac on the network that can
so proper single sign on, home directories etc etc. Ed to raise a help ticket.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
2) Other matters
================
Both these items are still pending:
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
Mustapha is working on this.
3) Next Meeting
===============
Will be at 2pm, 20th June 2007
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_06_14 deleted 100755 → 0
+ 0
− 126
View file @ cf47b0aa
==============================================================================
ZMap/lace sub-meeting
14/06/2007
jgrg, rds, edgrif
1) ZMap <-> lace communication
We need to check that lace and zmap behave correctly when either
quits in a controlled way. This is vital if annotators are to be
able to restart zmap from lace in a controlled way.
Ed/Roy have done quite a lot of work on zmap to ensure that it sends
commands in the correct way to clear up.
James to check that lace also clears up correctly.
Roy has done a lot of work to improve the xremote codes handling and
tracking of its own state.
NOTE that we still have a hole in that we don't have a good way for
lace to "notice" that zmap has died unexpectedly.
lace does not support the "single_select" request from zmap, nor
does it make "single_select" requests to zmap. This needs doing to
support feature highlighting.
2) otterids
Display of otterids is still outstanding and is essential. The
current plan is for this to happen in lace, not in zmap (although
with the new tagvalue display the otterid can be displayed in zmap
as well).
3) TagValue display
Ed has been working on this and its now complete. The data is displayed
in the usual "notebook" or "tabbed" style window. Some of the data
comes directly from zmap and some of it can come from lace.
When the user selects the feature menu "Show Feature Details" item,
zmap sends an xremote request to lace for extra feature details. lace
can then return information as xml in the form of pages containing
paragraphs containing tagvalues in a number of formats.
lace will need to support the new "feature_details" request and
reply with data in the form:
<zmap>
<response>
<notebook>
<page name="NNN">
<paragraph name="NNN" type="TTT">
<tagvalue name="NNN" type="TTT">
The contents of first tag
</tagvalue>
</paragraph>
</page>
</notebook>
</response>
</zmap>
The page, paragraph and tagvalue elements can be repeated as often as
required but must be nested as above.
Page element:
The "name" attribute is compulsory.
Paragraph element:
The "name" attribute is optional.
The type attribute must be one of:
"simple" tagvalues will be a simple vertical list.
"tagvalue_table" tagvalues will be aligned in a table.
"homogenous" as for "tagvalue_table" but all tagvalues should
have the same tag which will only be displayed once.
(default is "simple")
Tagvalue element:
The "name" attribute is compulsory.
The type attribute must be one of:
"simple" the value is displayed in a single line text widget
"scrolled_text" the value is displayed in a multiline/scrolled window
(default is "simple")
The content fo the tagvalue must be text.
4) New styles
Code is all waiting, we just need to do the big switch.
5) Mac builds
Both Roy and Ed have worked on the build system to make it easier/quicker
to do mac builds. Currently we are waiting to get GTK 2.10 installed on
our iMac and then the build should be automated.
6) The plan
James is to get a "test otterlace" system of some sort going before his
C++ course next week so Roy and Ed can try the latest zmap out with a
couple of annotators.
Ed is to finish the tagvalue code.
After the C++ course James, Ed and Roy will tie up all the current loose
ends that are preventing annotators from using zmap.
ZMAP_LACE_PROJECT/zmap_lace.2007_07_04 deleted 100755 → 0
+ 0
− 223
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Wednesday 4th July 2007
Attendees: th, edgrif, te3, lw2, eah
1) otterlace + zmap progress
============================
High priority
-------------
1/ Can't get otterid in zmap.
kj2 raised the point that searching zmap/lace for a otter id is a requirement.
ZFIN Requests are based on otter ids. jgrg suggested lace is a good place to
implement this. lace knows the data best, can search for otter id and instruct
zmap to spotlight the feature. Displaying the information in zmap depends on
the ability to show tag - value (below).
2/ Display of tag-values by zmap
The code has been implemented in zmap to dynamically build tabbed pages from
xml content sent from lace. The following remain to be added:
- Halfwise hits (rds asked if they have a URL object. lw2 pointed out that a
domain description is more important than the URL as it takes time to go to
the webpage for each hit.
- kj2 would like more information available for features such as the species
and the DE lines. edgrif said they could display this via the current
mechanism of mouse-over popups in the "Info" line at the top of the ZMap. jgrg
is going to make sure this information is in the acedb objects so it can be
exported to zmap.
- Evidence does not display that it has been used with an associated object.
We need something to replace the xref of fmap which is displayable in the
treeview. Discussion on whether the new styles are enough followed, but
although showing evidence in the same column goes some way, an explicit link
would be better. kj2 remarked that some method of removing the feature from
the display once it has been used as evidence, allowing the visualisation of
what's left to build objects with, could be the ideal solution.
3/ New zmap styles
edgrif has now implemented this (with inheritance), jgrg needs
to decide when to do the big swop.
4/ Single select
lace does not support the "single_select" request from zmap, nor
does it make "single_select" requests to zmap. This needs doing to
support feature highlighting.
5/ Demo
edgrif & eah will organise a zmap/havana demo to make remind everyone of
the way to use zmap.
Medium priority
---------------
1/ DNA finder - Needs to show its find results location on the zmap as in
fmap, would be nice to be colour coded depending on the strand. The finder
needs to be extended to also do protein searches. Searching should be
restricted to any marked region is one is set, edgrif to do this.
edgrif is implementing protein search now, location results to come (note that
currently the user is shown a list of all hits and clicking on a hit takes
the user to that hit).
2/ zmap needs to get sequences that are in acedb from there for blixem, means
issuing a call to the server to get them but this is possible. NOTE that some
sequences are _only_ in acedb. edgrif is doing this now.
3/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
4/ Annotation needs to have a history across assembly changes.
kj2 requested that when an assembly changes the objects which get
transferred should have a history as to what they were (otter id)
previously. lw2 remarked that it's possible to search for the old id
in the lace interface, but impossible to retrieve the old object and
display it. jgrg acknowledged there is a bug in the lace searching,
but that providing the history would be difficult. Further
discussion/thought on how to implement this is needed.
Low priority
------------
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ cannot currently cursor through features in a column, there are some
technical problems here to do with raising items so they are visible.
edgrif doing this now.
3/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
4/ we need a "back" button, the new zoom functions make this a lower priority
than before.
5/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif or rds will do this.
nothing done, but it was noted that NO enduser configuration of
colours should be possible!
A new canvas
------------
rds has been looking at alternative canvas implementations which offer an MVC
model. He has managed to get goocanvas developers to fix some bugs and make
some changes to support our needs.
the goocanvas MVC model will mean we do not have to copy data to split windows
meaning greatly reduced memory usage.
the goocanvas will cope automatically with the X Windows window size limit, this
combined with changes in the gtk scrolling model means we will be able to do away
with having two scroll bars.
We plan to introduce this in the Autumn.
Multiple alignments
-------------------
multiple alignments: edgrif is about a third of the way through implementing a
more general way of displaying arbitrary blocks. This will become a high
priority item as we move to haplotypes etc.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
a plan for extracting the smap code from acedb and making it a stand alone
package.
Builds
------
We now have a properly networked Mac, we need to include universal binaries.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
2) Other matters
================
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
Mustapha is working on this.
3) Next Meeting
===============
Will be at 2pm, 18th July 2007
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_08_15 deleted 100755 → 0
+ 0
− 190
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Wednesday 15th August 2007
Attendees: jgrg, lw2, edgrif, te3
1) otterlace + zmap progress
============================
High priority
-------------
0/ ZMap performance
The only issue here is caused by the huge numbers of homologies. There is much
confusion here as there are several confounding factors:
- slow machines
- slow network meaning slow startup/perceived time
- otter pipeline problems meaning that vast numbers of useless homologies
sometimes get through
- bumping is adversely affected by duplicated regions, current algorithm tries
to join up the regions, EG to deal with this.
I plan to do some profiling/statistics to get some facts/figures.
I have a couple of plans to deal with issues such as repeated regions which
create problems for my bumping algorithm.
1/ New zmap styles *************
edgrif has now implemented this (with inheritance), jgrg needs
to decide when to do the big swop.
Medium priority
---------------
1/ DNA finder - Needs to show its find results location on the zmap as in
fmap, would be nice to be colour coded depending on the strand. The finder
needs to be extended to also do protein searches. Searching should be
restricted to any marked region is one is set, edgrif to do this.
edgrif is implementing protein search now, location results to come (note that
currently the user is shown a list of all hits and clicking on a hit takes
the user to that hit).
2/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
3/ Annotation needs to have a history across assembly changes.
kj2 requested that when an assembly changes the objects which get
transferred should have a history as to what they were (otter id)
previously. lw2 remarked that it's possible to search for the old id
in the lace interface, but impossible to retrieve the old object and
display it. jgrg acknowledged there is a bug in the lace searching,
but that providing the history would be difficult. Further
discussion/thought on how to implement this is needed.
Low priority
------------
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
3/ we need a "back" button, the new zoom functions make this a lower priority
than before.
4/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif or rds will do this.
nothing done, but it was noted that NO enduser configuration of
colours should be possible!
A new canvas
------------
rds has been looking at alternative canvas implementations which offer an MVC
model. He has managed to get goocanvas developers to fix some bugs and make
some changes to support our needs.
the goocanvas MVC model will mean we do not have to copy data to split windows
meaning greatly reduced memory usage.
the goocanvas will cope automatically with the X Windows window size limit, this
combined with changes in the gtk scrolling model means we will be able to do away
with having two scroll bars.
We plan to introduce this in the Autumn.
Multiple alignments
-------------------
multiple alignments: edgrif is about a third of the way through implementing a
more general way of displaying arbitrary blocks. This will become a high
priority item as we move to haplotypes etc.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
a plan for extracting the smap code from acedb and making it a stand alone
package.
Builds
------
We now have a properly networked Mac, we need to include universal binaries.
jgrg, edgrif & rds to work on this.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
2) Other matters
================
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
Mustapha is working on this.
3) Next Meeting
===============
Will be at 2pm, 29th August 2007
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_09_12 deleted 100755 → 0
+ 0
− 211
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Wednesday 15th August 2007
Attendees: th, edgrif, rds, jgrg, lw2, te3, st3
1) otterlace + zmap progress
============================
High priority
-------------
0/ ZMap performance
The only issue here is caused by the huge numbers of homologies.
rds and edgrif have applied a number of fixes and we await feedback
from users, initial feedback has been good.
There is still a problem with the pipeline and pathological conditions
that produce huge numbers of essentially useless homologies.
1/ New zmap styles *************
edgrif has now implemented this (with inheritance), jgrg needs
to decide when to do the big swop. Waiting for jgrg.
2/ Display of otter information
edgrif and rds have implemented code in zmap to deal with otter ids etc but lace
needs to export these so we can display them.
3/ Vega
can vega be built using the new otter schema ?
4/ Ticket priority
edgrif and rds need to sit down with Havana and reasign ticket priorities as there are
too many on priority 7 making it impossible to prioritise.
Medium priority
---------------
1/ DNA finder - Needs to show its find results location on the zmap as in
fmap, would be nice to be colour coded depending on the strand. The finder
needs to be extended to also do protein searches. Searching should be
restricted to any marked region is one is set, edgrif to do this.
edgrif is implementing protein search now, location results to come (note that
currently the user is shown a list of all hits and clicking on a hit takes
the user to that hit).
2/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
3/ Annotation needs to have a history across assembly changes.
kj2 requested that when an assembly changes the objects which get
transferred should have a history as to what they were (otter id)
previously. lw2 remarked that it's possible to search for the old id
in the lace interface, but impossible to retrieve the old object and
display it. jgrg acknowledged there is a bug in the lace searching,
but that providing the history would be difficult. Further
discussion/thought on how to implement this is needed.
4/ look no mouse
edgrif has implemented various ways of navigating which mean that
zmap can largely be used without touching the mouse.
5/ removing evidence already used
annotators would like to be able to remove from display homologies that
have already been used to annotate variants etc. Does this need to be
persistent in the database in some way ??
Low priority
------------
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
We need a test database for this.
3/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif or rds will do this.
nothing done, but it was noted that NO enduser configuration of
colours should be possible!
A new canvas
------------
rds has been looking at alternative canvas implementations which offer an MVC
model. He has managed to get goocanvas developers to fix some bugs and make
some changes to support our needs.
the goocanvas MVC model will mean we do not have to copy data to split windows
meaning greatly reduced memory usage.
the goocanvas will cope automatically with the X Windows window size limit, this
combined with changes in the gtk scrolling model means we will be able to do away
with having two scroll bars.
We plan to introduce this in the Autumn by which time it is likely to have become
part of gtk as _the_ gtk canvas.
Multiple alignments
-------------------
multiple alignments: edgrif is about a third of the way through implementing a
more general way of displaying arbitrary blocks. This will become a high
priority item as we move to haplotypes etc.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
a plan for extracting the smap code from acedb and making it a stand alone
package.
Builds
------
We now have a properly networked Mac, we need to include universal binaries.
jgrg, edgrif & rds to work on this.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
- another issue is to incorporate James proxy into blixem and zmap, input
needed from jgrg for this.
2) Other matters
================
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
Mustapha is working on this.
3) Next Meeting
===============
Will be at 2pm, 26th September 2007
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_09_26 deleted 100755 → 0
+ 0
− 218
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Wednesday 26th September 2007
Attendees: th, eah, edgrif, jgrg, lw2, te3, st3
1) otterlace + zmap progress
============================
High priority
-------------
0/ ZMap performance
edgrif & rds still awaiting feedback.
There is still a problem with the pipeline and pathological conditions
that produce huge numbers of essentially useless homologies. jgrg is
thinking about how to do this. edgrif said he could add a warning message
to report excessive numbers of hits so that at least users would be aware
of any problem.
1/ New zmap styles *************
edgrif has now implemented this (with inheritance), jgrg needs
to decide when to do the big swop. jgrg said with the new schema
work now almost done he is in a position to do this.
2/ Display of otter information
edgrif and rds have implemented code in zmap to deal with otter ids etc but lace
needs to export these so we can display them. jgrg said with the new schema
work now almost done he is in a position to do this.
3/ Vega
can vega be built using the new otter schema ? st3 said not yet buts its on the way.
4/ Ticket priority
edgrif and rds went through all tickets with eah and jpa and recategorised
all tickets. This resulted in many being resolved. Currently we are down to
15 tickets with none in category 7. edgrif explained that he added a new
ticket field which was a text version of the seven ticket categories so that
Havana could just set one of these and forget all the other fields. edgrif
will readvertise this over the next couple of weeks.
Medium priority
---------------
1/ locator column: zmap needs a locator column as per fmap which could be
used to display dna and peptide search results and other information.
2/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
3/ Annotation needs to have a history across assembly changes.
kj2 requested that when an assembly changes the objects which get
transferred should have a history as to what they were (otter id)
previously. lw2 remarked that it's possible to search for the old id
in the lace interface, but impossible to retrieve the old object and
display it. jgrg acknowledged there is a bug in the lace searching,
but that providing the history would be difficult. Further
discussion/thought on how to implement this is needed.
jgrg said that this should be more possible with the new ensembl schema.
4/ look no mouse
edgrif has implemented various ways of navigating which mean that
zmap can largely be used without touching the mouse. Waiting for feedback.
edgrif to readvertise shortcuts with next zmap release. Will also check
about lassoing and why it isn't just button 1 down/drag.
5/ removing evidence already used
annotators would like to be able to remove from display homologies that
have already been used to annotate variants etc. Does this need to be
persistent in the database in some way ?? edgrif & jgrg will get
together to arrange this via styles so it can persist in a natural way
in the database.
Low priority
------------
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
We need a test database for this. jgrg said this would come soon.
3/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif or rds will do this but are waiting for eah and lw2 to report back with
list of what users would like to be able to configure.
A new canvas
------------
rds has been looking at alternative canvas implementations which offer an MVC
model. He has managed to get goocanvas developers to fix some bugs and make
some changes to support our needs.
the goocanvas MVC model will mean we do not have to copy data to split windows
meaning greatly reduced memory usage.
the goocanvas will cope automatically with the X Windows window size limit, this
combined with changes in the gtk scrolling model means we will be able to do away
with having two scroll bars.
We plan to introduce this in the Autumn when it has become part of gtk
as _the_ gtk canvas.
Multiple alignments
-------------------
multiple alignments: edgrif is about a third of the way through implementing a
more general way of displaying arbitrary blocks. This will become a high
priority item as we move to haplotypes etc.
th said this would be needed soon so it should be moved up the priority list.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
a plan for extracting the smap code from acedb and making it a stand alone
package.
Builds
------
We now have a properly networked Mac, we need to include universal binaries.
jgrg, edgrif & rds to work on this. edgrif working on installing autoconf
stuff on the mac, needed to build our special foocanvas version. Once that
has been done we wil harmonise with jgrg's script for building lace installs.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
- another issue is to incorporate James proxy into blixem and zmap, input
needed from jgrg for this.
2) Other matters
================
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
Mustapha is working on this.
3) Next Meeting
===============
Will be at 2pm, 10th October 2007
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_10_11 deleted 100755 → 0
+ 0
− 253
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Thursday 11 October 2007
Attendees: th, eah, edgrif, jgrg, lw2, te3, st3, jla1
1) otterlace + zmap progress
============================
High priority
-------------
0/ ZMap performance
edgrif & rds still awaiting feedback.
There is still a problem with the pipeline and pathological conditions
that produce huge numbers of essentially useless homologies. jgrg is
thinking about how to do this.
edgrif explained two possibilities for improving performance:
- make sgifaceserver stream data rather than batch it up, would
save a lot of memory.
- deferred loading, only load features when needed and load in
zone requested by user.
jla1 said there was still a problem with bumping, edgrif to investigate
further.
edgrif is to follow up installing X performance tools on linux/mac so we
measure performance identify poorly performing/badly configured boxes.
1/ New zmap styles *************
edgrif has now implemented this (with inheritance), jgrg needs
to decide when to do the big swop. jgrg said with the new schema
work now almost done he is in a position to do this.
should be done this week.
2/ Display of otter information
edgrif and rds have implemented code in zmap to deal with otter ids etc but lace
needs to export these so we can display them. jgrg said with the new schema
work now almost done he is in a position to do this.
should be done this week.
3/ Vega
can vega be built using the new otter schema ? st3 said not yet buts its on the way,
should be here in a week or two.
4/ Ticket priority
eah will talk about RT and raising tickets at next Havana meeting. edgrif
will implement a menu to take users directly to relevant pages to raise
tickets.
5/ CDS translation
rds is working on showing all possible translations etc in zmap window.
This is his current top priority.
6/ Blixem
edgrif will set up an option so that blixem can be run on swissprot and trembl
entries simultaneously.
Medium priority
---------------
1/ locator column: zmap needs a locator column as per fmap which could be
used to display dna and peptide search results and other information.
2/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
3/ Annotation needs to have a history across assembly changes.
kj2 requested that when an assembly changes the objects which get
transferred should have a history as to what they were (otter id)
previously. lw2 remarked that it's possible to search for the old id
in the lace interface, but impossible to retrieve the old object and
display it. jgrg acknowledged there is a bug in the lace searching,
but that providing the history would be difficult. Further
discussion/thought on how to implement this is needed.
jgrg said that this should be more possible with the new ensembl schema.
4/ look no mouse
edgrif has implemented various ways of navigating which mean that
zmap can largely be used without touching the mouse. Waiting for feedback.
edgrif to readvertise shortcuts with next zmap release. Will also check
about lassoing and why it isn't just button 1 down/drag.
we discussed the option of having a flag to remove mouse usage, would be
good for training and also for experienced users to get them to use
the keyboard short cuts.
5/ removing evidence already used
annotators would like to be able to remove from display homologies that
have already been used to annotate variants etc. Does this need to be
persistent in the database in some way ?? edgrif & jgrg will get
together to arrange this via styles so it can persist in a natural way
in the database.
6/ zmap width
Because of the way zmap works, screen space can be used up by columns
that have nothing in them for the coordinate range the user is looking
at. edgrif will look at a compress button to hide columns where this
is true.
Low priority
------------
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
We need a test database for this. jgrg said this would come soon.
3/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif or rds will do this but are waiting for eah and lw2 to report back with
list of what users would like to be able to configure.
A new canvas
------------
rds has been looking at alternative canvas implementations which offer an MVC
model. He has managed to get goocanvas developers to fix some bugs and make
some changes to support our needs.
the goocanvas MVC model will mean we do not have to copy data to split windows
meaning greatly reduced memory usage.
the goocanvas will cope automatically with the X Windows window size limit, this
combined with changes in the gtk scrolling model means we will be able to do away
with having two scroll bars.
We plan to introduce this in the Autumn when it has become part of gtk
as _the_ gtk canvas.
Multiple alignments
-------------------
multiple alignments: edgrif is about a third of the way through implementing a
more general way of displaying arbitrary blocks. This will become a high
priority item as we move to haplotypes etc.
th said this would be needed soon so it should be moved up the priority list.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
a plan for extracting the smap code from acedb and making it a stand alone
package.
Builds
------
We now have a properly networked Mac, we need to include universal binaries.
jgrg, edgrif & rds to work on this. edgrif working on installing autoconf
stuff on the mac, needed to build our special foocanvas version. Once that
has been done we wil harmonise with jgrg's script for building lace installs.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
- another issue is to incorporate James proxy into blixem and zmap, input
needed from jgrg for this.
2) Other matters
================
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
Mustapha is working on this.
3) Next Meeting
===============
Will be at 2pm, 10th October 2007
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_10_25 deleted 100755 → 0
+ 0
− 246
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Thursday 25th October 2007
Attendees: edgrif, jgrg, lw2, st3, jla1
1) otterlace + zmap progress
============================
High priority
-------------
0/ ZMap performance
edgrif & rds still awaiting feedback.
There is still a problem with the pipeline and pathological conditions
that produce huge numbers of essentially useless homologies. jgrg is
thinking about how to do this.
edgrif investigating two possibilities for improving performance:
- make sgifaceserver stream data rather than batch it up, would
save a lot of memory.
- deferred loading, only load features when needed and load in
zone requested by user.
edgrif is to follow up installing X performance tools on linux/mac so we
measure performance identify poorly performing/badly configured boxes.
1/ Bumping
jla1 had reported performance problems with bumping, edgrif has implemented
"compress" option, we will wait for user feedback.
2/ New zmap styles *************
edgrif has now implemented this (with inheritance), jgrg needs
to decide when to do the big swop. jgrg said with the new schema
work now almost done he is in a position to do this.
should be done this week.
3/ Display of otter information
edgrif and rds have implemented code in zmap to deal with otter ids etc but lace
needs to export these so we can display them. jgrg said with the new schema
work now almost done he is in a position to do this.
should be done this week.
lw2 reported a bug in that the "transcript" section of the feature display is
always empty, edgrif to look at this.
lw2 also asked about DE line information display, edgrif asked lw2 to collect
together requirements for information to be displayed.
4/ CDS translation
rds is working on showing all possible translations etc in zmap window.
This is his current top priority. edgrif to ask where we are with this.
5/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif is implementing this now as there are a couple of outstanding requests
for this.
edgrif & rds still waiting for eah and lw2 to report back with
list of what users would like to be able to configure.
Medium priority
---------------
1/ locator column: zmap needs a locator column as per fmap which could be
used to display dna and peptide search results and other information.
2/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
3/ Annotation needs to have a history across assembly changes.
kj2 requested that when an assembly changes the objects which get
transferred should have a history as to what they were (otter id)
previously. lw2 remarked that it's possible to search for the old id
in the lace interface, but impossible to retrieve the old object and
display it. jgrg acknowledged there is a bug in the lace searching,
but that providing the history would be difficult. Further
discussion/thought on how to implement this is needed.
jgrg said that this should be more possible with the new ensembl schema.
4/ lasso with left button down only
edgrif explained that this is not simple because we use left button to
select objects, he is looking at a possible way to implement this.
we discussed the option of having a flag to remove mouse usage, would be
good for training and also for experienced users to get them to use
the keyboard short cuts. edgrif to investigate.
5/ removing evidence already used
annotators would like to be able to remove from display homologies that
have already been used to annotate variants etc. Does this need to be
persistent in the database in some way ?? edgrif & jgrg will get
together to arrange this via styles so it can persist in a natural way
in the database.
6/ Multiple alignments
multiple alignments: edgrif is about a third of the way through implementing a
more general way of displaying arbitrary blocks. This will become a high
priority item as we move to haplotypes etc.
th said this would be needed soon so it should be moved up the priority list.
7/ pfetch proxy
jgrg has provided pseudo code, rds to implement.
Low priority
------------
0/ jgrg asked if edgrif could check what level of gtk acedb is built against.
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
We need a test database for this. jgrg said this would come soon.
A new canvas
------------
rds has been looking at alternative canvas implementations which offer an MVC
model. He has managed to get goocanvas developers to fix some bugs and make
some changes to support our needs.
the goocanvas MVC model will mean we do not have to copy data to split windows
meaning greatly reduced memory usage.
the goocanvas will cope automatically with the X Windows window size limit, this
combined with changes in the gtk scrolling model means we will be able to do away
with having two scroll bars.
We plan to introduce this in the Autumn when it has become part of gtk
as _the_ gtk canvas.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
started work on an autoconf'd package to do this.
Builds
------
We now have a properly networked Mac, we need to include universal binaries.
jgrg, edgrif & rds to work on this. edgrif working on installing autoconf
stuff on the mac, needed to build our special foocanvas version. Once that
has been done we wil harmonise with jgrg's script for building lace installs.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
2) Other matters
================
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
Mustapha is working on this.
3) Next Meeting
===============
Will be at 2pm, 8th November 2007
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_11_08 deleted 100755 → 0
+ 0
− 306
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Thursday 8th November 2007
Attendees: edgrif, lw2, jla1, jgrg, eah, st3, te3
1) otterlace + zmap progress
============================
High priority
-------------
0/ ZMap performance
edgrif & rds still awaiting feedback.
There is still a problem with the pipeline and pathological conditions
that produce huge numbers of essentially useless homologies. jgrg is
thinking about how to do this.
edgrif investigating two possibilities for improving performance:
- make sgifaceserver stream data rather than batch it up, would
save a lot of memory.
- deferred loading, only load features when needed and load in
zone requested by user.
rds has been making changes to the way the foocanvas draws which will
make operations like reverse complement significantly faster.
edgrif is to follow up installing X performance tools on linux/mac so we
measure performance identify poorly performing/badly configured boxes. In
particular this is going to be done on the new boxes.
1/ New zmap styles *************
edgrif has now implemented this (with inheritance), jgrg needs
to decide when to do the big swop. jgrg said with the new schema
work now almost done he is in a position to do this.
should be done this week.
2/ Display of otter information
edgrif and rds have implemented code in zmap to deal with otter ids etc but lace
needs to export these so we can display them. jgrg said with the new schema
work now almost done he is in a position to do this.
should be done this week.
lw2 reported a bug in that the "transcript" section of the feature display is
always empty, edgrif to look at this.
lw2 also asked about DE line information display, edgrif asked lw2 to collect
together requirements for information to be displayed. jla1 to chase up.
39329: PFAM info
Possible to show a description associated with Halfwise (Pfam) objects in Zmap?
Currently in lace we see the domain description as well as the pfam accession number
(EAH) jgrg will pass this information over to zmap, in particular Ensembl URLs will
be passed over.
BLAST evidence info:
Would it be possible to see what organism a piece of evidence belongs to, without
having to pfetch each one individually? Also no info (field Title in Fmap) on EST/mRNA
hits unless you pfetch (RJK, AF2, MT4) We need species and taxon data but some of
this needs new database fields (jgrg to implement).
3/ CDS translation
TOP PRIORITY rds is working on showing all possible translations etc in zmap window.
This is his current top priority. edgrif to ask where we are with this.
10155 & 40988: Show CDS translation in Zmap
40989: 3 frame translation on the Zmap
It would be nice when clicking on a transcript to have highlighted the correct frame
in the 3 frame translation that corresponds to a particular exon
- 3 frame translation did not work at all for forward or revcomp (RJK)
rds has implemented fmap functionality but to go further requires styles.
4/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif has implemented code for this but now need eah and lw2 to report back with
list of what users would like to be able to configure.
jla1 said that configuration is required more at the group or DB level, we can
already do this via lace setting up zmaps configuration files.
lw2 suggested users would like to configure column order, he will put in a low
priority ticket for this.
Medium priority
---------------
1/ locator column: zmap needs a locator column as per fmap which could be
used to display dna and peptide search results and other information.
2/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
3/ Annotation needs to have a history across assembly changes.
kj2 requested that when an assembly changes the objects which get
transferred should have a history as to what they were (otter id)
previously. lw2 remarked that it's possible to search for the old id
in the lace interface, but impossible to retrieve the old object and
display it. jgrg acknowledged there is a bug in the lace searching,
but that providing the history would be difficult. Further
discussion/thought on how to implement this is needed.
jgrg said that this should be more possible with the new ensembl schema.
4/ clone overlap display
lw2 said users need to see more clone overlap data, jgrg has provided a
suggestion for how this might be displayed.
They would also like to be able to list features by clone rather than just
by hit name or whatever.
They would also like to see the clone name in lists of hsps....
5/ removing evidence already used
TOP PRIORITY
annotators would like to be able to remove from display homologies that
have already been used to annotate variants etc. Does this need to be
persistent in the database in some way ?? edgrif & jgrg will get
together to arrange this via styles so it can persist in a natural way
in the database.
**24526: Showing which evidence has been used
Differential coloring of matches that have been used already as evidence
for a transcript
6/ Multiple alignments
multiple alignments: edgrif is about a third of the way through implementing a
more general way of displaying arbitrary blocks. This will become a high
priority item as we move to haplotypes etc.
th said this would be needed soon so it should be moved up the priority list.
7/ pfetch proxy
jgrg has provided pseudo code, rds to implement.
8/ Interface issues:
extending marked region:
jla1, eah and lw2 said users would like some way of interactively extending the
marked area. edgrif to look at this perhaps using mouse action over the marked area.
jla1 and lw2 said they would like the marked area to be less obvious an also to
be a "greying" out rather than blue. edgrif to implement.
Zooming set up:
It would be very useful for large genes if the evidence, ensembl objects etc. did not
disappear when you zoom out. This happens faster in Zmap than in Fmap, but the havana
objects do not disappear in either case. (MMS)
edgrif explained that we need the new styles to fix this.
Would it be possible to have an undo or back (like on a web browser) button? (AF2)
rds is implementing this.
Low priority
------------
0/ jgrg asked if edgrif could check what level of gtk acedb is built against.
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
We need a test database for this. jgrg said this would come soon.
3/ loutre schema and data representation changes
We need some way to make sure st3 knows about changes anacode are making.
jgrg and st3 to communicate more over this.
A new canvas
------------
rds has been looking at alternative canvas implementations which offer an MVC
model. He has managed to get goocanvas developers to fix some bugs and make
some changes to support our needs.
the goocanvas MVC model will mean we do not have to copy data to split windows
meaning greatly reduced memory usage.
the goocanvas will cope automatically with the X Windows window size limit, this
combined with changes in the gtk scrolling model means we will be able to do away
with having two scroll bars.
We plan to introduce this in the Autumn when it has become part of gtk
as _the_ gtk canvas.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
started work on an autoconf'd package to do this.
Builds
------
We now have a properly networked Mac, we need to include universal binaries.
jgrg, edgrif & rds to work on this. edgrif working on installing autoconf
stuff on the mac, needed to build our special foocanvas version. Once that
has been done we wil harmonise with jgrg's script for building lace installs.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
2) Other matters
================
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
Mustapha is working on this.
3) Next Meeting
===============
Will be at 2pm, 22nd November 2007
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_11_22 deleted 100755 → 0
+ 0
− 283
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Thursday 22nd November 2007
Attendees: edgrif, eah
1) otterlace + zmap progress
============================
High priority
-------------
0/ ZMap performance - contd.....
There is still a problem with the pipeline and pathological conditions
that produce huge numbers of essentially useless homologies. jgrg is
thinking about how to do this.
edgrif investigating two possibilities for improving performance:
- make sgifaceserver stream data rather than batch it up, would
save a lot of memory.
- deferred loading, only load features when needed and load in
zone requested by user....design done...now need to implement.
Have found X performance tools, very comprehensive. Plan is to run them
on my machine as a benchmark and compare. Will produce noddy script that
records the machines configuration, runs the X performance tool and produces
a comparison with the benchmark. This way we can profile anyones machine
who is having problems with performance.
1/ New zmap styles *************
edgrif has now implemented this (with inheritance), jgrg needs
to decide when to do the big swop. jgrg said with the new schema
work now almost done he is in a position to do this.
should be done this week.
2/ Display of otter information
Otter ids are now displayed. edgrif is reworking the feature display to match
requirements from Mark who coordinated Havana input on this. ZMap code should be
done this week and should include:
lw2 also asked about DE line information display, edgrif asked lw2 to collect
together requirements for information to be displayed. jla1 to chase up.
39329: PFAM info
Possible to show a description associated with Halfwise (Pfam) objects in Zmap?
Currently in lace we see the domain description as well as the pfam accession number
(EAH) jgrg will pass this information over to zmap, in particular Ensembl URLs will
be passed over.
BLAST evidence info:
Would it be possible to see what organism a piece of evidence belongs to, without
having to pfetch each one individually? Also no info (field Title in Fmap) on EST/mRNA
hits unless you pfetch (RJK, AF2, MT4) We need species and taxon data but some of
this needs new database fields (jgrg to implement).
3/ CDS translation
Will be in next build which is early next week.
4/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif has implemented code for this but now need eah and lw2 to report back with
list of what users would like to be able to configure.
jla1 said that configuration is required more at the group or DB level, we can
already do this via lace setting up zmaps configuration files.
Medium priority
---------------
1/ locator column: zmap needs a locator column as per fmap which could be
used to display dna and peptide search results and other information.
2/ There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement.
3/ Annotation needs to have a history across assembly changes.
kj2 requested that when an assembly changes the objects which get
transferred should have a history as to what they were (otter id)
previously. lw2 remarked that it's possible to search for the old id
in the lace interface, but impossible to retrieve the old object and
display it. jgrg acknowledged there is a bug in the lace searching,
but that providing the history would be difficult. Further
discussion/thought on how to implement this is needed.
jgrg said that this should be more possible with the new ensembl schema.
4/ clone overlap display
lw2 said users need to see more clone overlap data, jgrg has provided a
suggestion for how this might be displayed.
They would also like to be able to list features by clone rather than just
by hit name or whatever.
They would also like to see the clone name in lists of hsps....
5/ removing evidence already used
TOP PRIORITY
annotators would like to be able to remove from display homologies that
have already been used to annotate variants etc. Does this need to be
persistent in the database in some way ?? edgrif & jgrg will get
together to arrange this via styles so it can persist in a natural way
in the database.
**24526: Showing which evidence has been used
Differential coloring of matches that have been used already as evidence
for a transcript
6/ Multiple alignments
multiple alignments: edgrif is about a third of the way through implementing a
more general way of displaying arbitrary blocks. This will become a high
priority item as we move to haplotypes etc.
th said this would be needed soon so it should be moved up the priority list.
7/ pfetch proxy
jgrg has provided pseudo code, rds to implement.
8/ Interface issues:
extending marked region:
jla1, eah and lw2 said users would like some way of interactively extending the
marked area. edgrif to look at this perhaps using mouse action over the marked area.
jla1 and lw2 said they would like the marked area to be less obvious an also to
be a "greying" out rather than blue. edgrif to implement.
Zooming set up:
It would be very useful for large genes if the evidence, ensembl objects etc. did not
disappear when you zoom out. This happens faster in Zmap than in Fmap, but the havana
objects do not disappear in either case. (MMS)
edgrif explained that we need the new styles to fix this.
Would it be possible to have an undo or back (like on a web browser) button? (AF2)
rds is implementing this.
Low priority
------------
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
We need a test database for this. jgrg said this would come soon.
3/ loutre schema and data representation changes
We need some way to make sure st3 knows about changes anacode are making.
jgrg and st3 to communicate more over this.
A new canvas
------------
rds has been looking at alternative canvas implementations which offer an MVC
model. He has managed to get goocanvas developers to fix some bugs and make
some changes to support our needs.
the goocanvas MVC model will mean we do not have to copy data to split windows
meaning greatly reduced memory usage.
the goocanvas will cope automatically with the X Windows window size limit, this
combined with changes in the gtk scrolling model means we will be able to do away
with having two scroll bars.
We plan to introduce this in the Autumn when it has become part of gtk
as _the_ gtk canvas.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
started work on an autoconf'd package to do this.
Builds
------
rds has done the universal binary builds. So we can provide hand builds of them
but still need to incorporate the system into our overnight build procedure.
A labour of love not helped by fairly poor docs from Apple. But it is now
working.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
2) Other matters
================
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
Mustapha is working on this.
3) Next Meeting
===============
Will be at 2pm, 22nd November 2007
==============================================================================
ZMAP_LACE_PROJECT/zmap_lace.2007_12_06 deleted 100755 → 0
+ 0
− 324
View file @ cf47b0aa
==============================================================================
ZMap/Otterlace Development
Date: Thursday 22nd November 2007
Attendees: edgrif, eah, jgrg, br2, st3, jla1, lw2
1) otterlace + zmap progress
============================
High priority
-------------
0/ ZMap performance - contd.....
There is still a problem with the pipeline and pathological conditions
that produce huge numbers of essentially useless homologies. jgrg is
thinking about how to do this.
edgrif investigating two possibilities for improving performance:
- make sgifaceserver stream data rather than batch it up, would
save a lot of memory.
- deferred loading, only load features when needed and load in
zone requested by user....design done...now need to implement.
Have found X performance tools, very comprehensive. Plan is to run them
on my machine as a benchmark and compare. Will produce noddy script that
records the machines configuration, runs the X performance tool and produces
a comparison with the benchmark. This way we can profile anyones machine
who is having problems with performance.
1/ New zmap styles *************
edgrif has now implemented this (with inheritance), jgrg needs
to decide when to do the big swop. jgrg said with the new schema
work now almost done he is in a position to do this.
should be done this week. edgrif to mail jgrg with info. about how
to turn styles "on" in zmap.
2/ Display of otter information
Otter ids are now displayed. edgrif is reworking the feature display to match
requirements from Mark who coordinated Havana input on this. ZMap code should be
done this week and should include:
lw2 also asked about DE line information display, edgrif asked lw2 to collect
together requirements for information to be displayed. jla1 to chase up.
39329: PFAM info
Possible to show a description associated with Halfwise (Pfam) objects in Zmap?
Currently in lace we see the domain description as well as the pfam accession number
(EAH) jgrg will pass this information over to zmap, in particular Ensembl URLs will
be passed over.
BLAST evidence info:
Would it be possible to see what organism a piece of evidence belongs to, without
having to pfetch each one individually? Also no info (field Title in Fmap) on EST/mRNA
hits unless you pfetch (RJK, AF2, MT4) We need species and taxon data but some of
this needs new database fields (jgrg to implement).
3/ CDS translation
Will be in next build which is early next week.
4/ There was a discussion about how much a user should be able to
configure. It was agreed that they should be able to configure which columns
are initially hidden. They should also be able to "save" the current settings
to set this up and to be able to restore the system or there currently saved
defaults.
edgrif has implemented code for this but now need eah and lw2 to report back with
list of what users would like to be able to configure.
jla1 said that configuration is required more at the group or DB level, we can
already do this via lace setting up zmaps configuration files.
5/ parsing names with embedded spaces...
jgrg said there is a problem with zmap parsing gff where there are feature names
with embedded spaces, edgrif to fix this asap. Also, the text following the object
name needs to be displayed in the info. line when the feature is selected.
6/ Consistency Test using ZMap
jla1 said there will be a test in February using zmap, not xace. edgrif said he
and Roy will make sure there is a stable version for then.
Medium priority
---------------
0/ 5'and 3' EST read pairs
we need these to be marked in zmap as in acedb, requires new tags in database in
the same way as in worm database.
1/ locator column: zmap needs a locator column as per fmap which could be
used to display dna and peptide search results and other information.
3/ Annotation needs to have a history across assembly changes.
kj2 requested that when an assembly changes the objects which get
transferred should have a history as to what they were (otter id)
previously. lw2 remarked that it's possible to search for the old id
in the lace interface, but impossible to retrieve the old object and
display it. jgrg acknowledged there is a bug in the lace searching,
but that providing the history would be difficult. Further
discussion/thought on how to implement this is needed.
jgrg said that this should be more possible with the new ensembl schema.
4/ clone overlap display
lw2 said users need to see more clone overlap data, jgrg has provided a
suggestion for how this might be displayed.
They would also like to be able to list features by clone rather than just
by hit name or whatever.
They would also like to see the clone name in lists of hsps....
5/ removing evidence already used
TOP PRIORITY
annotators would like to be able to remove from display homologies that
have already been used to annotate variants etc. Does this need to be
persistent in the database in some way ?? edgrif & jgrg will get
together to arrange this via styles so it can persist in a natural way
in the database.
**24526: Showing which evidence has been used
Differential coloring of matches that have been used already as evidence
for a transcript
6/ Multiple alignments
multiple alignments: edgrif is about a third of the way through implementing a
more general way of displaying arbitrary blocks. This will become a high
priority item as we move to haplotypes etc.
th said this would be needed soon so it should be moved up the priority list.
7/ pfetch proxy
jgrg has provided pseudo code, rds to implement.
8/ Interface issues:
extending marked region:
jla1, eah and lw2 said users would like some way of interactively extending the
marked area. edgrif to look at this perhaps using mouse action over the marked area.
jla1 and lw2 said they would like the marked area to be less obvious an also to
be a "greying" out rather than blue. edgrif to implement.
jla1 said she would like to be able to click on an exon and see evidence (and
transcripts ?) with the same splice be highlighted.
Zooming set up:
It would be very useful for large genes if the evidence, ensembl objects etc. did not
disappear when you zoom out. This happens faster in Zmap than in Fmap, but the havana
objects do not disappear in either case. (MMS)
edgrif explained that we need the new styles to fix this.
Would it be possible to have an undo or back (like on a web browser) button? (AF2)
rds is implementing this.
9/ Future stuff
edgrif said he would like annotators to start thinking/reporting two things:
- repetitive tasks that could be automated.
- new ways to highlight/select data to help build/annotate transcripts.
Low priority
------------
1/ jgrg suggested that short cuts should be given on menus/mouse-over popups
to remind the user that they exist...edgrif to do this.
2/ alternative translations: edgrif about half way through code to do this.
edgrif is doing this as part of the protein search code since this code
does translations itself. edgrif will talk to jgrg about how alternative
genetic codes can be specified with acedb.
We need a test database for this. jgrg said this would come soon.
3/ loutre schema and data representation changes
We need some way to make sure st3 knows about changes anacode are making.
jgrg and st3 to communicate more over this.
2) Back To The Future
=====================
Leo's transcript display
------------------------
There was a discussion about good ways to interact with
alignments/transcripts for deletion and other actions. Leo and James have
already worked out a lot of this with Leos transcript viewer. edgrif will get
the rules from Leo and James and then we can discuss them and decide which to
implement. edgrif suggested that it might be good to have a separate window
but jgrg said he thought it could be done within existing zmap by adding
some new features.
A new canvas
------------
rds has been looking at alternative canvas implementations which offer an MVC
model. He has managed to get goocanvas developers to fix some bugs and make
some changes to support our needs.
the goocanvas MVC model will mean we do not have to copy data to split windows
meaning greatly reduced memory usage.
the goocanvas will cope automatically with the X Windows window size limit, this
combined with changes in the gtk scrolling model means we will be able to do away
with having two scroll bars.
We plan to introduce this in the Autumn when it has become part of gtk
as _the_ gtk canvas.
Changing the Assembly
---------------------
th made the good but frightening point that the world of annotation has
changed to one where the annotator may well be making changes to the
underlying assembly, he said that ensembl supports this and lace/zmap will
need to. The consequences feel alarming.....
edgrif and rds to think about this: would it mean that zmap would have to
change the position of features on the fly as the user edits the
assembly...some tricky pathological cases here....
We will need smapping support in zmap to do this kind of thing. edgrif has
started work on an autoconf'd package to do this.
Builds
------
rds has done the universal binary builds. So we can provide hand builds of them
but still need to incorporate the system into our overnight build procedure.
A labour of love not helped by fairly poor docs from Apple. But it is now
working.
Blixem/pfetch
--------------
- blixem: dna searching is NOT DONE, edgrif to expedite. Also protein searches
will be added.
2) Other matters
================
kj2 raised a question about how alignments were done for otter, jgrg said
using BLAST and est2genome. Kerstin said that much more useful alignments
could be made using BLAT or exonerate or ??? In particular, other alignment
methods join up their matches where they are obviously "perfect" overall
alignments (e.g. to consecutive exons) and cope with alignments where they go
over clone boundaries.
Mustapha is working on this.
3) Next Meeting
===============
Will be at 2pm, 3rd January 2008
==============================================================================
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment