## Re: [Gramps-devel] New Quilt view

 Re: [Gramps-devel] New Quilt view From: Peter Landgren - 2012-08-24 10:01:49 Attachments: Message as HTML ```Benny Malengier skrev 2012-08-23 21:03: > > > 2012/8/23 Nick Hall > > > 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 > Gramps-devel@... > https://lists.sourceforge.net/lists/listinfo/gramps-devel ```