Immigration Records Erroneously Showing Entry at Quebec, Hardin, United States?
|
|---|
Best Answer
-
My earlier short comment was easy to be misinterpreted. “Safeguarding the original place text and re-standardizing with better reference data” has always been the long term plan to repair the damage. Because that work is still in progress, it isn’t accurate to call it “poor programming” when it hasn’t been implemented yet.
You obviously put some serious thought into how this collection could be fixed, but the challenge goes far beyond this one collection. FamilySearch has over 3,500 collections and I’ve personally documented this same type of place‑standardization error in at least 124 collections. The underlying problem did not start because someone casually wrote bad code for a single project; it arose during the massive migration of over 5 billion records from an old system into a new one. In that process, some place names were standardized incorrectly.
“Re‑standardizing with better reference data” means two things:
- Preserving the original indexed text exactly as it was entered, and
- Using an improved “Standards” database in the new system to match (or construct) a more accurate place (or date, etc.), even when the original text might be just a single vague word or a messy string.
The long‑term “treatment” is to apply that approach across affected records in bulk. Currently there are dozens of linked work items focused on the final objective. I fully understand why this feels urgent and frustrating from a research perspective. The scope and complexity are exactly why it’s taking time, not a lack of concern or capability on the part of the engineers.
Lastly, I can only speak for myself, but I’ve worked very hard to be transparent about how these errors occur, and we truly do our best to respond to every concern that users raise. It would be difficult to find any responses from moderators or Admin that could be classified as “excuses, pablum, delay tactics, blame, deflection, denial, or negation”?
5
Answers
-
@bookworm5 Thank you, and AI, for bringing this to our attention.
0 -
Ancestry provided the index for this collection. When Ancestry identified an event location as Montreal, Quebec, Canada, it is displayed correctly on FamilySearch. However, if only "Quebec, Canada" was indexed, our system mistakenly assigned "Quebec, Hardin, Iowa" as the standardized place. This kind of error has occurred in many FamilySearch collections. We are documenting each instance so they can be corrected during a future bulk processing.
2 -
Thank you for responding. Curious: if "This kind of error has occurred in many FamilySearch collections" then shouldn't previous occurrences have generated protections and automated processes to both clean up all previous such errors and prevent "this kind of error"? I think even artificial intelligence should be able to look at these records and determine that Quebec, Hardin, Iowa <does not equal> Quebec, Canada.
At the very least, why not activate the "Edit" button for such errors? The "documentation" would then come from every user who cares enough to fix it.
0 -
I might as well be the long standing inhabitant of this community who winces at the suggestion of automated clean up processes. Regrettably, we have had instances of emergency clean up processes that actually made the system worse. Hence many of us will be very wary of such cleanups. I'd far rather wait for the techies to understand what the exact reason for the error is (because there are many variations on the issue) and get it right. Although, I'm afraid, even I worry about how long the fixes will take.
As for activating the edit button, given that the index came from elsewhere, it will probably create even more issues to move stuff away from the original.
4 -
I see your wince and raise you a cringe.
3 -
I see your wince and your cringe and raise you a stack of AI (this would be a rAIse):
- If we cannot trust automation then why is FS implementing AI indexing?
- This error should be eliminated by the regular process of uploading external data sets (including indexes). The computer should be programmed to flag records where the FS provided location seems to be different than the externally provided index: [Google maps] https://maps.app.goo.gl/PGcqWAtwK8dBu8Ts8 (and when over 600,000 records are flagged for the same reason then a human should get involved)
- As for activating the edit button, I guess we are devolving back to the "grumble about it to yourself" world prior to nearly 7 years ago (2019) when, {emphasis added} "In the past, if you came across an incorrect index on FamilySearch, there wasn’t much you could do about it besides note down the error and perhaps grumble about it to yourself. That’s all changed now! With the newest update on FamilySearch, you can make corrections to names in the index—with the ability to edit other details in the entries coming soon. By editing the index, you can help other people locate records—and ancestors—they might not have been able to find otherwise."
https://www.familysearch.org/en/blog/editing-names-on-indexed-records-familysearch-update
0 -
In the battle of cringing and wincing I would win, hands down! I find it frustrating to repeat responses over and over! @Adrian Bruce1, you’re right that fixing issues can sometimes create new problems. We had one bulk clean-up in early 2024 and although the targeted errors were fixed, new ones were introduced.
In a nutshell, the plan has always been to safeguard the original place text and re-standardize with better reference data. It is incredibly complex to get everything right so that additional issues are not accidentally added. I’m sorry that it’s taking so long, but engineers are not still trying to figure out what to do. They are working diligently toward the final objective.
3 -
First, let me state that I am in great admiration of what FS does, has done, and continues to do. Every FS page I explore has literally (I mean literally) hundreds of good ideas implemented from the readability of the fonts to the placement on a profile of vital data, to the ability to share profiles without exposing private data, to … (I could go on and on) Everyone who has had a big or small part in the platform deserves much credit; more than I can regularly give. I absolutely believe the claim that most of what is done is in the upper 90's % accurate. And I gratefully benefit far more than words allow. Bravo FS and team! Many times over. I cannot imagine using any other platform.
It is exactly that high level of performance that I am befuddled by thinking "the plan has always been to safeguard the original place text and re-standardize with better reference data." The plan needs to be revised if "better reference data" means re-standardizing "Quebec, Canada" to the 1860-destroyed (now ghost) town of Quebec, Hardin, Iowa. The two places are not near each other, they are not in the same country, one hasn't existed as a "place" for over 160 years, it was never a port of immigration. This error is tremendously large for a human to understand but even larger still for a computer to understand. What computer logic was applied to accepting a file from Ancestry then degrading the accuracy by inserting a tremendously inaccurate location in place of the location provided by Ancestry? I would love some suggestion of how changing "Quebec, Hardin, Iowa" to what Ancestry offered ("Quebec, Canada") could possibly create "new problems" or "make the system worse"? There are no "variations on the issue" - only 1 error: Quebec, Hardin, Iowa <does not equal> Quebec, Canada. Any new errors introduced by such a minor fix is not the fault of trying to fix this - it is the fault of more poor programming (the very same fault that caused the error to begin with - not a new error but the same old one)
This would not be a lot of programming to fix - the actual boolean logic would be:
Fix "Quebec" Program:
01 Begin Program, Open data file
02 Initialize record.counter=1
030 Does FS.location on record=record.counter = Ancestry.location on record=record.counter?
031 If yes, jump to line 04
032 If no, set FS.location=Ancestry.location
04 Increment record.counter by 1
05 if end.of.file has been reached, then jump to line 07
06 go to line 03
07 produce reports of records modified, other pertinent data
08 close data file, close program
Others may win at cringing and wincing but if we're going to use computers to make decisions for us then let us program them right. Don't cringe, don't wince - do it right. When errors occur, learn from them, then fix them … soon! This is how we raise our children, guide our coworkers, manage our lives. We shouldn't make excuses, offer pablum, cause delay tactics, blame others, deflect, deny, negate.
No repeat responses needed. "New" responses addressing the points I offer are welcome.
0 -
@SerraNola
I don't think we say "thank you" often enough - if at all. Please know I appreciate your efforts, and I know many other users who also do.4 -
Thank you @SerraNola for a response that shows more than a superficial understanding of the issue. I can certainly appreciate the fact that lackadaisical programming earlier in a massive transition could have resulted in numerous errors across many data sets (wan't it part of the plan to do it right the first time?). I also can appreciate that some kind of bulk fix for ALL of those earlier transgressions may be complex and take some time to achieve success.
Here is a suggestion that might save countless thousands of people like me some time: for each and every known data set where these errors occurred, place a standard message to the effect of "FS knows there are numerous records in this data set with errors likely caused during the massive migration of over 5 billion records from an old system into a new one. We are working on a massive correction needed to uphold our standard of 98+% accuracy. Thank you for your patience while we work to make these corrections. We currently project the affected records (the ones we know of) to be corrected by _ _ / _ _ / 202x. Please reach out to our community if any record remains incorrect after that date. Should you come across additional data sets that are in need of a correction please report them immediately to _________________________ and we will verify and add this message to that data set as well. Sincerely, the Techies"
You probably wouldn't even have heard from me if this sort of message had been posted on these pages:
2 ~ https://www.familysearch.org/en/search/collection/1803785
3 ~ https://www.familysearch.org/ark:/61903/1:1:XPBJ-V5Q?lang=en
One question, what do you think is a reasonable replacement for the "x" in the date above?
1 -
Answering my own question here without knowing the scope of the problem nor the current status/schedule for solving the problem but, since it is 4/4/2026 today I think if "x" is any larger than 7 (meaning by the end of 2027) then a new plan needs to be developed.
On the same subject but using a new example: what is the novice researcher, such as I am, to do about a record like: https://www.familysearch.org/ark:/61903/1:1:QP61-5ZXB?lang=en
Clearly "Event Place Deutsches Reich" is insufficiently located but is it part of the cleanup or no? How would I know? I keep coming across these types of indexing location errors (not as many 124 collections … yet, but I'm into the low teens.) Should I stop what I'm doing, come here to Community and point out the problem, then have a bunch of back-and-forth with others until someone decides to explain that the problem is already known, a fix is in the works, and give me a date that I can pause my concern until? Is that what has been done with each of the 124 collections referenced earlier? The problem I first mentioned ~ was it already part of the known errors that is being worked on or is my reporting here the impetus for including it into the mix? Has it now, actually, been included into the mix?
or what about https://www.familysearch.org/ark:/61903/1:1:QVGD-SMJW?lang=enClearly, the correct cemetery in "Affton, St. Louis, Missouri, United States of America" is not Sunset Cemetery, Moose Jaw, Moose Jaw No. 161, Saskatchewan, Canada
or what about https://www.familysearch.org/ark:/61903/1:1:Q2DV-Z6KP?treeref=9KZJ-HKJ&lang=en Clearly, Event Place
Riverside Cemetery, Knoxville, Tioga, Pennsylvania, United States
Denver, City and of Denver, Colorado, United States of America
0 -
My previous post was submitted before I was finished which is just as well since I would have listed another dozen records I have been collecting and trying to get fixed. Is this why it is "frustrating to repeat responses over and over"? It should also be considered frustrating to keep running into wildly nonsensical errors without any means of correcting them, reporting them, knowing whether somebody is already working on fixing them, and knowing when they are projected to be fixed. Should I just do nothing and go about my way while low-grade "whistling past the graveyard"?
If anyone knows a way to submit an idea (that might be actually considered for implementation) please consider submitting the suggestion of flagging all known record sets that are being worked up for bulk correction.
0
