I have set RootsMagic to show the relationships from the Root person (me).
To facilitate the work I’m doing, I also color coded all of my ancestors.
I would expect that a direct ancestor, like an 30th great grandfather, would be shown as the most important relationship (as does the relationship calculator which puts it first), as shown in the image, this is not what I get on the Person’s edit screen
@Willem Unfortunately no—I guess you can say it is working as designed for RM – you only run across this problem when both spouses are related to you.
Here are 2 previous threads that expand on your question
Dear Nancy, thanks for the links to the threads
In the case I showed it mentions the spouse, but it also happens with 2 cousin so many times removed, or even X gguncles.
As you say, it is likely because more than one of the family members is related to me (e.g. several of the children are direct ancestors).
Perhaps in a next version this could be addressed? Would it be corrected if the show relationship to spouses can be turned of?
Based on the database table (Person) there is a flag field – (One value) – I am guessing it assumes the shortest path is more correct but that may or may not be the desired one – a person can have 5 or more paths especially on larger db,
Kevin
@Willem Yes it is going to happen on any couple that has a dual relationship to you the farther back in time you go-- my hubby and his mother are also 3rd cousins ( hubby’s g-grandparents were cousins who married) BUT that always shows the mother/son relationship for them..
That said, you can still have relationships off even in more recent times-- for example-- my Dad and his brother married sisters-- so when I check the relationship between my nieces and nephews to my Mom’s sister–it says that she is the spouse of the great uncle instead of great aunt.
RM actually just added this expanded " spouse of" in RM10–as for being addressed–that is totally up to development and only @rzamor1 can answer that question BUT yes I would think an option to turn off relationship to spouses would solve the problem.
Dear Kevin,
Thanks, you are probably correct. As you imply, it may be difficult to code, as in some cases the shortest path may not be the “most direct ancestral relationship (with which I mean of the ggfather or ggmother type)”, although I wonder if a rule-based table could be used before displaying the result, perhaps based on the results from the relationship query which shows a list of all different relationship paths.
Anyway, for now the color coding provides an indication of such direct ancestry (I think).
Thanks. And then they say only living relatives are problematic…
Think I have more problems with the dead–they are NOT born when and where they are suppose to be, they are not listed as living where they are suppose to be and they are NOT buried where they are suppose to be…
And definitely have problems with their ages especially 2nd g-grandma and her son-- they bounced around on their age in census and dc so much that the last listings I have for them both shows them at least 10 years younger than actually were…
I don’t see us turning off a feature users asked for and we just added. This is only an issue when spouses are related multiple ways. The first relationship calculated is displayed in set relationships.
Thanks, I am not asking to turn it off, but perhaps it could be toggled by the user?
I know the problem. We did the genealogy of my wife, who is from a small town in Italy. I wrote a little “article” about it for the book we published for the family:
“Configurable” I can understand the ask.
I also wish the text of the relationship was accessible. (Calculated off the Person Table values (Relate1, Relate2 & Flags etc)
That said you could use CTE and recursive query to determine some of that. (That would be outside of RM), Though you could potentially, have a custom fact that gets update by a query. That would NOT be a simple query.
Not sure who asked for it, but it changed the way it used to work for the last several versions of RM including the initial v10. Many of us were used to the way it used to work and several of us think the old way is more correct, or at least preferred.
Thanks for the interesting thread. Personally, I have not come across the need for this “Spouse of” relationship, but at times you just don’t know what you need.
Not sure what you ( kbens0n) intended with that reply, but this person in that thread sums it up nice for me:
There is another effect caused by the new “spouse of” relationship:
If relatives marry under each other, formerly, the kind of how the spouse was related was mentioned in RM9. Now in RM10 this information about the kind of how they are related is overwritten by the “spouse of” information.
I prefer the information of how the spouse is related compared to the more or less obvious information of their marriage.
I am much more interested in the blood relationship than the “spouse of” relationship. This is how it worked in the initial version 10, and how it worked in version 9, and how it worked in version 8.
I agree, but as I said elsewhere, I have not come across a reason to desire to know the spousal relationship. Hence my request it could be turned on or off.
Willem, I agree. Obviously, the coding has been completed for both ways. Now we just need a switch to use the old programming versus the new programming, so people can choose whichever way suits them.
That is not a good design. I’m not in favor of turning off the “spouse of” feature. Rather, I’m in favor of changing the design so that actual relationships always take precedence over “spouse of” relationships. And if the design cannot be changed in that way, then I actually would be in favor of turning off the new feature. Overall, it makes things worse rather than better. The fact that it’s a new feature and that users requested it doesn’t matter if the design of the feature is not good and if the feature does not meet user’s needs.
Conceptually, the fix is quite easy. The code is obviously making one pass at the data. The same pass is setting actual relationships and setting “spouse of” relationships. So the fix is to make two passes at the data. The first pass would set actual relationships. The second pass would set the “spouse of” relationships, and only for the spouses that weren’t already actual relationships.
As to how I know this, I have an SQLite script that color codes based on relationships. It does more complicated color coding than can be done from within the RM user interface. Version 1 of my script did its color coding based on what it found in RM’s data from Set Relationships. But I had to rewrite my SQLite script for RM10 because I wanted actual relationships color coded one way and “spouse of” relationships color coded a different way. So Version 2 of my script no longer relies on RM’s data from Set Relationships. And Version 2 of my script makes two passes at the data. The first pass is to color code actual relationships. The second pass color codes based on “spouse of” relationships. And the second pass does not change any color codes that were set by the first pass. That’s the same logic that RM’s Set Relationships tool needs to use.
All that being said, even with a two pass design, it’s not clear that the “best” or “closest” actual relationship would be chosen. In fact, it’s not clear that there even exists a “best” or “closest” actual relationship.
My SQLite script is actually a three pass solution.
I have in the back of my mind to adapt my existing script not only to color code but also to do the Set Relationship logic correctly so that “spouse of” relationships do not take precedence over actual relationships. But that would solve the problem in RM10 only for me. I think it needs to be solved for all RM10 users.
I was pointing out discussion WHERE… (what you were told by @Nkess):
…an upgrade/change had previously been requested by users and fulfilled, but had consequences. That is all.
