1840 census locations are STILL botched
I had this written up in the legacy channel here: https://community.familysearch.org/s/idea/0874V000000sih6QAA/detail
which includes several examples. It's not going to copy cleanly, so please go there for the details.
In short, it looks like for 1840 census records, if the state wasn't included in the original index, the "event place" doesn't link to the correct location. This means it don't appear in searches if the correct location is included in the search, and when linking the record, the wrong location is included in the info.
This definitely WAS working and broke earlier this year. If I had to guess, I'd say whatever code tries to standardize the location stopped taking into account the location specified by the census volume itself.
For example:
https://www.familysearch.org/ark:/61903/1:1:XHRV-CC9?treeref=LZDJ-T7S
This record page says it's for it's for Waterford, Wahkiakum, Washington, United States, because "original" event place is Waterford, Washington. A search for Daniel Robert residing in Ohio won't find this. But if you view the image, it knows shows the correct location for the catalog breadcrumb of Ohio > Washington > Waterford Township: https://www.familysearch.org/ark:/61903/3:1:33SQ-GYY1-9NB7
Comments
-
This is still a problem. Who is working on it?
0 -
Can somebody please at least acknowledge this bug? It's now affecting 1790 and 1830 census records as well, and definitely used to be working.
As far as I can tell, it's not happening on 1800-1820 census reports, but all those include the state in the Event Place (Original) field.
0 -
I would think it best to raise this as a Support case, as it doesn't appear you are going to get any resolution (or even acknowledgement) of the problem by reporting here.
Unlike, with the old GetSatisfaction forum, it is very rare to see any responses from FamilySearch personnel here. Many of the former, regular GetSat contributors seem to have given up on "Ideas", too. Perhaps they are hoping that boycotting this platform will lead to FamilySearch introducing a better alternative, as promised.
0 -
My belief is that this is not a software bug (in the sense that the coding doesn't match the spec'n) but an inevitable consequence of the design of the system (ie. the design is wrong).
The Event Place (Original) on the census is "Waterford, Washington". Just that. Nothing in there about Ohio. The designed system takes the Event Place (Original) and automatically, in the background, looks up a standardised place-name for it. If you use the FS Place-name tool to enquire on "Waterford, Washington", the first one on the list is "Waterford, Wahkiakum, Washington, United States" - which is the Event Place that's ended up on the Historical Record for that census.
Please note I'm not defending this, I've had the dirty end of this stick myself.
So far as I can see, there is, in this case, nothing wrong with the standardised place-names. The contributory causes are:
The Event Place (Original) on the Historical Index Record is so thin / skimpy / short that a poor match is bound to occur when the County matches a State elsewhere. If the US State were to be added, then in this instance, "Waterford, Washington, Ohio" would match correctly.
The production of Event Place from Event Place (Original) takes place automatically in the background, so there is no possibility of anyone saying... "Pardon?" To what extent a manual audit can be done, I'm not sure.
Both those options (and there may be others) could help in this case. Both are sizeable items.
I'd guess that it's worked beforehand for you because either the production of Event Place from Event Place (Original) was manual beforehand or you've never seen places where the County matches a State leading to this confusion before???? Wild guess....
0 -
My belief is that this is not a software bug (in the sense that the coding doesn't match the spec'n) but an inevitable consequence of the design of the system (ie. the design is wrong).
Well, we can debate about what constitute a "bug". :-) I've been in QA for 25 years, so my definition is basically anything that runs counter to product intent or reasonable user expectation. A poor design or implementation is a bug as much as a missed colon in the code. Especially when there's a feature regression like there is here.
[...] Both those options (and there may be others) could help in this case. Both are sizeable items.
I think, unless the "Original" field data was very corrupt, it would just be sufficient if the standardization function was performed using Event Place (Original) + the state the record is in as input, like you suggested, which actually seems like a fairly easy change to me and probably how it worked before, (though granted I don't know the details of how the function is coded). I don't know if this is happening on specific collections because it's broken just on them, or if the others all include more complete Event Place data. When I checked the 1800-1820 census reports, the 1800 and 1810 reports don't show a separate (Original) field, and the 1820 reports all show what looks like standardized locations for both Event fields, the only difference being the (Original) field excludes "United States". Who knows, maybe they went ahead and hard-coded the standardized locations into those collections instead of dynamically generating them like they still do elsewhere. One other weird thing I just noticed is that the 1800-1820 census reports return very few results if a you search for a residence without including the state.
I'd guess that it's worked beforehand for you because either the production of Event Place from Event Place (Original) was manual beforehand or you've never seen places where the County matches a State leading to this confusion before???? Wild guess....
I don't think so. I think it actually used to include the location of the record itself when resolving the standardized location, and for whatever reasons, that just stopped happening. The reason I say it was working before is because these errors don't appear in profiles where this info was added longer than ~1 year ago. This error would be much more widespread if it had never worked correctly. When it first happened, I went back and checked records that I had edited earlier and that I know I didn't manually standardize, and saw that the record indexing location had changed.
0 -
Raise a toast to the one-year anniversary of me reporting this bug on the old system. I can't believe it's gone by so quickly, and so little has been done.
0 -
This is still a problem. I was looking for records for Indiana in 1840 Census. Results indicate Smithfield Indiana but when you go to view record and scroll a page or two you will see this is Rhode Island
1 -
Yeah, it's still absolutely baffling to me that they didn't try to fix this as soon as the problem came up, when they could have reverted the problem quickly. Now the bug is buried somewhere in code nobody's touched in a year and a half.
0