siblings in between spouses

[nopoz]

First off thank you for this great module! It's very useful to be able to display the tree in a very broad view.

My problem is I'm finding that siblings often get in between spouses and it makes for a more jumbled view that is less easy to follow visually. Is there any way to prevent this? If not, could I make a feature request to sort the display more logically where spouses are beside each other in the graph? See attached image below for a simple example - it can obviously get much more twisted up when there are many siblings and spouses in a particular generation.

[nopoz]

As a visual example of what I'm talking about - here is the visual style of the 23andMe family tree chart - where they use a sort of "coat hanger" styling to maintain spousal grouping.

[Neriderc]

Thanks for stopping by and taking the time to write up a post!

Variations of this have been discussed in the past, and it's unfortunately not something we've worked out a good solution for.

There's a sort of combination of Graphviz (the engine used to display the tree) and the order that we feed in people. We feed in people by starting from a root person and growing from there. It's a little hard to describe, but basically the parents are added first, then the children, then spouses. It's recursive, so first the father is added, then we don't continue with the root person until the father is done, so the father's father is added, then the father's father, etc.

We have tried playing with the order, but if you change the order then other things come out wrong. I'm afraid I'm all out of ideas on how to fix this. Happy to take suggestions!

As a note, you can reorder siblings in a family within webtrees. Doing so should also reorder them in GVExport. You might be able to reorder the siblings to get them to sit next to their partner - but no promises. And when you change something in the diagram, you might have to change the order again.

Another option is you could download the DOT file, and use other Graphviz software to edit the order of the nodes - the nodes are one per line, so you would just shuffle whole lines around. Not an ideal solution but you might be able to make it work.

[Neriderc]

@hartenthaler @schuco I've had a thought that may help with this very specific scenario of an isolated spouse (no further links) not being next to their partner. I know you guys have some strong opinions on reordering the diagram so I'd like to hear your thoughts on this.

We could identify spouses that have no other links except to their spouse, then for these spouses, slot them in straight after the attached spouse in the DOT file. In theory this should also put them next to each other in the diagram, and since we only move the ones with no other links this should cause minimal disruption to the flow of the diagram.

From a technical perspective this is not as straightforward as it sounds, but I'm moderately confident it's doable. Do you think there are downsides to doing this? Anything I haven't considered?

[schuco]

Certainly I would like to see a solution to get an adequate positioning of spouses. This is especially disturbing when a spouse is placed in between sibs of a complete unrelated group. But I thought this was the inevitable compromise using a powerful general program like graphviz to display family trees. As I understand the strategy of graphviz is to minimise crossings of lines and to get as small as possible diagrams. Another unfavourable consequence is that the family groups may be completely reordered or move to the opposite side of the graphic when you just add one starting individual. I can't assess if your approach may help to overcome the improper spouse positioning. Isn't there an option in graphviz that the minimization of crossings and size is restricted in favour of strict retaining the grouping of the input? (Excuse my English)

[hartenthaler]

We could identify spouses that have no other links except to their spouse, then for these spouses, slot them in straight after the attached spouse in the DOT file.

We are talking only about this using the simple mode?! You can try this. I'm not sure about possible side effects. Maybe it helps to optimize the presentation in the diagram.

I'm just thinking about the use of the persons/families in the clippings cart. When adding them to GVExport this is done using the sequence in the clippings cart. When I remember right the used sequence is based on the XREF. I will check what happens in the diagram presentation if the same group of persons/families was added by the standard selection in GVExport and via the clippings cart.

Do you plan to implement the reordering of isolated spouses as post-processing? Then you can do this maybe after the generation of the internal lists, ie after the generation of the list from the clippings cart, so that this is optimized, too.

[Neriderc]

@schuco

But I thought this was the inevitable compromise using a powerful general program like graphviz to display family trees. As I understand the strategy of graphviz is to minimise crossings of lines and to get as small as possible diagrams.

To some extent, but we have seen in the past that some reordering does make an impact. I am hoping that reordering the order we give Graphviz the spouse records (for spouses without further links) should be honoured as it should not change the number of crossings. It may not always work, but I'm hoping for improvement.

Another unfavourable consequence is that the family groups may be completely reordered or move to the opposite side of the graphic when you just add one starting individual.

