New Quilt view

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

New Quilt view

Nick Hall-6
Devs,

There is a thread on gramps-users discussing a new visualisation layout.

A feature request has been opened for it:  4649: GeneaQuilts
visualization integration

http://www.gramps-project.org/bugs/view.php?id=4649

The visualisation was created as part of a research project.  The
original article and a Java implementation can be found on the following
website.

http://www.aviz.fr/Research/Geneaquilts

Serge has already contacted the authors and they are happy for us to
write our own implementation.  Their source code is not available at the
moment, and they have suggested that we start from scratch using their
article and program as a specification.

I suggested writing a view, loosely basing the design on that of the
Timeline Pedigree view.

What do you think?

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

DS Blank
On Tue, Aug 21, 2012 at 10:11 AM, Nick Hall <[hidden email]> wrote:

> Devs,
>
> There is a thread on gramps-users discussing a new visualisation layout.
>
> A feature request has been opened for it:  4649: GeneaQuilts
> visualization integration
>
> http://www.gramps-project.org/bugs/view.php?id=4649
>
> The visualisation was created as part of a research project.  The
> original article and a Java implementation can be found on the following
> website.
>
> http://www.aviz.fr/Research/Geneaquilts
>
> Serge has already contacted the authors and they are happy for us to
> write our own implementation.  Their source code is not available at the
> moment, and they have suggested that we start from scratch using their
> article and program as a specification.
>
> I suggested writing a view, loosely basing the design on that of the
> Timeline Pedigree view.
>
> What do you think?

Absolutely +1 !

I read the paper and looked over the project, and it seems not too
difficult. I suggest using a low-level Cairo interface, as one would
want to see hundreds and hundreds of people, no doubt.

I think starting with Gary's GraphView in Addons would be a great
starting point. The FanChart view might also have some UI hints.

(BTW, I like the trick they did at the top of their paper --- rotating
the view to get as much in between the paper margins. There is no
reason why we couldn't have a view that rotated like that. More good
trig hints in FanChart view :)

-Doug

> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Benny Malengier
In reply to this post by Nick Hall-6
When designing, you should clearly define how strange data can be presented.
Eg, the pedigreeview has a problem with people with several sets of parents. Quiltview would not have this problem. However, I'm wondering about marriages that span generations.
Take a person that marries his own granddaughter. Looking at the Greek God example (Hades and Persepone) you skip a generation. However, they don't write an F of family nucleus anymore.

Extra people that come in, also mean they need to be added to the correct generation. It seems they are added to the generation of their partner.

Some ideas:
1. Instead of only F for family, we can use M for married, P for partners, D for divorced, and O if offspring in other relation types
2. I don't like the dot for women, square for man, perhaps just use the symbols
3. allow color changing via code, eg men in blue boxes, ...
4. People added to a generation, not offspring of previous one is indicated with the horizontal line not connecting to the left. This seems weak to me. I would suggest putting them under the children, in some way that is more visible, eg no vertical lines in front (not needed as they are not offspring).

As to drawing, people will want printout too. This is mainly text, not very graphical, so using a textual layout is also a possibility.

Benny

2012/8/21 Nick Hall <[hidden email]>
Devs,

There is a thread on gramps-users discussing a new visualisation layout.

A feature request has been opened for it:  4649: GeneaQuilts
visualization integration

http://www.gramps-project.org/bugs/view.php?id=4649

The visualisation was created as part of a research project.  The
original article and a Java implementation can be found on the following
website.

http://www.aviz.fr/Research/Geneaquilts

Serge has already contacted the authors and they are happy for us to
write our own implementation.  Their source code is not available at the
moment, and they have suggested that we start from scratch using their
article and program as a specification.

I suggested writing a view, loosely basing the design on that of the
Timeline Pedigree view.

What do you think?

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Benny Malengier
As an aside, it would be great to have the gedcom for greek gods, lord of the rings, adam and eve, ...
They are great for PR material.

