Tool: Display Relations and Distance with Home Person - Possible Bug?

[david1]

Gramps AIO64-6.0.5–1 Win 11

I have been using the addon Tools>Analysis and Exploration>Display Relations and Distance with Home Person, and ran into a situation where one of my first cousins initially did not appear on the results screen of that tool.

The First Cousin is the biological child of my uncle and a person not his wife. The First Cousin’s parents have her non-birth “father” (i.e., Legal Father) set as her stepfather and her bio mother as her birth mother, as follows:

The Relationship Chart for the entire tree looks like this:

The Grandson in this family is set at the Home Person. Tools>Utilities>Relationship Calculator correctly shows that First Cousin and Grandson are first cousins:

So far, so good. The problem arises when running the Relations and Distance tool, which does not display First Cousin at all:

By way of experimentation, I changed the First Cousin’s Legal Father to a “None” relationship with First Cousin:

That fixed the problem, in that the Relations and Distances tool now correctly lists First Cousin:

Most interestingly, when I then changed the Paternal relationship back to Stepchild, the Relations and Distances tool still correctly displays the First Cousin.

Indeed, using the Adopted relationship for the First Cousin’s Legal Father, the Relations and Distances tool still gives the correct display of First Cousin. It’s almost like the error only occurs following initial data entry, but making any subsequent changes to the relationship corrects the problem from then on.

Is this a reportable bug or am I doing something wrong?

[romjerome]

@david1

The First Cousin is the biological child of my uncle and a person not his wife.

By design, the most recent ancestor will be the wife (it was the safetiest way to get a robust lineage). Might be often a spouse with female gender but could also be a single woman. So, there is a know issue with step descendants linked with the father (or male) as the MRA will not match.

https://gramps-project.org/wiki/index.php?title=Addon:Display_relations_and_distances_with_the_home_person#To_check

About the change state, which will keep the previous value. This could be related to a cache and a pseudo-signal used for performances issues. Cache might be purged, but sometimes to keep some data from the first pass will improve performances. I suppose in this case this remains in cache.

Note, as this tool is just an other interface to relationships handler, you could also get a traceback related to the relationships module, like

Possible issues on Relationship module

As far as I was able to track this down there could be an issue with 1st cousins, or children of 1st cousins. The above patch has been applied on my local version of gramps and a run with ‘Check and Repair’ fixed something on my testcase database. So, it is still unclear why sometimes a new Family Tree (or data set) could generate an out of range index error around ChildRel. Custom child<->parent relation? A translated relation type?

Feel free to improve the number of generations for testing with large data set or use this tool as a debug one:

$ gramps -d "relation_tab"

[romjerome]

@david1

Indeed, using the Adopted relationship for the First Cousin’s Legal Father, the Relations and Distances tool still gives the correct display of First Cousin. It’s almost like the error only occurs following initial data entry, but making any subsequent changes to the relationship corrects the problem from then on.

Is this a reportable bug or am I doing something wrong?

Let me try to translate, you are asking why the stepchild relation is missing while it has not been set into gramps? Once set, it will match.

Why the ‘None’ is not really a ‘None’ (or a second None), this could be a bug. And why ‘stepchild’ sounds like covered by an alternate step relation type is something that I cannot explain or figure now.

Maybe you make it right (and the tool too)! As written above, I added a cache and some signals might not always return “real time” data state ! Any change on tool options (e.g., the variable for the maximum of deep generations), will be initialized on any new run.

The fact that cache, threading and signals are in a pseudo-static state during a gramps session, could maybe explain the strange behavior. But this is out of my knowledges and I do not know yet how could be fixed into the addon.

As the author of the addon, I must say that I also do not know yet how adopted or step relationship for the First Cousin’s Legal Father could now match without any woman… There is a piece of code for always setting a woman as the most recent ancestor. I suppose that it will match with the mother of First Cousin’s Legal Father? Maybe I could remove this from my TODO list for checking this type of relation because it seems too complex (None handling sounds too cryptic for me).

