Family tree option to see every person

[Progrsam]

It would be nice if there is an option that shows every person that is related to the home person in the tree view. So if there is any connection possible, that person is shown. This would be a nice feature, because it is currently not possible to see every person in the family tree using the ancestor or descendant tree.

[geostag]

This can be pretty useful when you try to get some sort overview. However, this adds significant more complexity, which should be taken into account:

• to prevent getting very very large charts of projects with a large number of persons, you might need to restrict the number of persons shown. Other than in ancestor or descendant trees, restricting the number of generations obviously does not help here. The restriction has to be something like "distance from the root person", which might be ambiguous in situations with circular relationships
• relation ship connections will cross. To minimize number of crossings, sophisticated layout is needed. Sounds like a problem for graphviz / d3-graphviz :-)

[andre1wall]

Who can I turn to or who can I commission to do this and of course pay for it to be realized?

[DavidMStraub]

By the way, while there is no graph view with this feature, you can simply generate a relationship graph report. I just tried this for my own tree showing all people in the tree, zoomed out:

So, makes more sense with a filter 🙂

[Progrsam]

Definitely. The family tree export option is actually what I wanted. I didn't know that this feature existed. Maybe you can integrate that in the graph view as well?

[dnenad]

Any update on this one? How much would it take to change so you can see every person in family tree?

[DavidMStraub]

If no one is assigned to the issue, you can assume that it's not actively being worked on. Just one week ago, we had a new release with a new hourglass chart. Beyond that, it's significantly more work.

[geostag]

I propose to break this issue up into 4 parts:

• check if d3-graphviz is capable to handle directed graph visualization for grampsweb
• discuss the structure of the visualization: just link persons with parent-child-links or display couples, which is more likely used in similar manual visualizations
• implement backend service to retrieve data in apprioriate manner
• implement the visualization itself

[geostag]

step 1 is done. d3-graphviz would work, however, the underlying hpcc-wasm is sufficient and complexity is reduced by using it directly.

Thus, we should decide the structure of the data visualized. There are two main options:

1. Each person is shown exactly once and is connected to its parents with one connector per parent
2. Couples (a couple are two persons which are married and/or have at least one common child) are created and connected with their children by one connector per child.

Option 1 is straight forward and very generic, but leads to a factor of 2 connectors compared to option 2.

Option 1:

Option 2:

A larger example of Option 2:
digraph-2305.pdf

Any Opinions?

[DavidMStraub]

Great! I don't have a strong opinion about option 1 vs 2. Perhaps option 2 is a bit cleaner, but either would be fine I think.

Regarding step 3: I guess the backend should already have the required functionality using person filters, and then adding a preprocessing step in Javascript, similarly to how we use IsLessThanNthGenerationAncestorOf and IsLessThanNthGenerationDescendantOf filters for the tree charts, followed by the getTree JS function. I can look into it. What would be our criterion to select a subset of people? Some kind of relationship distance?

[DavidMStraub]

Oh I get it, we need a graphviz file, right?

[ItsSiem]

As a very happy user of grampsweb and also of the H-chart plugin in gramps desktop (which also displays a more complete view of the family tree) I thought I'd share my opinion on the matter.
I would definitely prefer option two over option one, in my opinion it is clearer whats going on when you have multiple families with the same individual. And with regard to the person limit, I don't really have strong opinions about that.

Love the project and I'm very curious how this view will turn out.

[geostag]

Oh I get it, we need a graphviz file, right?

Yep. The flow would be:
Filter persons -> create couple-nodes (see above, Option 2) -> create graphviz (dot) string -> render

The last step needs to be done in the frontend (javascript), for the others we are free. If we do the first three steps in the backend, every change in the filter would trigger a backend roundtrip. However, dealing significant with data (creating nodes) in the frontend, might be bad architecture. Not sure, what would be best.

[geostag]

After looking into the existing code of the tree charts, I propose to do all steps (filter persons using the existing backend service, create coupld nodes, create dot string and finally render it) in the frontend. I meanwhile got what you ment @DavidMStraub .

Option 2 seems to be agreed on.

For the filter, the distance to the root person shoud be ok:

• distance 0: root person
• distance 1: distance 0 + children of root person + parents of root person
• distance 2: distance 1 + children of all persons of distance 1 + parents of all persons of distance 1
• ...

additionally, uniqueness of persons has to be checked, in cases where you have circular relationships. @DavidMStraub if you could have a look at this as suggested, this would be great. I can do the code for creating the nodes, dot string and render it.

Concerning #347 : I have no opinion on that, offering two ways to users seems not to be a problem.

[DavidMStraub]

Sounds good!

I looked into the filter and, to my surprise, found that this is not possible in Gramps core, but there is an addon doing just that written by @Mattkmmr 🎉

I will install the addon into the API default docker image as we already do for the PostgreSQL addon.

[DavidMStraub]

@geostag in this branch https://github.com/gramps-project/gramps-web/tree/relationship_graph I added a placeholder GrampsjsViewRelationshipChart.js which pulls the data using the DegreesOfSeparation filter (it abuses nAnc for the degree of separation for now).

[geostag]

thank you, I will do the further work on this branch.

[geostag]

Just want to give an update on this. After struggling with a bunch of different issues, I'd like to show the current state of this enhancement:
relationship-graph.pdf

• I had to make hpcc-wasm to render the dot into a hidden div and steal the svg-content from there to be able to apply the same zoom/pan d3-mechanics like in the other graphs
• styling hast to be improved
• some issue with single-person parent nodes
• fonts: graphviz would be able to use the gramps-web "Inter var" font, but then fails to calculate the dimensions of the boxes. This might be fixed, when fonts are installed locally and made available to pango, which ist used to render the fonts. Is there a plan to install the fonts local to the webserver?

[DavidMStraub]

Nice!

Concerning the font issue: if we grab the SVG from the container and then pass it to d3, why can't we style everything with CSS using d3 in this final step, independently of which font graphviz used? (I never tried this, so might be a silly question.)

[geostag]

Just wanted to know if there are any thoughts on serving the fonts directly. And yes, indeed, the way outlined on doing the font-sizing in d3 is the alternative. I will go for that.

[geostag]

#401 Comments welcome, still some data interpretation issues

[ItsSiem]

Looks great! Perhaps some options for the style of the lines would be nice (orthogonal, smoothed, straight). It could also be interesting to show marriage status and date for each set of parents. These are all small things, because this looks really great already.

[geostag]

edge style is generated directly by the underlying graphviz. While graphviz has more options (splines, ortho), they look even worse in this context. I would prefer to start with the actual setup using "polyline". Will try to add marriage status and date without using too much space - the graph already tends to be generally very wide.

[geostag]

• marriage status implemented (small circle in the middle of couple)

still open and might be done in future:

• marriage date
• prettier edges by replacing the graphviz polylines by d3 rendered edges

[geostag]

closed with #401