Benny Malengier skrev 2012-08-23 21:03:
>
>
> 2012/8/23 Nick Hall <nick__hall@...
> <mailto: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
|