From c67d1160183f7dbc1bd0e9a23f0cc7d62f5efb03 Mon Sep 17 00:00:00 2001 From: edgrif <edgrif> Date: Fri, 13 Feb 2009 12:49:19 +0000 Subject: [PATCH] moved to 2007 --- ZMAP_LACE_PROJECT/zmap_lace.2007_01_11 | 203 -------------- ZMAP_LACE_PROJECT/zmap_lace.2007_01_24 | 239 ---------------- ZMAP_LACE_PROJECT/zmap_lace.2007_02_01 | 203 -------------- ZMAP_LACE_PROJECT/zmap_lace.2007_02_23 | 360 ------------------------- ZMAP_LACE_PROJECT/zmap_lace.2007_03_14 | 264 ------------------ ZMAP_LACE_PROJECT/zmap_lace.2007_04_13 | 300 --------------------- ZMAP_LACE_PROJECT/zmap_lace.2007_04_23 | 234 ---------------- ZMAP_LACE_PROJECT/zmap_lace.2007_05_09 | 234 ---------------- ZMAP_LACE_PROJECT/zmap_lace.2007_06_06 | 265 ------------------ ZMAP_LACE_PROJECT/zmap_lace.2007_06_14 | 126 --------- ZMAP_LACE_PROJECT/zmap_lace.2007_07_04 | 223 --------------- ZMAP_LACE_PROJECT/zmap_lace.2007_08_15 | 190 ------------- ZMAP_LACE_PROJECT/zmap_lace.2007_09_12 | 211 --------------- ZMAP_LACE_PROJECT/zmap_lace.2007_09_26 | 218 --------------- ZMAP_LACE_PROJECT/zmap_lace.2007_10_11 | 253 ----------------- ZMAP_LACE_PROJECT/zmap_lace.2007_10_25 | 246 ----------------- ZMAP_LACE_PROJECT/zmap_lace.2007_11_08 | 306 --------------------- ZMAP_LACE_PROJECT/zmap_lace.2007_11_22 | 283 ------------------- ZMAP_LACE_PROJECT/zmap_lace.2007_12_06 | 324 ---------------------- 19 files changed, 4682 deletions(-) delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_01_11 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_01_24 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_02_01 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_02_23 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_03_14 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_04_13 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_04_23 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_05_09 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_06_06 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_06_14 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_07_04 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_08_15 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_09_12 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_09_26 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_10_11 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_10_25 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_11_08 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_11_22 delete mode 100755 ZMAP_LACE_PROJECT/zmap_lace.2007_12_06 diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_01_11 b/ZMAP_LACE_PROJECT/zmap_lace.2007_01_11 deleted file mode 100755 index 4f24c37da..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_01_11 +++ /dev/null @@ -1,203 +0,0 @@ -============================================================================== -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. - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_01_24 b/ZMAP_LACE_PROJECT/zmap_lace.2007_01_24 deleted file mode 100755 index a27dfed2e..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_01_24 +++ /dev/null @@ -1,239 +0,0 @@ -============================================================================== -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. - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_02_01 b/ZMAP_LACE_PROJECT/zmap_lace.2007_02_01 deleted file mode 100755 index 4f24c37da..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_02_01 +++ /dev/null @@ -1,203 +0,0 @@ -============================================================================== -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. - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_02_23 b/ZMAP_LACE_PROJECT/zmap_lace.2007_02_23 deleted file mode 100755 index 6eec9c247..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_02_23 +++ /dev/null @@ -1,360 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_03_14 b/ZMAP_LACE_PROJECT/zmap_lace.2007_03_14 deleted file mode 100755 index 8831bc85c..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_03_14 +++ /dev/null @@ -1,264 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_04_13 b/ZMAP_LACE_PROJECT/zmap_lace.2007_04_13 deleted file mode 100755 index 46474df66..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_04_13 +++ /dev/null @@ -1,300 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_04_23 b/ZMAP_LACE_PROJECT/zmap_lace.2007_04_23 deleted file mode 100755 index f4eefef88..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_04_23 +++ /dev/null @@ -1,234 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_05_09 b/ZMAP_LACE_PROJECT/zmap_lace.2007_05_09 deleted file mode 100755 index d638447be..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_05_09 +++ /dev/null @@ -1,234 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_06_06 b/ZMAP_LACE_PROJECT/zmap_lace.2007_06_06 deleted file mode 100755 index f644ed6b4..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_06_06 +++ /dev/null @@ -1,265 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_06_14 b/ZMAP_LACE_PROJECT/zmap_lace.2007_06_14 deleted file mode 100755 index b456768ed..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_06_14 +++ /dev/null @@ -1,126 +0,0 @@ -============================================================================== -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. diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_07_04 b/ZMAP_LACE_PROJECT/zmap_lace.2007_07_04 deleted file mode 100755 index 0f7a394e1..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_07_04 +++ /dev/null @@ -1,223 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_08_15 b/ZMAP_LACE_PROJECT/zmap_lace.2007_08_15 deleted file mode 100755 index 393bef8b5..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_08_15 +++ /dev/null @@ -1,190 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_09_12 b/ZMAP_LACE_PROJECT/zmap_lace.2007_09_12 deleted file mode 100755 index b6f54a862..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_09_12 +++ /dev/null @@ -1,211 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_09_26 b/ZMAP_LACE_PROJECT/zmap_lace.2007_09_26 deleted file mode 100755 index b121108ba..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_09_26 +++ /dev/null @@ -1,218 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_10_11 b/ZMAP_LACE_PROJECT/zmap_lace.2007_10_11 deleted file mode 100755 index 96170cebe..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_10_11 +++ /dev/null @@ -1,253 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_10_25 b/ZMAP_LACE_PROJECT/zmap_lace.2007_10_25 deleted file mode 100755 index 7ef6230f3..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_10_25 +++ /dev/null @@ -1,246 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_11_08 b/ZMAP_LACE_PROJECT/zmap_lace.2007_11_08 deleted file mode 100755 index aad233fc1..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_11_08 +++ /dev/null @@ -1,306 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_11_22 b/ZMAP_LACE_PROJECT/zmap_lace.2007_11_22 deleted file mode 100755 index 7698f587f..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_11_22 +++ /dev/null @@ -1,283 +0,0 @@ -============================================================================== -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 - - -============================================================================== diff --git a/ZMAP_LACE_PROJECT/zmap_lace.2007_12_06 b/ZMAP_LACE_PROJECT/zmap_lace.2007_12_06 deleted file mode 100755 index 732079499..000000000 --- a/ZMAP_LACE_PROJECT/zmap_lace.2007_12_06 +++ /dev/null @@ -1,324 +0,0 @@ -============================================================================== -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 - - -============================================================================== -- GitLab