2012/8/23 Nick Hall <firstname.lastname@example.org>
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.
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 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.
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)
When we process a branch, we will know the correct generation number when we hit the existing tree.
c. step tree, determine what the correct generation is for non root people in the todo list
Only for a simple tree. The spouse may belong to a different generation when we have inter-marriages.
1. do they have a spouse/husband of generation j, then they should be generation j
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 have a sibling, then they cannot be a root node.
2. do they have a sibling of generation j, then they should be generation j
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.
I think that birth dates could be one way to order people within a generation, but not to assign the generation number.
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.
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).
Yes, it is safe to shift an entire branch.
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).
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?
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
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.