From: Nick H. <nic...@ho...> - 2012-08-23 13:09:27
|
On 23/08/12 12:24, W. Trevor King wrote: > It sounds like you left out the todo list phase, where those > parentless individuals are dealt with: Yes. How should I process the todo list? There seems to be a step missing. At some point we need to adjust the generations in the branches that are too high up in the tree. Nick. |
From: Benny M. <ben...@gm...> - 2012-08-23 15:02:16
|
2012/8/23 Nick Hall <nic...@ho...> > On 23/08/12 12:24, W. Trevor King wrote: > >> It sounds like you left out the todo list phase, where those >> parentless individuals are dealt with: >> > Yes. How should I process the todo list? There seems to be a step > missing. > > At some point we need to adjust the generations in the branches that are > too high up in the tree. > My idea was that the todo list people must be assigned an generation based on: a. step one: determine estimated birth of everyone in the todo list. We have a function for that b. step two: determine first generation. Those are the oldest in the todo list. These people will not be moved to another generation anymore Assign every person a moveto list, which is [current_gen] initially, and for the root people None (to indicate they should not move) c. step tree, determine what the correct generation is for non root people in the todo list 1. do they have a spouse/husband of generation j, then they should be generation j 2. do they have a sibling of generation j, then they should be generation j 3. if not assigned yet, if they have a calculated birth day, look for the generation in the decendants of the root people that fits this birth day best. 4. when assigning a person in todo list a generation, all their descendants must be moved to. Say a person goes to generatino 4. Then every descendant of this person should have minimum of current assigned generation + 4. So moveto list is appended with this new generation. The move should not happen yet however. Instead, all people in the todo list must be handled first. After that, the move can happen to the highest generation in the moveto list, so to max(moveto). I think that closes all holes. Problem will remain with disconnected sets of people, where the root decendants also don't overlap, eg root person of 1600 with decendants to 1750, and another set of people starting in 1820. With some luck, those will nevertheless with above approach start after the last generation of the descendants of 1600 Benny > Nick. > > |
From: Doug B. <dou...@gm...> - 2012-08-23 15:21:46
|
On Thu, Aug 23, 2012 at 11:02 AM, Benny Malengier <ben...@gm...> wrote: > > > 2012/8/23 Nick Hall <nic...@ho...> >> >> On 23/08/12 12:24, W. Trevor King wrote: >>> >>> It sounds like you left out the todo list phase, where those >>> parentless individuals are dealt with: >> >> Yes. How should I process the todo list? There seems to be a step >> missing. >> >> At some point we need to adjust the generations in the branches that are >> too high up in the tree. > > > My idea was that the todo list people must be assigned an generation based > on: > > a. step one: determine estimated birth of everyone in the todo list. We have > a function for that > > b. step two: determine first generation. Those are the oldest in the todo > list. These people will not be moved to another generation anymore > > Assign every person a moveto list, which is [current_gen] initially, and for > the root people None (to indicate they should not move) > > c. step tree, determine what the correct generation is for non root people > in the todo list > > 1. do they have a spouse/husband of generation j, then they should be > generation j > 2. do they have a sibling of generation j, then they should be generation j > 3. if not assigned yet, if they have a calculated birth day, look for the > generation in the decendants of the root people that fits this birth day > best. > 4. when assigning a person in todo list a generation, all their descendants > must be moved to. > Say a person goes to generatino 4. Then every descendant of this person > should have minimum of current assigned generation + 4. So moveto list is > appended with this new generation. > The move should not happen yet however. Instead, all people in the todo list > must be handled first. > After that, the move can happen to the highest generation in the moveto > list, so to max(moveto). > > I think that closes all holes. Problem will remain with disconnected sets of > people, where the root decendants also don't overlap, eg root person of 1600 > with decendants to 1750, and another set of people starting in 1820. With > some luck, those will nevertheless with above approach start after the last > generation of the descendants of 1600 It sounds like the Layering algorithm (that Benny outlines above) will be the easy part. The next and harder part is getting the ordering inside the layer to be nice. In fact, this must be hard because (reading the paper) it sounds like the geneaquilt project farms that out to dot. Dot will do the ordering, and then geneaquilt reads that back in for their (X,Y) position. That is an option, but it sounds like it will be worth a try ourselves :) But it may be that it is an expensive operation. Suggest that we may want to cache that in any event. On a different issue, I wonder if putting the names after the matrix squares would make the report head off to the right less quickly? In the geneaquilt version, the matrix for the downward links to families doesn't start until after the names. -Doug > Benny > >> >> Nick. >> > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Nick H. <nic...@ho...> - 2012-08-23 17:57:55
|
On 23/08/12 16:21, Doug Blank wrote: > It sounds like the Layering algorithm (that Benny outlines above) will > be the easy part. The next and harder part is getting the ordering > inside the layer to be nice. In fact, this must be hard because > (reading the paper) it sounds like the geneaquilt project farms that > out to dot. Dot will do the ordering, and then geneaquilt reads that > back in for their (X,Y) position. I'll email the GeneaQuilt authors. Serge seemed to get a helpful response. > That is an option, but it sounds like it will be worth a try ourselves > :) But it may be that it is an expensive operation. Suggest that we > may want to cache that in any event. > > On a different issue, I wonder if putting the names after the matrix > squares would make the report head off to the right less quickly? In > the geneaquilt version, the matrix for the downward links to families > doesn't start until after the names. Perhaps we should try to reproduce the GeneaQuilt output to start with? We can think about modifications and enhancements later. Nick. |
From: Benny M. <ben...@gm...> - 2012-08-23 17:30:19
|
2012/8/23 W. Trevor King <wk...@tr...> > On Thu, Aug 23, 2012 at 05:02:15PM +0200, Benny Malengier wrote: > > b. step two: determine first generation. Those are the oldest in the todo > > list. These people will not be moved to another generation anymore > > I think the best way to do this is to have a LinkedGroup object that > can store generation info. Parentless folks from the todo list will > belong to some number of possibly disjoint `LinkedGroup`s. You sort > each linked group independently, with the eldest person in gen 0. No > need for a todo list, since all people have an anchoring relation into > the group. > > If you have disjoint linked groups, you'll need to align them. Since > the intra-group alignment starts from the eldest and works down > (possibly getting out of sync as it goes), it is most consistent to > align the LinkedGroups from their eldest generations. Each group gets > a max age (from the eldest member of their eldest generation). The > eldest group sets the scale, and subsequent groups are assigned by > matching their eldest with the mean of each successive generation from > the already joined groups: > > done = [] > while len(groups) > 1: > groups.sort() > eldest = groups[0] > next_eldest = groups[1] > try: > merge(eldest, next_eldest) > except NoOverlap: > # because next_eldest doesn't overlay with eldest, > # no other group will either. > next_eldest.root_generation = eldest.tail_generation > done.append(eldest) > groups.remove(eldest) > else: > groups.remove(next_eldest) > > > c. step tree, determine what the correct generation is for non root > people > > in the todo list > > I thought the todo list was *only* root people (i.e. no parents). > Perhaps you mean the eldest in a linked set of parentless people > (i.e. the older member of a couple, neither of whom have known > parents)? > Defenitions needed :-) The todo list are those with no parents. You call them root people. However, there has to be some true root (meaning here generation 0) and the rest are elsewhere. So in my mail, with root I mean the true roots (generation 0), the rest of the todo list is then the 'non-root' people. Benny > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > |
From: Nick H. <nic...@ho...> - 2012-08-23 17:53:48
|
On 23/08/12 16:02, Benny Malengier wrote: > My idea was that the todo list people must be assigned an generation > based on: > > a. step one: determine estimated birth of everyone in the todo list. > We have a function for that We should be able to assign a generation number without estimating birth dates. The Greek Gods file contains virtually no date information. I expect that GeneaQuilt determines generation (layer) number purely by analysing the structure of the graph. > > b. step two: determine first generation. Those are the oldest in the > todo list. These people will not be moved to another generation anymore > > Assign every person a moveto list, which is [current_gen] initially, > and for the root people None (to indicate they should not move) We could just pick any person for generation 0. If we move a branch such that we end up with a negative generation number, this is not a problem. > > c. step tree, determine what the correct generation is for non root > people in the todo list When we process a branch, we will know the correct generation number when we hit the existing tree. > > 1. do they have a spouse/husband of generation j, then they should be > generation j Only for a simple tree. The spouse may belong to a different generation when we have inter-marriages. > 2. do they have a sibling of generation j, then they should be > generation j If the have a sibling, then they cannot be a root node. > 3. if not assigned yet, if they have a calculated birth day, look for > the generation in the decendants of the root people that fits this > birth day best. I think that birth dates could be one way to order people within a generation, but not to assign the generation number. > 4. when assigning a person in todo list a generation, all their > descendants must be moved to. > Say a person goes to generatino 4. Then every descendant of this > person should have minimum of current assigned generation + 4. So > moveto list is appended with this new generation. > The move should not happen yet however. Instead, all people in the > todo list must be handled first. > After that, the move can happen to the highest generation in the > moveto list, so to max(moveto). Yes, it is safe to shift an entire branch. > > I think that closes all holes. Problem will remain with disconnected > sets of people, where the root decendants also don't overlap, eg root > person of 1600 with decendants to 1750, and another set of people > starting in 1820. With some luck, those will nevertheless with above > approach start after the last generation of the descendants of 1600 This is a more complex problem than I anticipated. Although I can see a solution now, I think that I will email the GeneaQuilt authors. Perhaps they can let me know the algorithms they use? Nick. |
From: Nick H. <nic...@ho...> - 2012-08-23 18:35:09
|
Trevor, At the moment, I am selecting the people for the chart by tree walking from the active person. This has two benefits: 1. We avoid disjoint groups. 2. If necessary, we could limit the number of people in the chart. Even determining the generation number in a continuous graph is not as easy as I thought. We can always extend the functionality later, but I would like to start with something simple. You are correct that siblings might be in a family without parents. I'll look for an example of how GeneaQuilts represents this, but I don't see a problem here. Nick. On 23/08/12 19:11, W. Trevor King wrote: > On Thu, Aug 23, 2012 at 06:53:41PM +0100, Nick Hall wrote: >> On 23/08/12 16:02, Benny Malengier wrote: >>> My idea was that the todo list people must be assigned an generation >>> based on: >>> >>> a. step one: determine estimated birth of everyone in the todo list. >>> We have a function for that >> We should be able to assign a generation number without estimating birth >> dates. The Greek Gods file contains virtually no date information. I >> expect that GeneaQuilt determines generation (layer) number purely by >> analysing the structure of the graph. > The Greek Gods don't have any disjoint sets. With the LinkedGroup > algorithm, dabirthdates only come into play for aligning these > disjoint groups. > >>> 2. do they have a sibling of generation j, then they should be >>> generation j >> If the have a sibling, then they cannot be a root node. > They can if they are children in a family that has no known parents. > >>> 3. if not assigned yet, if they have a calculated birth day, look for >>> the generation in the decendants of the root people that fits this >>> birth day best. >> I think that birth dates could be one way to order people within a >> generation, but not to assign the generation number. > If you don't have a relationship linkage, they are the only way to > estimate alignment. > > Trevor > |
From: Benny M. <ben...@gm...> - 2012-08-23 19:03:33
|
2012/8/23 Nick Hall <nic...@ho...> > On 23/08/12 16:02, Benny Malengier wrote: > >> My idea was that the todo list people must be assigned an generation >> based on: >> >> a. step one: determine estimated birth of everyone in the todo list. We >> have a function for that >> > > We should be able to assign a generation number without estimating birth > dates. The Greek Gods file contains virtually no date information. I > expect that GeneaQuilt determines generation (layer) number purely by > analysing the structure of the graph. > > b. step two: determine first generation. Those are the oldest in the todo >> list. These people will not be moved to another generation anymore >> >> Assign every person a moveto list, which is [current_gen] initially, and >> for the root people None (to indicate they should not move) >> > > We could just pick any person for generation 0. If we move a branch such > that we end up with a negative generation number, this is not a problem. True > > c. step tree, determine what the correct generation is for non root people >> in the todo list >> > > When we process a branch, we will know the correct generation number when > we hit the existing tree. > > 1. do they have a spouse/husband of generation j, then they should be >> generation j >> > > Only for a simple tree. The spouse may belong to a different generation > when we have inter-marriages. Well, if the only mention of the person is as spouse of somebody, then it seems simplest to just put him on the same generation, and not look at birth date. If connected to two people of different gen (eg child is 6, spouse if gen 4), how to choose generation (3,4 or 5?). As it is a person without parents, it doesn't really matter. Only birth day could help you, but putting it at the level of the oldest spouse doesn't hurt as a first attempt > > 2. do they have a sibling of generation j, then they should be generation >> j >> > > If the have a sibling, then they cannot be a root node. Yes they can. Please keep it general. We should allow for a filter on the people to show: everyone, descendants active person, ... If everyone, then many people can be at the root. > > 3. if not assigned yet, if they have a calculated birth day, look for the >> generation in the decendants of the root people that fits this birth day >> best. >> > > I think that birth dates could be one way to order people within a > generation, but not to assign the generation number. Not to assign an original generation number, but if everyone is shown, distinct groups must be connected to each other. Then birth day is the way to go. If you only do people connected to the active person, this will not be a problem, but a general approach would be usefull too (eg to see which people might have known each other). > > 4. when assigning a person in todo list a generation, all their >> descendants must be moved to. >> Say a person goes to generatino 4. Then every descendant of this person >> should have minimum of current assigned generation + 4. So moveto list is >> appended with this new generation. >> The move should not happen yet however. Instead, all people in the todo >> list must be handled first. >> After that, the move can happen to the highest generation in the moveto >> list, so to max(moveto). >> > > Yes, it is safe to shift an entire branch. > > I think that closes all holes. Problem will remain with disconnected sets >> of people, where the root decendants also don't overlap, eg root person of >> 1600 with decendants to 1750, and another set of people starting in 1820. >> With some luck, those will nevertheless with above approach start after the >> last generation of the descendants of 1600 >> > > This is a more complex problem than I anticipated. Although I can see a > solution now, I think that I will email the GeneaQuilt authors. Perhaps > they can let me know the algorithms they use? > Looking at the output Peter posted, I would not be amazed if there are still some holes in their algorithms :-). Note that even in the drawing at the start of the research article an error is present. Our users would not be so forgiving :-D Doing research myself, don't bet on it they don't tweak it here and there to have nicer output. Benny |
From: Nick H. <nic...@ho...> - 2012-08-23 20:22:57
|
On 23/08/12 20:03, Benny Malengier wrote: > Well, if the only mention of the person is as spouse of somebody, then > it seems simplest to just put him on the same generation, and not look > at birth date. If connected to two people of different gen (eg child > is 6, spouse if gen 4), how to choose generation (3,4 or 5?). As it is > a person without parents, it doesn't really matter. Only birth day > could help you, but putting it at the level of the oldest spouse > doesn't hurt as a first attempt If the only link is the spouse, then I agree, they should go at the level of the spouse. If there is a link to a child, then it would be natural to place them one generation above the child, unless there are other constraints that prevent this. > > If the have a sibling, then they cannot be a root node. > > > Yes they can. I was thinking of layers rather than generations when I wrote this (in which case the family would be the root). In terms of people you are correct. > Please keep it general. We should allow for a filter on the people to > show: everyone, descendants active person, ... > If everyone, then many people can be at the root. Yes. At the moment, I am creating a list of people reachable from the active person. We can enhance this later, but I'd like to start out with something simple, otherwise I will probably end up getting nowhere. > > Looking at the output Peter posted, I would not be amazed if there are > still some holes in their algorithms :-). Note that even in the > drawing at the start of the research article an error is present. Our > users would not be so forgiving :-D > Doing research myself, don't bet on it they don't tweak it here and > there to have nicer output. I'll send them an email anyway - they might have some useful suggestions. Nick. |
From: Peter L. <pet...@te...> - 2012-08-24 10:01:49
|
Benny Malengier skrev 2012-08-23 21:03: > > > 2012/8/23 Nick Hall <nic...@ho... > <mailto:nic...@ho...>> > > On 23/08/12 16:02, Benny Malengier wrote: > > My idea was that the todo list people must be assigned an > generation based on: > > a. step one: determine estimated birth of everyone in the todo > list. We have a function for that > > > We should be able to assign a generation number without estimating > birth dates. The Greek Gods file contains virtually no date > information. I expect that GeneaQuilt determines generation > (layer) number purely by analysing the structure of the graph. > > b. step two: determine first generation. Those are the oldest > in the todo list. These people will not be moved to another > generation anymore > > Assign every person a moveto list, which is [current_gen] > initially, and for the root people None (to indicate they > should not move) > > > We could just pick any person for generation 0. If we move a > branch such that we end up with a negative generation number, this > is not a problem. > > > True > > > c. step tree, determine what the correct generation is for non > root people in the todo list > > > When we process a branch, we will know the correct generation > number when we hit the existing tree. > > 1. do they have a spouse/husband of generation j, then they > should be generation j > > > Only for a simple tree. The spouse may belong to a different > generation when we have inter-marriages. > > > Well, if the only mention of the person is as spouse of somebody, then > it seems simplest to just put him on the same generation, and not look > at birth date. If connected to two people of different gen (eg child > is 6, spouse if gen 4), how to choose generation (3,4 or 5?). As it is > a person without parents, it doesn't really matter. Only birth day > could help you, but putting it at the level of the oldest spouse > doesn't hurt as a first attempt > > > 2. do they have a sibling of generation j, then they should be > generation j > > > If the have a sibling, then they cannot be a root node. > > > Yes they can. > Please keep it general. We should allow for a filter on the people to > show: everyone, descendants active person, ... > If everyone, then many people can be at the root. > > > 3. if not assigned yet, if they have a calculated birth day, > look for the generation in the decendants of the root people > that fits this birth day best. > > > I think that birth dates could be one way to order people within a > generation, but not to assign the generation number. > > > Not to assign an original generation number, but if everyone is shown, > distinct groups must be connected to each other. Then birth day is the > way to go. If you only do people connected to the active person, this > will not be a problem, but a general approach would be usefull too (eg > to see which people might have known each other). > > > 4. when assigning a person in todo list a generation, all > their descendants must be moved to. > Say a person goes to generatino 4. Then every descendant of > this person should have minimum of current assigned generation > + 4. So moveto list is appended with this new generation. > The move should not happen yet however. Instead, all people in > the todo list must be handled first. > After that, the move can happen to the highest generation in > the moveto list, so to max(moveto). > > > Yes, it is safe to shift an entire branch. > > I think that closes all holes. Problem will remain with > disconnected sets of people, where the root decendants also > don't overlap, eg root person of 1600 with decendants to 1750, > and another set of people starting in 1820. With some luck, > those will nevertheless with above approach start after the > last generation of the descendants of 1600 > > > This is a more complex problem than I anticipated. Although I can > see a solution now, I think that I will email the GeneaQuilt > authors. Perhaps they can let me know the algorithms they use? > > > Looking at the output Peter posted, I would not be amazed if there are > still some holes in their algorithms :-). Note that even in the > drawing at the start of the research article an error is present. Our > users would not be so forgiving :-D > Doing research myself, don't bet on it they don't tweak it here and > there to have nicer output. I have found the cause of this error. The program creates a LYR-file (layer file I think). This file is a text file with three columns: 1. Individual number or family number 2. Some kind of coordinate 3. Layer number, families have odd numbers while individuals have even numbers In the first LYR, column 2 is always 0.0 I5830 0.0 22 I5832 0.0 22 I5831 0.0 20 But in the correct file: I5830 21.375 24 I5832 475.71 24 I5831 475.83 22 Somehow the construction of the LYR file was not complete the first time. No idea why of course. /Peter > > Benny > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: <ad...@cs...> - 2012-08-23 19:30:22
|
Don't know if this would be of any use, but I thought I would mention it. My FilteredReports plugin (on the wiki) has the ability to determine what generation people are in. The plugin uses a filter, not a central person so that I can add multiple family lines into the same report. In order to do that, I need to figure out what generation each person that the filter returns should be in. It's quite possible that the "top" person in a rule (assuming you are returning descendants) is not in the same generation as another "top" person in a different rule making up the filter. If interested, look for the '_create_person_list' function. Traversing the list of people the filter returns, I'm able to use relationship.get_one_relationship to determine generation. Look around line 317 in the DescendantReport.py file in my plugin. > Trevor, > > At the moment, I am selecting the people for the chart by tree walking > from the active person. This has two benefits: > > 1. We avoid disjoint groups. > 2. If necessary, we could limit the number of people in the chart. > > Even determining the generation number in a continuous graph is not as > easy as I thought. We can always extend the functionality later, but I > would like to start with something simple. > > You are correct that siblings might be in a family without parents. > I'll look for an example of how GeneaQuilts represents this, but I don't > see a problem here. > > Nick. > > > On 23/08/12 19:11, W. Trevor King wrote: >> On Thu, Aug 23, 2012 at 06:53:41PM +0100, Nick Hall wrote: >>> On 23/08/12 16:02, Benny Malengier wrote: >>>> My idea was that the todo list people must be assigned an generation >>>> based on: >>>> >>>> a. step one: determine estimated birth of everyone in the todo list. >>>> We have a function for that >>> We should be able to assign a generation number without estimating >>> birth >>> dates. The Greek Gods file contains virtually no date information. I >>> expect that GeneaQuilt determines generation (layer) number purely by >>> analysing the structure of the graph. >> The Greek Gods don't have any disjoint sets. With the LinkedGroup >> algorithm, dabirthdates only come into play for aligning these >> disjoint groups. >> >>>> 2. do they have a sibling of generation j, then they should be >>>> generation j >>> If the have a sibling, then they cannot be a root node. >> They can if they are children in a family that has no known parents. >> >>>> 3. if not assigned yet, if they have a calculated birth day, look for >>>> the generation in the decendants of the root people that fits this >>>> birth day best. >>> I think that birth dates could be one way to order people within a >>> generation, but not to assign the generation number. >> If you don't have a relationship linkage, they are the only way to >> estimate alignment. >> >> Trevor >> > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Dale A. <dal...@ho...> - 2012-08-24 05:56:06
|
Nick, You may find the information on the following links, just as informative: https://sites.google.com/site/dglabprojects/Quilts http://cs.lnu.se/isovis/theses/finished/13991.pdf Dale. > Date: Thu, 23 Aug 2012 22:11:58 +0100 > From: nic...@ho... > To: ad...@cs... > CC: gra...@li...; wk...@tr... > Subject: Re: [Gramps-devel] New Quilt view > > Adam, > > Thanks. This is the sort of suggestion I was looking for. > > It might not be usable directly, but was certainly worth reading. > > Nick. > > > On 23/08/12 20:13, ad...@cs... wrote: > > Don't know if this would be of any use, but I thought I would mention it. > > My FilteredReports plugin (on the wiki) has the ability to determine what > > generation people are in. The plugin uses a filter, not a central person > > so that I can add multiple family lines into the same report. In order to > > do that, I need to figure out what generation each person that the filter > > returns should be in. It's quite possible that the "top" person in a rule > > (assuming you are returning descendants) is not in the same generation as > > another "top" person in a different rule making up the filter. > > > > If interested, look for the '_create_person_list' function. Traversing > > the list of people the filter returns, I'm able to use > > relationship.get_one_relationship to determine generation. Look around > > line 317 in the DescendantReport.py file in my plugin. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Benny M. <ben...@gm...> - 2012-08-24 07:58:53
|
Nick, Best make a GEP where all resources are collected. Benny 2012/8/24 Dale Athanasias <dal...@ho...> > Nick, > > You may find the information on the following links, just as informative: > > https://sites.google.com/site/dglabprojects/Quilts > > http://cs.lnu.se/isovis/theses/finished/13991.pdf > > Dale. > > > Date: Thu, 23 Aug 2012 22:11:58 +0100 > > From: nic...@ho... > > To: ad...@cs... > > CC: gra...@li...; wk...@tr... > > Subject: Re: [Gramps-devel] New Quilt view > > > > > Adam, > > > > Thanks. This is the sort of suggestion I was looking for. > > > > It might not be usable directly, but was certainly worth reading. > > > > Nick. > > > > > > On 23/08/12 20:13, ad...@cs... wrote: > > > Don't know if this would be of any use, but I thought I would mention > it. > > > My FilteredReports plugin (on the wiki) has the ability to determine > what > > > generation people are in. The plugin uses a filter, not a central > person > > > so that I can add multiple family lines into the same report. In order > to > > > do that, I need to figure out what generation each person that the > filter > > > returns should be in. It's quite possible that the "top" person in a > rule > > > (assuming you are returning descendants) is not in the same generation > as > > > another "top" person in a different rule making up the filter. > > > > > > If interested, look for the '_create_person_list' function. Traversing > > > the list of people the filter returns, I'm able to use > > > relationship.get_one_relationship to determine generation. Look around > > > line 317 in the DescendantReport.py file in my plugin. > > > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. > Discussions > > will include endpoint security, mobile security and the latest in > malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Nick H. <nic...@ho...> - 2012-08-24 20:16:14
|
I have created GEPS 030 to discuss new visualization techniques. I also started a section on TimeNets which were mentioned on the gramps-users list. Gerald was investigating. Nick. On 24/08/12 08:58, Benny Malengier wrote: > Nick, > > Best make a GEP where all resources are collected. > > Benny > > 2012/8/24 Dale Athanasias <dal...@ho... > <mailto:dal...@ho...>> > > Nick, > > You may find the information on the following links, just as > informative: > > https://sites.google.com/site/dglabprojects/Quilts > > http://cs.lnu.se/isovis/theses/finished/13991.pdf > > Dale. > > > Date: Thu, 23 Aug 2012 22:11:58 +0100 > > From: nic...@ho... <mailto:nic...@ho...> > > To: ad...@cs... <mailto:ad...@cs...> > > CC: gra...@li... > <mailto:gra...@li...>; wk...@tr... > <mailto:wk...@tr...> > > Subject: Re: [Gramps-devel] New Quilt view > > > > > Adam, > > > > Thanks. This is the sort of suggestion I was looking for. > > > > It might not be usable directly, but was certainly worth reading. > > > > Nick. > > > > > > On 23/08/12 20:13, ad...@cs... <mailto:ad...@cs...> wrote: > > > Don't know if this would be of any use, but I thought I would > mention it. > > > My FilteredReports plugin (on the wiki) has the ability to > determine what > > > generation people are in. The plugin uses a filter, not a > central person > > > so that I can add multiple family lines into the same report. > In order to > > > do that, I need to figure out what generation each person that > the filter > > > returns should be in. It's quite possible that the "top" > person in a rule > > > (assuming you are returning descendants) is not in the same > generation as > > > another "top" person in a different rule making up the filter. > > > > > > If interested, look for the '_create_person_list' function. > Traversing > > > the list of people the filter returns, I'm able to use > > > relationship.get_one_relationship to determine generation. > Look around > > > line 317 in the DescendantReport.py file in my plugin. > > > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. > Discussions > > will include endpoint security, mobile security and the latest > in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > <mailto:Gra...@li...> > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest in > malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > <mailto:Gra...@li...> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Benny M. <ben...@gm...> - 2012-08-24 20:36:56
|
2012/8/24 Nick Hall <nic...@ho...> > I have created GEPS 030 to discuss new visualization techniques. > > I also started a section on TimeNets which were mentioned on the > gramps-users list. Gerald was investigating. > For those needing a link: http://www.gramps-project.org/wiki/index.php?title=GEPS_030:_New_Visualization_Techniques |
From: Emmanuel B. <br...@ad...> - 2012-09-26 08:24:12
|
> Emmanuel, I notice your code is GPL3. So Nick would better not look at it if he wants to use in Gramps which is GPL2 or later. > Adding one GPL3 piece would effectively make everything GPL3. > As you use a web application, why GPL3, AGPL3 would seem better then if you want the v3 of the GPL licenses. I am fine with changing the license to GPL2, no problem with that. Basically, I use geneapro as a ground for experimentation, but I still use Gramps as my main genealogy application. So the more goes into Gramps, the better for me :-) |
From: Benny M. <ben...@gm...> - 2012-09-26 08:30:15
|
2012/9/26 Emmanuel Briot <br...@ad...> > > > Emmanuel, I notice your code is GPL3. So Nick would better not look at > it if he wants to use in Gramps which is GPL2 or later. > > Adding one GPL3 piece would effectively make everything GPL3. > > As you use a web application, why GPL3, AGPL3 would seem better then if > you want the v3 of the GPL licenses. > > I am fine with changing the license to GPL2, no problem with that. > Basically, I use geneapro as a ground for experimentation, but I still use > Gramps as my main > genealogy application. So the more goes into Gramps, the better for me :-) > Ok, only pieces Nick would use would need an approval of you to change to GPL2 or later. I think Nick already has a lot working with a GTK based view, so mainly the computation of positions is the blocker. The graph is interesting code, but maintaining such a thing in a genealogy application often leads to problems later on when maintenance is needed. A small library for it is then a nice option (under LGPL or BSD python licence) :-D Did you investigate http://networkx.lanl.gov/pygraphviz/ ? Benny |
From: Emmanuel B. <br...@ad...> - 2012-09-26 08:41:45
|
> Ok, only pieces Nick would use would need an approval of you to change to GPL2 or later. It *was* a GPL later, since it was GPL 3. Now, I do not know much about these, so I have simply changed the text in the README to say GPL 2, which is fine with me. > I think Nick already has a lot working with a GTK based view, so mainly the computation > of positions is the blocker. Right, this is indeed the most difficult part. There are lots of small issues in the GUI view itself, but these are relatively trivial to handle, just need time. > The graph is interesting code, but maintaining such a thing in a genealogy application often leads to problems later on when maintenance is needed. A small library for it is then a nice option (under LGPL or BSD python licence) :-D Writing a graph implementation in python is relatively trivial in fact, so I am not sure there really is a point in having a separate full blown library (though I reserve the right to change my mind here :-) > Did you investigate http://networkx.lanl.gov/pygraphviz/ ? Yes I did. Several reasons why I did not use it: - I could not get dot itself to work on my OSX laptop, although I did not investigate much since I have access to other machines where it is installed. - It is more fun to understand the algorithm itself. In fact, I did not realize immediately that the layout in Quilts is really very similar to what dot does (but given the properties of a genealogy graph, we do not need all the complexity that dot has). - pygraphviz will spawn an external executable ("dot"), which is not very fast and on a web server could lead to performance problems (although admittedly doing the layout in python is not the fastest way either -- I can layout my 2000 people graph in about 0.16s on my very fast laptop, so I was fine with it for now). It likely is a viable option for Gramps, though, since there is already an optional dependency on dot in any case. |
From: Benny M. <ben...@gm...> - 2012-09-26 09:07:44
|
2012/9/26 Emmanuel Briot <br...@ad...> > > Ok, only pieces Nick would use would need an approval of you to change > to GPL2 or later. > > It *was* a GPL later, since it was GPL 3. Now, I do not know much about > these, so I have > simply changed the text in the README to say GPL 2, which is fine with me. > We investigated it somewhat in the past. Note that you should make it "GPL v2 or later", not just GPL v2. Like this, the code can be used by people who want GPL3 or use a license compatible with GPL 3, but also by people who use GPL 2 only. Benny |
From: Emmanuel B. <br...@ad...> - 2012-09-26 12:39:46
|
Nick, I am sure you have been able to make progress on this view by now. Just in case you are interested however, I have implemented a quilts view in my toy application geneapro. This is GPL code, so you are of course free to copy all or part of the code as you like. There are several packages involved: - geneapro/utils/graph.py Contains a standard directed graph data structure, independent from genealogy, which among others provide various layout functions to split the nodes into layers and sort the nodes within each layer to minimize the number of edge crossings. The ranking of nodes is not optimal yet, and certainly not as good as graphviz provides, I am still working on that part. Still, it does a descent job to get started. - geneapro/view/graph.py is the django view for the Quilts view. The function from_db is the only one specific to geneapro, that would have to be changed for Gramps. It basically creates a graph of all persons in the database, with parents and spouses relationships. It then computes the layout of the graph. - resources/media/quilts.js is a javascript implementation of the quilts view itself. It draws the pretty picture and allows the user to click on a name to highlight all ancestors and descendants. This could be interesting to gramps online. Geneapro will probably never be a full blown application, so I would love to have such a view in Gramps itself. If you think there is anything worth reusing in the code, please feel free to do so, and ask questions if some things are unclear. The code is not industrial quality yet (as I mentioned, the ranking could stand some improvements). Git: https://github.com/briot/geneapro Screenshot: http://briot.github.com/geneapro/screenshots.html Emmanuel |
From: Benny M. <ben...@gm...> - 2012-09-26 12:53:46
|
2012/9/26 Emmanuel Briot <br...@ad...> > > > Screenshot: > http://briot.github.com/geneapro/screenshots.html > > Nice fanchart also. The white for the marriage date is a good find. What is the wedge for, that box to the left? Just details on the central person? I suppose in Gramps I should add birth and death year also to the new fanchart in trunk, it seems everybody adds that. Now only visible in the toolbox. You also use a lot of different colors. Some specific meaning? Benny > > Emmanuel > |
From: Emmanuel B. <br...@ad...> - 2012-09-26 13:00:21
|
> Nice fanchart also. > The white for the marriage date is a good find. What is the wedge for, that box to the left? Just details on the central person? Right, the wedge is to give space for the central person. I also display the children for easy navigation. I noticed you took the approach of displaying the children in the central area, which I haven't really taken a look at yet. It might be a better approach. > I suppose in Gramps I should add birth and death year also to the new fanchart in trunk, it seems everybody adds that. Now only visible in the toolbox. The drawback, of course, is that it takes space. What I am interested in in geneapro is the check mark next to the dates, which indicate whether there is or not a reliable (or so I think) source for this. That helps me on finding what to concentrate my research on. That's the main reason for displaying the dates. The best approach, probably, would be to allow zooming in on the fan chart, and display more info as we zoom in: in the first few zoom steps, we start by enlarging the font. When it reaches a given threshold, we start adding new lines to the box, for instance the dates. That said, displaying in the toolbar is probably good enough. > You also use a lot of different colors. Some specific meaning? Yes, that's something I actually like in geneapro. It is possible to specify rules for the highlighting of people. The rules used in the screenshots are of course way too much, but the approach is similar to what you implemented recently for the fan chart, although it seems more flexible in geneapro: the rules are defined in a python file, and are user-writable. For examples, see http://briot.github.com/geneapro/highlighting.html So basically an extension of what you now have for the fan charts. |
From: Nick H. <nic...@ho...> - 2012-10-01 21:46:17
|
Emmanuel, Thanks. I'll have a look at this, but don't have much time at the moment. So far, I have simple functionality including the basic chart, panning/zooming and a preview window. I need to improve my ancestor and descendant highlighting and add filter functionality. I use graphviz for the layout (as does GeneaQuilts) which is quite fast when tweaked. I use pygoocanvas for the actual graphics, which also works well. Nick. On 26/09/12 13:39, Emmanuel Briot wrote: > > Nick, > > I am sure you have been able to make progress on this view by now. > Just in case you are interested however, I have implemented a quilts view > in my toy application geneapro. This is GPL code, so you are of course > free > to copy all or part of the code as you like. There are several packages > involved: > > - geneapro/utils/graph.py > Contains a standard directed graph data structure, independent from > genealogy, which among others provide various layout functions > to split > the nodes into layers and sort the nodes within each layer to > minimize > the number of edge crossings. > The ranking of nodes is not optimal yet, and certainly not as > good as > graphviz provides, I am still working on that part. Still, it > does a descent > job to get started. > > - geneapro/view/graph.py > is the django view for the Quilts view. The function from_db is > the only > one specific to geneapro, that would have to be changed for Gramps. > It basically creates a graph of all persons in the database, > with parents > and spouses relationships. It then computes the layout of the graph. > > - resources/media/quilts.js > is a javascript implementation of the quilts view itself. It > draws the > pretty picture and allows the user to click on a name to > highlight all > ancestors and descendants. This could be interesting to gramps > online. > > Geneapro will probably never be a full blown application, so I would > love to > have such a view in Gramps itself. If you think there is anything > worth reusing > in the code, please feel free to do so, and ask questions if some > things are > unclear. The code is not industrial quality yet (as I mentioned, the > ranking > could stand some improvements). > > Git: > https://github.com/briot/geneapro > > Screenshot: > http://briot.github.com/geneapro/screenshots.html > > > Emmanuel |
From: Emmanuel B. <br...@ad...> - 2012-10-02 07:20:36
|
> So far, I have simple functionality including the basic chart, panning/zooming and a preview window. I need to improve my ancestor and descendant highlighting and add filter functionality. Right, that's basically where I am too (using a HTML5 front-end, which, again, I would be happy to contribute to Gramps's web view). Working on the efficiency a bit, since we definitely want zooming and panning to be fast, and in fact most of the layout can be computed in advance (and needs to be recomputed only when filtering). > I use graphviz for the layout (as does GeneaQuilts) which is quite fast when tweaked. I use pygoocanvas for the actual graphics, which also works well. I might end up using graphviz as well, since it definitely has more advanced algorithms than anyone would want to rewrite. I thought the nature of genealogical data would make some of the more advanced algorithms useless (for instance, the placement of nodes at each layer, as opposed to their ordering, is useless in the case of the Quilts view), but maybe not so. I am definitely happy to see that more views in Gramps (fanchart and quilts at least) are using a canvas rather than a fixed layout. That definitely will improve a lot the capabilities the developers can add to their views… Emmanuel |
From: Benny M. <ben...@gm...> - 2012-10-02 07:32:57
|
2012/10/2 Emmanuel Briot <br...@ad...> > > So far, I have simple functionality including the basic chart, > panning/zooming and a preview window. I need to improve my ancestor and > descendant highlighting and add filter functionality. > > Right, that's basically where I am too (using a HTML5 front-end, which, > again, I would be happy to > contribute to Gramps's web view). As you will have noted from other mails, the static web site is not in good shape. I would not mind nice features like these, but you should then also go the extra mile to submit a nice patch to add this, a bit like the embedded map I suppose. Benny |