Standardized place gets mutilated when adding to PID, case 1
- I've left this source unattached so the engineer can take a look at it. For Jacob D Ballard (LYQK-X5D), if I "Add" the Marriage license location of "Amherst, Virginia, United States" which should precisely match a Standardized Place Name, not only does it NOT match it, but it instead automagically selects a DIFFERENT standardized place name—"Amherst, Papineau, Quebec, Canada." For the not-so-attentive source-attaching patron, they are going to end up with a bunch of bad place names associated with persons in the tree that they have worked on.
의견
-
In some marriage records, the "Marriage Licence" placename in the source document is already a standardized placename. But when you "Add" it to the PID, it loses the standardized placename characteristics, as well as part of the placename. Example "Albemarle, Virginia, United States", when added becomes "Albemarle" so you have to then type in the remainder of the name that is already showing. I have left the following merge uncompleted so the engineer can observe this behavior:
0 -
When attaching a 1940 census entry, the Residence placename gets completely changed to something unrelated, even though it started out as a standard placename. In this example the placename starts as "Bristol, Virginia, United States" but when added becomes "Charlottesville, Virginia, United States." This can be seen in this attachment, which I have left uncompleted:
0 -
This is a problem with the automatic place name chooser. It has always been the case that the chooser works in exactly the wrong way. By that I mean that it takes the leftmost part of the place and tries to find a match in alphabetical order. This is totally wrong. It should begin with the rightmost part: i.e. working from the geographically greatest place and gradually progressing to resolve the place in more detail. If the place associated with the record set is already predetermined (such as Tennessee Marriages) then any unpopluated part of the place name should be set as such, so that all places within Tennessee would be given a higher significance. External places should only be offered when there is no match within Tennessee.
1 -
All apparently based on that same flawed algorithm that changes places in indexed records. A stillborn child in New Jersey would not be buried in Spain, except on FamilySearch where the town in New Jersey has the same name as the town in Spain.
1 -
While the first case seems to be a case of matching on the leftmost part of the name rather than the rightmost, the next two cases I documented don't seem to match that logic, so there is something more going on here than just one simple bug.
0 -
Today I noticed that the automatic place name chooser is behaving better than previously. A place name that includes the word 'street' in the left part, and prior to the town name, is no longer being forced to be the place in the same county beginning with Street. Instead, and correctly, it is now selecting the town. This is a positive indication of good progress. *EDIT: Hold that! Another post to follow.
0 -
… follow up.
I tried to attach the 1841 E & W census record https://www.familysearch.org/ark:/61903/1:1:MQPF-QYK
to Sarah Ann Garside PID KJVQ-X49
I have put a picture of the sequence in the memories of her person record.
It shows that the place name chooser selected a generic region as a match when there were at least 3 exact matches already available in the list of places.
This is not helpful.
0
