1870 U.S. Census incorrect geographical place standardization
I have encountered many 1870 U.S. census records with erroneous geographical place standardization for Washington and Smyth Counties, Virginia. Examples:
https://familysearch.org/ark:/61903/1:1:MFGZ-6SV
Event Place: Dilltown, East Wheatfield Township, Indiana, Pennsylvania, United States
should be Smyth, Va.
https://familysearch.org/ark:/61903/1:1:MFG6-HRL
Event Place: Dilltown, East Wheatfield Township, Indiana, Pennsylvania, United States
should be Washington, Va.
Thank you for any remedy for this.
Answers
-
Another
https://www.familysearch.org/ark:/61903/1:1:MMJN-SCC
Event Place: Buena Vista, Virginia, United States
Event Place (Original): (west part) Bristol city Ward 2, ED 144, Washington, Virginia, United States
This one at least has the correct original event place.
0 -
@N Tychonievich, please. At least some of these are placename standardization algorithm issues. Could you please take a look? Thanks!
0 -
I reported a few similar errors here, not the census but birth registers, and the kind people here got them fixed. But for records already attached they still have the erroneous locations. Frankly, there are so many of these errors if I reported them all it would be all I could do, so I just try to be careful when attaching sources.
0 -
I’m encountering the same issue all over Massachusetts. Here’s one where it has been four different places, the only one correct is Boston. https://www.familysearch.org/ark:/61903/1:1:MD3V-JGK
To add: Almost every record I’ve attached for Essex County, Ma now says folks live at a cemetery. It’s obnoxious.
0 -
For the location errors that I reported, the correct location is listed in the search results but not in the record. I have been copying and pasting the correct locations from the search results into each entry. It is slow but it does force the correct location to paste to the detail section of each person in the tree.
0 -
From Scott Co., Virginia:
https://www.familysearch.org/ark:/61903/1:1:MFGZ-4ST
Event Place in record (incorrect): Luray, Prairie Township, Henry, Indiana, United States
Event Place in Search Results listing (correct): Powell District, Scott, Virginia, United States
0 -
From Wythe Co., Virginia:
https://www.familysearch.org/ark:/61903/1:1:MFGX-8Z5
Event Place in record (incorrect): Dilltown, East Wheatfield Township, Indiana, Pennsylvania, United States
Event Place in Search Results listing (correct): Blacklick, Wythe, Virginia, United States
0 -
From Grayson Co., Virginia
https://www.familysearch.org/ark:/61903/1:1:MFG9-4QH
Event Place in record (incorrect): Luray, Prairie Township, Henry, Indiana, United States
Event Place in Search Results listing (correct): Elk Creek, Grayson, Virginia, United States
0 -
This is the link to a page which shows the following:
The event place is Coffee County, Alabama, United States. Genesee, New York is incorrect but I can't find a way to edit the Event Place. Any suggestions will be appreciated.
0 -
Rescued URL: https://www.familysearch.org/ark:/61903/1:1:MHVB-BBY?icid=home-tasks&treeref=LM1T-VCF. (Don't give URLs their own line in this Community. It'll mangle them.)
I was going to ask whether you'd tried the Edit button on that page, but I see that it doesn't help: it's correct on the edit-everything tool's index panel.
This appears to be (yet) another variant on the new index-correction tool's inability to communicate properly with the index detail page. Either that, or it's running the autostandardizer on the corrected place and coming up with utter balderdash. Either way, I don't know how to fix it, but I'll go and report the problem using the Feedback tab on the index editor. (Perhaps if we ask there often enough, they'll make a Community group for the editor where we can report its newest goofs.)
5 -
Thank you very much! I'm glad I wasn't the only one who couldn't find a way to edit that field. I found other issues with the family record itself which I have decided to table for now. I'll take it up again one of these days.
1 -
You can console yourself that despite the error(s), the index served its purpose: you found the record.
0 -
I am find this common on many more indexes now. It happens on some Texas birth records i have worked on. just yesterday I was working in Kent, Maryland and the search shows the names/family in that location but when I added the source it wanted to make the location Maryland, Terre Haute, Vigo, Indiana, United States. Not sure where the defect in the system is but I am finding these place error conflicts more frequently.
2 -
Great that one can find a record but then when attaching the incorrect location is what shows to attach to the person … stop the algorithm it isn’t working.
0 -
I think the records for Resurrection Cemetery have a glitch. The records list the event place as Resurrection, Kapisha, Chingola, Chingola, Copperbelt, Zambia when it's supposed to be Justice, Cook, Illinois, United States.
Here's an example: https://www.familysearch.org/ark:/61903/1:1:Q2HN-R9SG
On a related note, when looking at related records on the right side of record pages, some will be attached to people but it will say attached to X person when its attached to Y.
0 -
I have reported that the "Event Place" corrections made are buried in the dropdown list while the incorrect location remain the primary place. We do not know how long it will take to have the problem solved. Thanks for your patience. I will let you know when I hear something back.
3 -
I have found a ton of these in Tennessee, where the original place was something like District 5, SomeCounty, Tennessee, and they all got indexed into Grainger County regardless of the original county.
1 -
I have noticed that, too, in Tennessee. It seems to occur because there is not a standardized place name for the numbered districts in other counties. For example, "District 4, Sullivan, Tennessee, United States" gets standardized to "District 4, Grainger, Tennessee, United States" in https://www.familysearch.org/ark:/61903/1:1:MDW6-V7L. It seems like all these numbered districts would need to be added to the geographical name list, then geographical name matching run again.
0