Benny

2012/8/21 Benny Malengier <[hidden email]>
When designing, you should clearly define how strange data can be presented.
Eg, the pedigreeview has a problem with people with several sets of parents. Quiltview would not have this problem. However, I'm wondering about marriages that span generations.
Take a person that marries his own granddaughter. Looking at the Greek God example (Hades and Persepone) you skip a generation. However, they don't write an F of family nucleus anymore.

Extra people that come in, also mean they need to be added to the correct generation. It seems they are added to the generation of their partner.

Some ideas:
1. Instead of only F for family, we can use M for married, P for partners, D for divorced, and O if offspring in other relation types
2. I don't like the dot for women, square for man, perhaps just use the symbols
3. allow color changing via code, eg men in blue boxes, ...
4. People added to a generation, not offspring of previous one is indicated with the horizontal line not connecting to the left. This seems weak to me. I would suggest putting them under the children, in some way that is more visible, eg no vertical lines in front (not needed as they are not offspring).

As to drawing, people will want printout too. This is mainly text, not very graphical, so using a textual layout is also a possibility.

Benny


2012/8/21 Nick Hall <[hidden email]>
Devs,

There is a thread on gramps-users discussing a new visualisation layout.

A feature request has been opened for it:  4649: GeneaQuilts
visualization integration

http://www.gramps-project.org/bugs/view.php?id=4649

The visualisation was created as part of a research project.  The
original article and a Java implementation can be found on the following
website.

http://www.aviz.fr/Research/Geneaquilts

Serge has already contacted the authors and they are happy for us to
write our own implementation.  Their source code is not available at the
moment, and they have suggested that we start from scratch using their
article and program as a specification.

I suggested writing a view, loosely basing the design on that of the
Timeline Pedigree view.

What do you think?

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

DS Blank
On Tue, Aug 21, 2012 at 10:46 AM, Benny Malengier
<[hidden email]> wrote:
> As an aside, it would be great to have the gedcom for greek gods, lord of
> the rings, adam and eve, ...
> They are great for PR material.

...and testing!

http://famousfamilytrees.blogspot.com/

-Doug


> Benny
>
>
> 2012/8/21 Benny Malengier <[hidden email]>
>>
>> When designing, you should clearly define how strange data can be
>> presented.
>> Eg, the pedigreeview has a problem with people with several sets of
>> parents. Quiltview would not have this problem. However, I'm wondering about
>> marriages that span generations.
>> Take a person that marries his own granddaughter. Looking at the Greek God
>> example (Hades and Persepone) you skip a generation. However, they don't
>> write an F of family nucleus anymore.
>>
>> Extra people that come in, also mean they need to be added to the correct
>> generation. It seems they are added to the generation of their partner.
>>
>> Some ideas:
>> 1. Instead of only F for family, we can use M for married, P for partners,
>> D for divorced, and O if offspring in other relation types
>> 2. I don't like the dot for women, square for man, perhaps just use the
>> symbols
>> 3. allow color changing via code, eg men in blue boxes, ...
>> 4. People added to a generation, not offspring of previous one is
>> indicated with the horizontal line not connecting to the left. This seems
>> weak to me. I would suggest putting them under the children, in some way
>> that is more visible, eg no vertical lines in front (not needed as they are
>> not offspring).
>>
>> As to drawing, people will want printout too. This is mainly text, not
>> very graphical, so using a textual layout is also a possibility.
>>
>> Benny
>>
>>
>> 2012/8/21 Nick Hall <[hidden email]>
>>>
>>> Devs,
>>>
>>> There is a thread on gramps-users discussing a new visualisation layout.
>>>
>>> A feature request has been opened for it:  4649: GeneaQuilts
>>> visualization integration
>>>
>>> http://www.gramps-project.org/bugs/view.php?id=4649
>>>
>>> The visualisation was created as part of a research project.  The
>>> original article and a Java implementation can be found on the following
>>> website.
>>>
>>> http://www.aviz.fr/Research/Geneaquilts
>>>
>>> Serge has already contacted the authors and they are happy for us to
>>> write our own implementation.  Their source code is not available at the
>>> moment, and they have suggested that we start from scratch using their
>>> article and program as a specification.
>>>
>>> I suggested writing a view, loosely basing the design on that of the
>>> Timeline Pedigree view.
>>>
>>> What do you think?
>>>
>>> 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
>>> [hidden email]
>>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