About the addon itself?
Is it useful? Was there a lack on common core features (gramps program)? Should be a view? This could be easily extended (e.g., density of family network, family islands, persons comparison via their relationships maps, DNA stuff, integration with NLP to analyze, etc.)

Pair numbers are for women (and MRA), impair numbers are for men and root (default person = 1): the sosa/kékulé ancestors numbering.
The primary idea was to find a numbering for descendants, sibling and cousins too, but using float between 0 and 1, or negative numbers, cannot be used into this type of tab (via Gtk TreeView). The Relationship ID is used as a key for displaying the tab (model & co). “Textual numbers” will work on CLI (or without Gtk) but I did not fully split GUI and CLI. So this addon has been forced to always use a “valid” and “basic” number, which will avoid the mistake with Graphical User Interface and tab (TreeView). Maybe a new refactoring might go further by returning UID for descendants, sibling and cousins.

https://raw.githubusercontent.com/gramps-project/addons-source/refs/heads/maintenance/gramps60/RelID/NEW_README.md

Otherwise, the filter rules handler is not active yet. The environment is set (methods), but filter rule is currently hardcoded. So, dynamic user choice via a filter selector and more accessible tool options, could be an other improvement.

[romjerome]

I do not know if this could be related?

For gramps.gen.relationship.RelationshipCalculator:

• Fixed incorrect handling of return value of get_birth_parents() method in base RelationshipCalculator
• Adds tests to base RelationshipCalculator module to improve coverage of step, in-law and plural cases (some of existing rel_xx.py now fail on new tests)

Re-written relationship calculator for Russian language

@david1 I thought that the strange behavior might be related to a fresh import of data and metadata init around type handling (Child relation type set as None), but this could also be fixed into gramps 6.0.6 ? Not tested yet.

Release v6.0.6 · gramps-project/gramps

[petr_fedorov]

@romjerome

Fixed incorrect handling of return value of get_birth_parents() method in base RelationshipCalculator

means this:

so only RelationshipCalculator.get_sibling_relationship_string() is affected

[romjerome]

@petr_fedorov

so only RelationshipCalculator.get_sibling_relationship_string() is affected

And mayble indirectly, cousins uncles and aunts as sibling of parents? Sure, ‘step children’ is something else, but as it matches (sometimes), I was only wondering if a great-mother (on the step father side) cannot re-enable one calculation or something else does the match around the relationships map.

An other issue has been fixed on 6.0.6. Maybe a specific or corner case: to look if childrel exists before calling lists?

childrel[0][1],
IndexError: list index out of range

Does it mean that None relation type != return None list value? That’s why I thought something that might be improved or fixed on 6.0.6, but I was not able to confirm the relation to this issue.

Note, there is also an other variable, linked with filter rule “Related”. If the tab does not display the line, either there is no relation by birth with a top woman as most recent ancestor, or the filter rule missed the step relation. In any cases, it should not be inconsistent. I still think on a possible default ‘None’ value for a child relation type (either after an import or on edition). Great to know that the tool can find the “step cousin” after a modification via the parent-child editor. Do you have an idea (or a fix) for the addon? Or is there something specific to do on a core module of gramps (editor, importer, database state, signals, etc.)?

An improvement might be to go further and to check relations not only by birth (only_birth=false). This should be a real tool option as this might generate performances issues (I suppose), with large dataset.

[romjerome]

@romjerome

An improvement might be to go further and to check relations not only by birth (only_birth=false).

The idea was to use the smallest data set for the calculation, but this should not increase too much the calculation time and might help to find step-relations without multi-pass[es] (or cache call):

line 513

# 2. Calcul de la distance de relation (une seule fois)
dist = self.relationship.get_relationship_distance_new(
-    self.dbstate.db, default_person, person, only_birth=True)
+    self.dbstate.db, default_person, person, only_birth=False)

and if you want to check all your individuals without filtering, on line 399

# Application du filtre initial
-self.filtered_list = self.filter_manager.apply_filter(plist)
+self.filtered_list = plist

this can take few minutes for more than 120 000 individuals according to your hardware and ressources (and few seconds with the filter rule).