gramps

2012/8/23 Nick Hall <nick__hall@...>

> 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.
>
>

On Thu, Aug 23, 2012 at 11:02 AM, Benny Malengier
<benny.malengier@...> wrote:
>
>
> 2012/8/23 Nick Hall <nick__hall@...>
>>
>> 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
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

2012/8/23 W. Trevor King <wking@...>

> 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
>

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.

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.

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
>

2012/8/23 Nick Hall <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.

Benny

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
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

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.

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, adam@... 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.

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: nick__hall@...
> To: adam@...
> CC: gramps-devel@...; wking@...
> 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, adam@... 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
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

Nick,

Best make a GEP where all resources are collected.

Benny

2012/8/24 Dale Athanasias <dalegrind@...>

>  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: nick__hall@...
> > To: adam@...
> > CC: gramps-devel@...; wking@...
> > 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, adam@... 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
> > Gramps-devel@...
> > 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
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>

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

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 <dalegrind@... 
> <mailto:dalegrind@...>>
>
>     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: nick__hall@... <mailto:nick__hall@...>
>     > To: adam@... <mailto:adam@...>
>     > CC: gramps-devel@...
>     <mailto:gramps-devel@...>; wking@...
>     <mailto:wking@...>
>     > 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, adam@... <mailto:adam@...> 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
>     > Gramps-devel@...
>     <mailto:Gramps-devel@...>
>     > 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
>     Gramps-devel@...
>     <mailto:Gramps-devel@...>
>     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
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

2012/8/24 Nick Hall <nick__hall@...>

>  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

> 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 :-)

2012/9/26 Emmanuel Briot <briot@...>

>
> > 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

> 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.

2012/9/26 Emmanuel Briot <briot@...>

> > 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

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

2012/9/26 Emmanuel Briot <briot@...>

>
>
> 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
>

> 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.

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

> 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

2012/10/2 Emmanuel Briot <briot@...>

> > 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

Hello Nick


>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.


For running in trunk you should ditch pygoocanvas and use the version 2 of goocanvas, which is supposed to work with introspection.

I have made a start on converting GraphView so that can run in trunk.

Bye

Gary

2012/10/3 Gary Burton <bury_lancs@...>

> Hello Nick
>
>
> >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.
>
>
> For running in trunk you should ditch pygoocanvas and use the version 2 of
> goocanvas, which is supposed to work with introspection.
>
> I have made a start on converting GraphView so that can run in trunk.
>

In light of what Paul said, stable views and plugins that have user
following can be included in normal Gramps. Don't know if graphview falls
under this already.

Benny

Gary,

Thanks.  As a test, I converted my code and it almost works with 
introspection.

I noticed the following:

1. All GooCanvas objects are prefixed with "Canvas".  Perhaps this is 
because the functions in C are prefixed with "goo_canvas" instead of 
"goocanvas"?

2. There doesn't seem to be an override to provide a pythonic 
constructor for Points.

3. The get_natural_extents method of CanvasText isn't annotated 
correctly.  I would expect both the ink_rect and logical_rect parameters 
to be annotated as (out).

The above don't cause any real problems though, but I found a bug:

4. When connecting an event handler to an object, the callback event 
parameter returns void instead of a button number in event.button.

Did you have any problems?

Nick.


On 03/10/12 08:22, Gary Burton wrote:
> Hello Nick
>
>
>> 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.
>
> For running in trunk you should ditch pygoocanvas and use the version 2 of goocanvas, which is supposed to work with introspection.
>
> I have made a start on converting GraphView so that can run in trunk.
>
> Bye
>
> Gary
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>