DS Blank
In reply to this post by Benny Malengier
On Tue, Aug 21, 2012 at 10:43 AM, Benny Malengier
<[hidden email]> wrote:

> When designing, you should clearly define how strange data can be presented.
> Eg, the pedigreeview has a problem with people with several sets of parents.
> Quiltview would not have this problem. However, I'm wondering about
> marriages that span generations.
> Take a person that marries his own granddaughter. Looking at the Greek God
> example (Hades and Persepone) you skip a generation. However, they don't
> write an F of family nucleus anymore.
>
> Extra people that come in, also mean they need to be added to the correct
> generation. It seems they are added to the generation of their partner.
>
> Some ideas:
> 1. Instead of only F for family, we can use M for married, P for partners, D
> for divorced, and O if offspring in other relation types
> 2. I don't like the dot for women, square for man, perhaps just use the
> symbols

Including "other" (not in GenderTypes yet) and "unknown". Also, this
display would work fine for families with more than two parents. For
"other" symbol, see:

http://www.gramps-project.org/bugs/view.php?id=5730

> 3. allow color changing via code, eg men in blue boxes, ...
> 4. People added to a generation, not offspring of previous one is indicated
> with the horizontal line not connecting to the left. This seems weak to me.
> I would suggest putting them under the children, in some way that is more
> visible, eg no vertical lines in front (not needed as they are not
> offspring).
>
> As to drawing, people will want printout too. This is mainly text, not very
> graphical, so using a textual layout is also a possibility.

Cairo can be printed. As this view is predominately useful in a UI, I
wouldn't worry too much about a textual version (although that would
be a good way to get started coding). As we want to see lots of
people, I would not use our Document utilities to construct the
view... too much overhead.

-Doug

> Benny
>
>
> 2012/8/21 Nick Hall <[hidden email]>
>>
>> Devs,
>>
>> There is a thread on gramps-users discussing a new visualisation layout.
>>
>> A feature request has been opened for it:  4649: GeneaQuilts
>> visualization integration
>>
>> http://www.gramps-project.org/bugs/view.php?id=4649
>>
>> The visualisation was created as part of a research project.  The
>> original article and a Java implementation can be found on the following
>> website.
>>
>> http://www.aviz.fr/Research/Geneaquilts
>>
>> Serge has already contacted the authors and they are happy for us to
>> write our own implementation.  Their source code is not available at the
>> moment, and they have suggested that we start from scratch using their
>> article and program as a specification.
>>
>> I suggested writing a view, loosely basing the design on that of the
>> Timeline Pedigree view.
>>
>> What do you think?
>>
>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Nick Hall-6
In reply to this post by DS Blank
On 21/08/12 15:37, Doug Blank wrote:

> On Tue, Aug 21, 2012 at 10:11 AM, Nick Hall <[hidden email]> wrote:
>> Devs,
>>
>> There is a thread on gramps-users discussing a new visualisation layout.
>>
>> A feature request has been opened for it:  4649: GeneaQuilts
>> visualization integration
>>
>> http://www.gramps-project.org/bugs/view.php?id=4649
>>
>> The visualisation was created as part of a research project.  The
>> original article and a Java implementation can be found on the following
>> website.
>>
>> http://www.aviz.fr/Research/Geneaquilts
>>
>> Serge has already contacted the authors and they are happy for us to
>> write our own implementation.  Their source code is not available at the
>> moment, and they have suggested that we start from scratch using their
>> article and program as a specification.
>>
>> I suggested writing a view, loosely basing the design on that of the
>> Timeline Pedigree view.
>>
>> What do you think?
> Absolutely +1 !
>
> I read the paper and looked over the project, and it seems not too
> difficult. I suggest using a low-level Cairo interface, as one would
> want to see hundreds and hundreds of people, no doubt.