This might be Graphviz trying to reduce crossings, or it might be because the tree is generated in a different way if you add a starting person. Do you find any difference if you add the starting persons in a different order?

Isn't there an option in graphviz that the minimization of crossings and size is restricted in favour of strict retaining the grouping of the input? (Excuse my English)

I've found an option that strictly keeps the left to right order of items within a rank (in our case, this is a generation). The problem with things like this is that it means we are then responsible for getting it right, and that adds a lot more complexity to what we are trying to do. It's a lot better to try to push that to Graphviz to handle.

The problem is that we don't necessarily add to the tree in the order they should be displayed. E.g. with spouses, before we add a spouse we add parents and all their links (including siblings of the starting person). By the time we come to add the spouse there are already others on the same generation.

If we don't add the parents first and instead add the spouse first, we then add a whole spousal family before adding the parents of the starting individual, which can really change the layout of the tree. Siblings of the starting person would be located far away as all the spouse's relations in the same generation would be added first. It's a tricky balance getting the display order right, and in my view the more we can push that to Graphviz the better. However, Graphviz doesn't know that we would prefer spouses right next to each other so it leads to other problems like the one we have here. But I think small changes is the best way forward, trying not to break what already works :slightly_smiling_face:

@hartenthaler

We are talking only about this using the simple mode?! You can try this. I'm not sure about possible side effects. Maybe it helps to optimize the presentation in the diagram.

Yes, simple/decorated mode. Combined mode already groups partners so there isn't much to do there. Now you mention it, @nopoz you may want to look at combined mode to see if you prefer this layout.

Do you plan to implement the reordering of isolated spouses as post-processing? Then you can do this maybe after the generation of the internal lists, ie after the generation of the list from the clippings cart, so that this is optimized, too.

I don't quite have a plan, but just thinking now, during the generation of the diagram we could have a new list that tracks anyone added as a spouse (often a spouse is actually added as a parent or child to the family so would not be added, but in this case they would not have a single link and so we don't want them anyway). When the individual/family/spouse lists are complete, we could loop through the spouse list checking that they are not included in any other family - and delete any that are. In our spouse list we could track both spouses, one with further links and one that has just the single link, then when adding individuals to the diagram we check if they are in this spouse list and if so, add the spouse at the same time (then probably remove them from the lists so we don't add them at the original place as well). As always, I'm happy to hear other ideas!

This seems doable, like it might have the outcome we are looking for, and has minimal changes from how the process currently works. I don't hear any strong objections to doing this re-ordering so I'll have a go at implementing it and then we can give it a try before putting it into a release.

[Neriderc]

Ok so I made the change, managed to get the DOT file generated with the single-link-spouses directly after the main spouse in the DOT file, just how I wanted it to.

Unfortunately, it's didn't actually work. Graphviz still put some spouses way away from their partners. I also found the diagram appeared to have a lot more crossings. It's like the spouses placed out on their own are actually important to the layout of the graph for minimising crossings.

And on that note, through testing this I found the MCLIMIT does seem to make a difference with the number of crossings. But it only seems to matter on large diagrams, and in those cases you seem to need large MCLIMIT values. At least 100 to get any meaningful difference, I've tried with 1,000 which reduced the crossings to almost none, but this takes a long time to run. I've only tested on my development instance webtrees installed on my laptop, which for about 500 individuals was taking about 30 seconds to run. My production server is much less powerful, and I expect this would time out before finishing. Also, it seems to have the biggest impact on the top-to-bottom style. Even setting the MCLIMIT to 10,000 gave me quite a few crossings for left-to-right.

Currently this MCLIMIT option is only available in the config.php file, not in the UI, as discussed in #163 it was removed. I'm considering bringing it back to the UI. Even if not practical to affect the number of crossings in any great way, it's a convenient way to effectively ask Graphviz to try generating the graph slightly differently. Using different MCLIMIT numbers may be a way to reduce the number of times partners are shown far apart from each other by giving the ability to generate different versions of the diagram.

@nopoz if you're still following, sorry it seems this isn't really fixable. It's a function of being based on Graphviz, which puts things in the best place for layout of the graph without knowing that the spouses are important to each other. You may want to try Combined mode, which groups the spouses and family record together.