2012/8/23 Nick Hall <nick__hall@hotmail.com>
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.

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.