Dude what happened to the once mighty search engine?
what good is it if it thinks hermann, gasconade is hermann, transvaal?
suddenly a bunch of places are changed to another place with the same name!
isnt this basically a lie?
are those computer-transcribed obits run thru some weird forced auto name resolve process? idk
Answers
-
its not just in the obits
0 -
This isn't really a problem with the search engine itself. There are two versions of the actual problem.
A couple of years ago an automatic routine was developed that scanned through the indexed records and converted all the event place names to a standard version. Unfortunately there was a flaw in this routine so that a small percentage of the time the routine badly corrupted the place name. The could be particularly severe when the original place name was a single word. You can see the error made by comparing the original event place to the "corrected" event place:
Here the original place of Stord, Valestrand, Hordaland, Norway was converted into Valestrand Cemetery, Stord, Hordaland, Norway. Not a great place for a wedding.
There is a team that is slowly going through the indexed records and fixing these errors. But this is being a long process. I first reported this particular example over three years ago and it has not been corrected yet. I'm sure it's taking a lot of time because when there are 20.5 billion records, even a small percentage is a lot of records to find and correct.
The second type of error is an on-the-fly auto-standardization problem in which the indexed place name is not changed in the record but the name is displayed incorrectly in the search results. For example, in some Norwegian records, the last part of place name is abbreviated S.B. for Søndre Bergenhus. The index does have, for example, Fitjar, SB, and only shows that way but looking in a search results list it used to display as Fitar, Solomon Island. This particular problem has been fixed for this location. I don't know if it has been fixed overall.
The engineers are well aware of this problem and, as I said, we've been told they are working on fixing things.
4 -
@tgdavis007 With some exceptions, when you search for the record using the correct (as indexed) place name in the search criteria, the record will be retrieved:
https://www.familysearch.org/en/search/record/results?count=100&q.deathLikePlace=Hermann%2C%20Gasconade%2C%20Missouri%2C%20United%20States&q.deathLikePlace.exact=on&c.collectionId=on&f.collectionId=2026973
If you consider that the purpose of an index is to be a finding aid to the original record, then the process works as designed. However, of course the changed place names in search results and often other places, is indeed a flaw and needs to be corrected. Contrary to the rumors of a careless auto-standardization routine, these errors occurred during the migration of record collections to a new storage system that enabled millions more digitized records to be brought online. Restoring the accuracy of the data is a high priority but also a complex task. Although many collections have been laboriously repaired, there is not an engineering team slowly going through the records and fixing errors. Rather, they are working on a universal fix or "treatment" which I can only say (as a non-engineer) is a massive, ongoing effort.
1 -
@SerraNola Very interesting to hear you say "Contrary to the rumors of … auto-standardization routine" since that is what we users have been told by representatives of FamilySearch. We users didn't start that rumor.
2 -
The operative word in my sentence was "careless". Of course there were standardization errors in the process of migrating the records and that was the easiest way to explain what happened, but it doesn't tell the whole story.
0 -
I'm sorry to persist, but I don't think I've ever said careless or seen my fellow contributors use that word when referring to the place issue. Problematic or troublesome algorithm, yes. Careless, no.
In fact, that's why I used an ellipsis because I did not wish to use that word in reference to the routine.
As I've mentioned before, we users rarely are informed of what/why/who. Thank you for your comments.
2 -
Thanks for letting us know more of the full story. I'll modify my answers to people who keep noticing this. It's also great to hear that they are working on a general fix and not having to repair collections one at a time. That's really what it was sounding like they were doing from previous moderator reports. Finding the root problem and fixing that sounds much more efficient.
And there is progress. As I mentioned, the Norwegian census collections are now leaving alone one word place names and just displaying them as they were indexed rather than trying to turn them into a three or four part place name that was rarely correct. Also, it was a great step forward to have the Event Place (Original) back again to be able to see if the post-processing was correct or not.
Unfortunately, the Source Linker still provides the post-processing place name and I've had to correct far too many records where the user attaching the hint just takes what the Source Linker provides at face value and leaves a goofy place name on the profile rather than checking the record and determining what the place name really was. But that chronic problem, not checking original records and never looking beyond the index, places all sorts of incorrect information on profiles. I wish there was a big notice on every index record stating "This is a partial transcription of an original document. It may have errors. Please check the original document to confirm accuracy and for additional information for this event."
2 -
@Áine Ní Donnghaile I will take ownership of my comment which was not meant to be accusatory. When I first recognized the scope of the place name errors I thought, "How can they be so careless as to continue to apply a flawed program—why not stop at the first hint of a problem?" It was hard to fathom. I would guess I was not alone in that thought process.
@Gordon Collett Thank you for further information on Norway records. Every collection with these errors plays out differently. In the example from the original poster in this thread, search results show the usual conversion of the town into a different place, the index details page shows just the cemetery name, and source linker has just the one word name of the town.
2 -
i just ran into another one. grant, minnesota and grant, perkins, nebraska arent the same place at all! 🤔 this is getting really bad. most of what im finding, the ‘edit’ button is disabled. wow, doesnt seem like a repair is possible, it keeps getting more ghastly. thanks for the observations
0 -
I have suggested in earlier posts that the current place name standardistion routine seems to work in exactly the wrong way. It seems to work from left to right, i.e. it ignores the most important geographical information.
Compare:
Kingston, Autauga County, Alabama, United States
Kingston, Jamaica
Kingston, Meeker County, Minnesota, United StatesIf I start work from left to right using Kingston as the search criterion, then the first match in alphabetical order is Kingston, Autauga which comes before Kingston, Jamaica, and Kingston, Meeker
However, the most significant information is the Country, and therefore the routine should work from right to left.
If the recordset in use is the Baptism records in Kingston, Jamaica, then the routine should exclude anything that is not in that country.
Simlarly, if the recordset in use is the marriage records in Minnesota, then the routine should exclude anything that is not in that state and country.
There are many examples where the routine has replaced a location with one in another country because it has not followed the correct order: Most Significant to Least Significant.
0