Yes, using cairo is the best way to go.  The java application can
handles thousands of people.


>
> I think starting with Gary's GraphView in Addons would be a great
> starting point. The FanChart view might also have some UI hints.

I'll have a look at both of these before I start.


> (BTW, I like the trick they did at the top of their paper --- rotating
> the view to get as much in between the paper margins. There is no
> reason why we couldn't have a view that rotated like that. More good
> trig hints in FanChart view :)

It looks good rotated.  We can always try it.

Nick.


>
> -Doug
>
>> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Nick Hall-6
In reply to this post by Benny Malengier
On 21/08/12 15:43, Benny Malengier wrote:
When designing, you should clearly define how strange data can be presented.
Eg, the pedigreeview has a problem with people with several sets of parents. Quiltview would not have this problem. However, I'm wondering about marriages that span generations.
Take a person that marries his own granddaughter. Looking at the Greek God example (Hades and Persepone) you skip a generation. However, they don't write an F of family nucleus anymore.


These more unusual cases are handled very well with this visualisation.


Extra people that come in, also mean they need to be added to the correct generation. It seems they are added to the generation of their partner.

Yes, the first step will be to correctly determine which generation each person belongs to.



Some ideas:
1. Instead of only F for family, we can use M for married, P for partners, D for divorced, and O if offspring in other relation types
2. I don't like the dot for women, square for man, perhaps just use the symbols
3. allow color changing via code, eg men in blue boxes, ...

These should be easy to make customisable.


4. People added to a generation, not offspring of previous one is indicated with the horizontal line not connecting to the left. This seems weak to me. I would suggest putting them under the children, in some way that is more visible, eg no vertical lines in front (not needed as they are not offspring).

At the moment, I'm not sure what algorithm they use to determine the order of people and families.  According to a news group post, the order tries to place people closest to the diagonal.  Other sort orders would be possible though.


Nick.



As to drawing, people will want printout too. This is mainly text, not very graphical, so using a textual layout is also a possibility.

Benny

2012/8/21 Nick Hall <[hidden email]>
Devs,

There is a thread on gramps-users discussing a new visualisation layout.

A feature request has been opened for it:  4649: GeneaQuilts
visualization integration

http://www.gramps-project.org/bugs/view.php?id=4649

The visualisation was created as part of a research project.  The
original article and a Java implementation can be found on the following
website.

http://www.aviz.fr/Research/Geneaquilts

Serge has already contacted the authors and they are happy for us to
write our own implementation.  Their source code is not available at the
moment, and they have suggested that we start from scratch using their
article and program as a specification.

I suggested writing a view, loosely basing the design on that of the
Timeline Pedigree view.

What do you think?

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Peter Landgren
In reply to this post by Nick Hall-6
Nick Hall skrev 2012-08-21 19:13:

> On 21/08/12 15:37, Doug Blank wrote:
>> On Tue, Aug 21, 2012 at 10:11 AM, Nick Hall <[hidden email]> wrote:
>>> Devs,
>>>
>>> There is a thread on gramps-users discussing a new visualisation layout.
>>>
>>> A feature request has been opened for it:  4649: GeneaQuilts
>>> visualization integration
>>>
>>> http://www.gramps-project.org/bugs/view.php?id=4649
>>>
>>> The visualisation was created as part of a research project.  The
>>> original article and a Java implementation can be found on the following
>>> website.
>>>
>>> http://www.aviz.fr/Research/Geneaquilts
>>>
>>> Serge has already contacted the authors and they are happy for us to
>>> write our own implementation.  Their source code is not available at the
>>> moment, and they have suggested that we start from scratch using their
>>> article and program as a specification.
>>>
>>> I suggested writing a view, loosely basing the design on that of the
>>> Timeline Pedigree view.
>>>
>>> What do you think?
>> Absolutely +1 !
>>
>> I read the paper and looked over the project, and it seems not too
>> difficult. I suggest using a low-level Cairo interface, as one would
>> want to see hundreds and hundreds of people, no doubt.
> Yes, using cairo is the best way to go.  The java application can
> handles thousands of people.
With my 9000 family tree, it looks very strange. See attachment.

