Some 1840 US census reports are no longer indexed to the right place
https://www.familysearch.org/ark:/619...
https://www.familysearch.org/ark:/619...
Indexed as Surry, Virginia, but for Surry, North Carolina
https://www.familysearch.org/ark:/619...
https://www.familysearch.org/ark:/619...
Indexed as Wayne, Mississippi, but for Wayne, Kentucky
These were indexed correctly before -- the residence entries for them show the correct location. They're not found if you search for the location.
I've also seen a lot of entries where they can't resolve the location, so it just links to "United States", even though they're filed into the right catalogs:
https://www.familysearch.org/search/r...
Answers
-
Tom Huber said: I suspect these were early indexes so when the films were digitized and matched to the indexes, someone missed getting the right image with the associated index entries.
I can see where this can happen with the same name for a county used in more than one state.
FamilySearch will need to address this issue and verify the situation in the instances you've found and all other instances where a county name is found in more than one state at the time of the census enumeration.0 -
Ryan Torchia said: I don't think it's just a problem with how they were indexed, because these used to be working correctly. This is a recently introduced bug, where however the system determines the record location got disconnected from the geographic location the individual volumes were assigned to.
I honestly think it's affecting the entire 1840 census database, but just isn't apparent when the indexed location is complete enough for the system to guess the right place. My guess is it'd be a relatively easy fix.0 -
Ryan Torchia said: Any update on this? Is somebody at least looking into it? It's still happening and severely impeding progress.0
-
Happy two-year anniversary to this bug, which remains thunderously ignored.
0 -
Wow, so the auto-standardization had already started two years ago? I thought it was mostly more recent than that.
0 -
@Julia Szent-Györgyi I think the problem has spread to some other catalogs. I remember the 1790 US census broke a few months after 1840. It seems like they used to at least take what catalog the record was in into account, rather than trying to standardize off of just the location indexed in the individual records (like the Surry examples above).
I think I flagged it pretty quickly. It's really frustrating that they couldn't identify and revert the change that caused it quickly. Now with two years of additional code changes on top of it, it'll probably be a nightmare to fix.
0 -
I thought this was funny -- Virginia records aren't being linked to cities in Virginia:
https://www.familysearch.org/ark:/61903/1:1:6ZLF-X4RP
(Not funny 'ha ha', more like depressingly ironic.)
0 -
@RTorchia, yes, that's yet another demonstration that the autostandardization routine failed to apply even the most rudimentary of data validation or sanity checks.
I suppose you ought to report it, but it's all so tediously depressing that I can fully understand if you don't feel like bothering. It's a fact of life, now: event locations in FS's database are hopelessly corrupted, so don't believe anything that Search - Records tells you about "where", and use alternate methods for localized searches (such as film numbers).
1 -
@Julia Szent-Györgyi I just don't know where to report it besides here. I've been a QA engineer for 25 years, so writing bug reports and isolating problems is second nature, but it's pointless to do that if there's no bug database and no direct line with the engineers.
More frustrating than just this specific issue is the lack of faith I have in FS from a technical project standpoint. We've got constant creeping breakage, no connection between developers and users, and constant tweaking (and breaking) of features and UI that is completely fine and that nobody is asking to have changed, while long-standing bugs and needed functional improvements are pushed aside.
And with all that said, this is still the best genealogy DB site I've found. A lot of the UX design is fantastic and novel. It makes me wonder if, like, 3-4 years ago this team had its funding slashed or lost some key architects and engineers. Now whenever a change is announced I only feel dread rather than excitement.
0 -
This has been marked as "Answered". Could somebody remove that? It absolutely has not been addressed whatsoever and is still very much and very depressingly a problem.
1 -
It used to be that a Community moderator could mark a post / question as "Answered". Hopefully, they are no longer able to do that, as only the original poster should be arbiter in that matter.
BTW - in this instance, I can't see where this has been labelled "Answered".
0 -
With regard to your first example, the record indexed as Surrey, Virginia appears not as yet corrected. I will move this one into the queue to be reviewed and fixed by the appropriate team. 2+ years is a long time to wait for a correction - sometimes things get missed. Hopefully, by raising the issue once again, we'll see the problem fixed.
Indeed, your second example is of one that has been corrected. The record now correctly identifies Wayne, Kentucky.
0 -
@Mike357 Trying to fix each volume separately seems like the wrong way to fix this. Remember: originally it was working. Wayne, KY may be fixed, but, for example, here's a search that finds 4,885 entries whose location can't be determined at all.
Is the plan actually to have users report every volume where this occurs separately, with no dedicated method for reporting bugs or tracking when they get fixed?
1
