Standardized place gets mutilated when adding to PID, case 2
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.
Comentarios
-
I noticed something similar while working on some Chicago, Cook, Illinois records/families this week. The source linker offers the Cook Islands placename first with Chicago, Cook, Illinois way down the list.
0 -
There have been only 2 reported problems with Standardize this week, but there were 17 last week. The Source Linker is not finding the correct indexed value, even though the correct place is in the places database. Please be patient as this is remedied.
0 -
I encountered this problem just now: the event on the left-hand side had the place as "Hajdúböszörmény, Hajdú, Hungary", which is an exact and verbatim match to an entry in the places database — but when I clicked it across to the right, it now said "Hungary" for the event place. (I suppose I ought to be happy that it didn't find someplace in Texas instead.)
(Yes, I submitted feedback via the tab on the SL page.)
1 -
Thank you for the feedback. I will post to the known issues when I hear something from the engineers.
0 -
I've been finding this for German place names as well. There is a lot of variation in names for the same place depending on the time period. I make sure I have the words I want, standardized, then something else shows up on the Person Page.
0 -
I just had Vienna, Austria turn into Wies, Melk, Lower Austria.
https://www.familysearch.org/search/linker?ark=/ark:/61903/1:1:6KC6-7WMZ&id=GTYN-9GV
There's something Truly Screwy going on with Vienna in all of FS's sections. The Catalog's new-and-disimproved search algorithm cannot find it to save its life, and the autostandardmangler loves to turn it into that Wies, Melk place (which is a name attached to a group of something like two rural buildings, fifty miles west of the city). Half of the Viennese indexes I've been working with today have had Wies in the placename field. Luckily, the hinting algorithms appear to be able to work around the error, and Source Linker is so parsimonious with its event transfers (it only does half: either a date or a place, almost never both) that the incorrect location seldom came up — until this one. I was even admiring that hey, this index entry got the place right, I won't need to corre… Um, yes, I will.
Oh, maybe I can explain this one: looking at the index detail page (https://www.familysearch.org/ark:/61903/1:1:6KC6-7WMZ), there's evidence of editing (the little v after the event date and event place). It would appear that Source Linker and the index editor (or its resident gremlins) are failing to communicate.
1