/Peter

>
>> I think starting with Gary's GraphView in Addons would be a great
>> starting point. The FanChart view might also have some UI hints.
> I'll have a look at both of these before I start.
>
>
>> (BTW, I like the trick they did at the top of their paper --- rotating
>> the view to get as much in between the paper margins. There is no
>> reason why we couldn't have a view that rotated like that. More good
>> trig hints in FanChart view :)
> It looks good rotated.  We can always try it.
>
> Nick.
>
>
>> -Doug
>>
>>> 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
>>> [hidden email]
>>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

Screenshot - 2012-08-21 , 19_27_31.jpg (22K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Benny Malengier


2012/8/21 Peter Landgren <[hidden email]>
Nick Hall skrev 2012-08-21 19:13:

On 21/08/12 15:37, Doug Blank wrote:
On Tue, Aug 21, 2012 at 10:11 AM, Nick Hall <[hidden email]> wrote:
Devs,

There is a thread on gramps-users discussing a new visualisation layout.

A feature request has been opened for it:  4649: GeneaQuilts
visualization integration

http://www.gramps-project.org/bugs/view.php?id=4649

The visualisation was created as part of a research project.  The
original article and a Java implementation can be found on the following
website.

http://www.aviz.fr/Research/Geneaquilts

Serge has already contacted the authors and they are happy for us to
write our own implementation.  Their source code is not available at the
moment, and they have suggested that we start from scratch using their
article and program as a specification.

I suggested writing a view, loosely basing the design on that of the
Timeline Pedigree view.

What do you think?
Absolutely +1 !

I read the paper and looked over the project, and it seems not too
difficult. I suggest using a low-level Cairo interface, as one would
want to see hundreds and hundreds of people, no doubt.
Yes, using cairo is the best way to go.  The java application can
handles thousands of people.
With my 9000 family tree, it looks very strange. See attachment.

Well, it is research code, in Gramps it would have to be more robust.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Benny Malengier
In reply to this post by Nick Hall-6


2012/8/21 Nick Hall <[hidden email]>
On 21/08/12 15:43, Benny Malengier wrote:
When designing, you should clearly define how strange data can be presented.
Eg, the pedigreeview has a problem with people with several sets of parents. Quiltview would not have this problem. However, I'm wondering about marriages that span generations.
Take a person that marries his own granddaughter. Looking at the Greek God example (Hades and Persepone) you skip a generation. However, they don't write an F of family nucleus anymore.


These more unusual cases are handled very well with this visualisation.



Extra people that come in, also mean they need to be added to the correct generation. It seems they are added to the generation of their partner.

Yes, the first step will be to correctly determine which generation each person belongs to.




Some ideas:
1. Instead of only F for family, we can use M for married, P for partners, D for divorced, and O if offspring in other relation types
2. I don't like the dot for women, square for man, perhaps just use the symbols
3. allow color changing via code, eg men in blue boxes, ...

These should be easy to make customisable.



4. People added to a generation, not offspring of previous one is indicated with the horizontal line not connecting to the left. This seems weak to me. I would suggest putting them under the children, in some way that is more visible, eg no vertical lines in front (not needed as they are not offspring).

At the moment, I'm not sure what algorithm they use to determine the order of people and families.  According to a news group post, the order tries to place people closest to the diagonal.  Other sort orders would be possible though.

I would suggest a general gen function: order_in_generations.
Input would be a list of people. Algorithm could be:

1. i=1, put all people in generation i
2. go over all people in generation i, if no parents, put a copy in todo list
3. go over all people in generation i, if one of their parents is in generation i, move person to generation i+1
4. i = i+1 go to point 3.

After this you should have a division in generations. For the people in the todo list, based on estimated date of birth or siblings or partners, they can be distributed over the correct generation.

This general algorithm can be reused in other parts (eg a generations report or quickview, could be a way to test the algorithm on robustness, if released first, we can try it on our data). With it, you have the start for the drawing. Next would be to order them in a generation (people with parents present at top, siblings together I assume).
At that point you have a structure which is the basis for different type of reports (a timeline could be used). Per generation you can compute first birth date, and last death, to have an overview, ...

Benny
 


Nick.




As to drawing, people will want printout too. This is mainly text, not very graphical, so using a textual layout is also a possibility.

Benny

2012/8/21 Nick Hall <[hidden email]>
Devs,

There is a thread on gramps-users discussing a new visualisation layout.

A feature request has been opened for it:  4649: GeneaQuilts
visualization integration

http://www.gramps-project.org/bugs/view.php?id=4649

The visualisation was created as part of a research project.  The
original article and a Java implementation can be found on the following
website.

http://www.aviz.fr/Research/Geneaquilts

Serge has already contacted the authors and they are happy for us to
write our own implementation.  Their source code is not available at the
moment, and they have suggested that we start from scratch using their
article and program as a specification.

I suggested writing a view, loosely basing the design on that of the
Timeline Pedigree view.

What do you think?

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Nick Hall-6
On 21/08/12 19:15, Benny Malengier wrote:
> I would suggest a general gen function: order_in_generations.
> Input would be a list of people. Algorithm could be:
>
> 1. i=1, put all people in generation i
> 2. go over all people in generation i, if no parents, put a copy in
> todo list
> 3. go over all people in generation i, if one of their parents is in
> generation i, move person to generation i+1
> 4. i = i+1 go to point 3.

I had a look at this yesterday, but it doesn't quite work.

At the end of step 2, we have identified all top level (end of line)
parents.  They are assigned generation 1, which is not their final
generation number.

Steps 3 and 4 descend the tree, and identify any level gaps caused be
inter marriage.

The problem is that we are left with branches that need moving down the
tree.  Taking the Greek Gods example, we should only have 1 person in
generation 1 (Choas), although there are quite a few gods without parents.

I can get a list of people by tree walking.  For a simple tree, with no
generation breaks due to inter-marriages, I can assign generation
numbers easily during the tree walk.

I thought that I may be able to customise this approach to cope with the
more complex case, but it is proving difficult.  Any help would be
appreciated.

Looking at the GeneaQuilts program, they assign layers.  Each layer is
either a generation or a family.  The top level in the tree is zero.  
People are on even numbered layers and families are on odd numbered
layers.  I don't know if this gives us any clue to their algorithm though.

For now, I will probably start writing the code to generate the graphics
using simple test data only.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Nick Hall-6
In reply to this post by Nick Hall-6
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.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Benny Malengier


2012/8/23 Nick Hall <[hidden email]>
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.



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

DS Blank
On Thu, Aug 23, 2012 at 11:02 AM, Benny Malengier
<[hidden email]> wrote:

>
>
> 2012/8/23 Nick Hall <[hidden email]>
>>
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Benny Malengier
In reply to this post by Benny Malengier


2012/8/23 W. Trevor King <[hidden email]>
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Nick Hall-6
In reply to this post by Benny Malengier
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.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Nick Hall-6
In reply to this post by DS Blank
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.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Nick Hall-6
In reply to this post by Nick Hall-6
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Quilt view

Benny Malengier
In reply to this post by Nick Hall-6


2012/8/23 Nick Hall <[hidden email]>
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
123