In the example below, I have just edited a place in Ancestry to separate the place details from the place proper, and then copied this change back to RM. Both databases have identical data for the marriage - the same spouse, the same date, the same place, the same place details and the same sources, and yet the two values are shown in red as significantly different
Although RM copies the data from one side to the other correctly, when comparing the data it adds the place details before the place proper on the RM side and after on the Ancestry side and wrongly concludes that the two are different.
Contact Ancestry, it looks to be their problem. Their side appears to be the one with the scrambled data. In RM, the place details always appear before the place name and they have for as long as I can remember. You can see this any time you work in an Edit Person window and fill in Place Details.
It has been stated numerous times that the RM data model and the Ancestry data model do NOT line up perfectly. I really doubt it is ever going to be brought fully in line so we can make ourselves nuts over it or we can find a way to work around it. So a bug? Probably not! It is doing precisely what it was designed to do.
…and like I said, Rootsmagic is displaying it as it has displayed it for as long as I can remember. Ancestry has decided to rearrange the parts. RM is very literal and makes no assumptions in regards to comparing (nor should it). RM knows that it has two (or sometimes more) strings, A and B. It gets data from Ancestry, which Ancestry calls A and B. Rootsmagic, like every other program that I know of, tries to match A to A and B to B. In your example that means ‘St. Paul, Westminster Bridge Road’ is being compared to ‘Westminster, London, England’. As anyone with glasses can see, those are not equal.
You are asking for RM to compare A to A, and if that is not equal, then compare A to B and if that is equal, then repeat by comparing B to B etc. and from that, conclude that even though A doesn’t equal A, they must be the same. That is just freakin’ insanity.
That was a simply example with two variables. Expand it out a little. In a standard place name, you might have a city, a county, a state, a country, and a specific place/address. 5 variables. Now, making an assumption that Ancestry would also use those exact same 5 variables you would be running 25 matches instead of the three matches above. If Ancestry used a different number of variables, the compares can increase considerable. Not a smart design or even one that a reasonable person should expect.
Not a bug if it works as designed. Just because it doesn’t act like you or I might want, again, not a bug.
I’m not sure I understand how you separate ‘place details’ from ‘place proper’ in Ancestry. Maybe it is because I haven’t used Ancestry recently. Iirc, Ancestry has just the one field for place while RM has both ‘place’ and ‘place detail’. Hence, a string downloaded from an Ancestry ‘place’ goes into the RM ‘place’ regardless of its level of detail. It could be just a country or everything down to a plot number in a cemetery. Under those conditions, the RM ‘place’ has everything identical to the Ancestry ‘place’. However, if in RM, the string is split between the two fields, then there is no match with Ancestry.
At the very least, we have two fields in RM and at least 1 field in Ancestry. If this is the case, then one is still going to need to break the RM strings into pieces and search all of those substrings in the result from Ancestry.
The problem here is that we have absolutely no idea how Ancestry stores and transmits their data and how it is transmitted is going to have to be dealt with in RM. If Ancestry transmits a single string, then see above. If they transmit in two pieces then RM is going to have to do a compare between each of the pieces and determine if they all match, regardless of the order. If Ancestry transmits in multiple pieces, then RM has to figure out how to assemble the pieces and then run the comparisons (and god forbid should it assemble them incorrectly).
My best guess from the research is that RM concatenates place details + place and compares that directly with the resultant string in Ancestry. In the Ops example, it is no surprise that they are shown as different.
To be fair, Alan has previously indicated that he may know something about the Ancestry API that is generally not knowable outside of FTM and RM dev teams (oh yeah, and Ancestry). So he may very well know a lot about things that you and I don’t when it comes to that API.
I have NOT looked at the RM DB tables in a while, but I am assuming that RM stores places and place details as two individual strings and for display and comparison, it concatenates. We can guess that Ancestry stores the place in a single string, but we can’t know it.
Very strange. I originally produced the image posted above by amending a marriage in Ancestry, taking the place details out of the place field and putting them in the description field. I then used Treeshare to copy that change back to RM and, immediately after copying the data, Treeshare showed the two databases as being out of line as shown in the image; RM had mapped the Ancestry fields in one way to process the amendment and in a different way when comparing the results.
However, try as I can, I can’t replicate this. I can’t replicate it deleting and re-adding the marriage or amending and amending back or working in either direction - RM to Ancestry or Ancestry to RM. I can’t replicate it by amending either the place or description fields in Ancestry or any of the three corresponding fields in RM.
I can only think that I have changed something about how Treeshare functions by amending the fact type definition for the marriage fact in RM in the mean time, but I have tried changing that back and I still can’t replicate it. On reflection, I have amended marriage descriptions in Ancestry many times and have never before seen a discrepancy with RM after processing these changes in Treeshare; it must have been some kind of one-off glitch, but I don’t understand how it happened.
