Records where [Location=Buffalo] are now [Location=State University of New York at Buffalo..]
Records where the location is Buffalo (Erie,NewYork) are instead presenting
State University of New York at Buffalo, Buffalo, Erie, New York, United States
as the location. It's also being aggressively inserted into autocomplete, in some cases Buffalo proper will not appear.
ref: https://www.familysearch.org/ark:/61903/1:1:KQBH-GB1
The end result: We're told families live in Uni so Uni it is.
Eventually Buffalo will never be and the population will have always lived on campus.
Answers
-
Every now and then, I use the nearest Feedback tab and/or the "improve" button in the Places tool to report a particularly-egregious error in locations.
(Two that I reported recently: the continuing farce where it puts Vienna in a pair of farmhouses 50 miles from the city, because apparently in the automangler's world, Wien = Wies; and the dozens of entries just on the one page I looked at where baptisms in one of Budapest's central districts, called Erzsébetváros, have been moved to a town by that name with population 2500 in Kis-Küküllő county, 100 miles short of the furthest you could get from Budapest without leaving pre-1920 Hungary.)
2 -
As it looks like this problem (and countless other reported examples) is not going to be resolved any time soon, at least there is a workaround when it comes to finding sources for an individual where the placename has been incorrectly standardized: the use of wildcards.
From the example quoted by @No one in particular I carried out a search for the individual in question, using the inputs shown at https://www.familysearch.org/search/record/results?count=20&q.anyPlace=buffalo%2A&q.anyPlace.exact=on&q.givenName=salv%2A&q.givenName.exact=on&q.surname=passaf%2A&q.surname.exact=on. As long as "Buffalo" appears somewhere in the record, all variants will be presented. I did wonder about the Military Service one, which does not appear to refer to Buffalo at all, but when the record is opened (see https://www.familysearch.org/ark:/61903/1:1:7BCH-CLPZ) the Residence Place field does indeed show "Buffalo N Y".
Again, in relation to making searches, I don't have my settings to provide any "autocomplete", and find "Buffalo, Erie, New York, United States" is the second offering in the placename drop-down (the place in Cass, North Dakota taking first place), but I do realise the issue extends beyond the matter of getting results from "Search".
Finding such records won't be anywhere near so easy in Julia's Wien / Wies* example, of course, but as the overall problem shows no sign of being fixed I think we have to continue to "think outside the box" when it comes to getting the desired results returned in our searches.
(*Perhaps inputting Wie* as the placename might get to records that would otherwise remain "hidden"?)
2 -
Just to add - and I admit in dealing with "Search" problems I am not necessarily addressing the issue @No one in particular is highlighting - I decided to see what records could be found for a Salvatore Passafiume (or variant) by not checking the "Exact" box. See https://www.familysearch.org/search/record/results?count=20&q.anyPlace=buffalo&q.givenName=salv%2A&q.givenName.exact=on&q.surname=passaf%2A&q.surname.exact=on. Of course many of the records (in this "extended list") will have no reference to Buffalo (wherever), but will at least bring up what is probably a more worthwhile set of results if the individual (rather than the place) is the object of your research. (No good if your man is "John Smith", of course!)
1 -
@Paul W 1) I had difficulty finding all of the expected records for Salvatore Passafiume's family.
2) One example of the autocomplete issue: When attaching affected census records→ editing the location field. Sometimes I pick Buffalo proper and Buffalo Uni would populate anyway. A couple times I found lots of Buffalo but the only NY Buffalo was Buffalo Uni.
Editing this field in the mobile WebUI is already difficult due to the the oversized format of New Linker. The autocomplete text squeezes into a super narrow dropdown list. Imagine someone printing a banner in portrait mode.
When I rediscover where else I had the autocomplete issue, I'll post.
3) To better see how pervasive this is, I'll post records as I find them. Here are 1940 &1950 census.
https://www.familysearch.org/ark:/61903/1:1:6XRQ-S4P5
https://www.familysearch.org/ark:/61903/1:1:KQBH-FTF
(unrelated sidebar: We can only quote posts in their entirety, it seems. This eliminates most of the usefulness and usually discourages me from quoting.)
0 -
At least the University campus is in the same county and state.
I just reported an 1840 census from Liberty County, Georgia, USA that has been automagically transported to the city of Philadelphia, Pennsylvania, USA.
0 -
My day job is sorting chronic tech issues. If they're persistent, we have insufficient tech or too few talent. It's usually both; tech isn't fully up to the task and full staffing is needed to fill the gaps.
My point being - what you're describing feels familiar.
0 -
I think I overstated the issue in the OP. I now believe this is limited to the 1940 and 1950 census records.
https://www.familysearch.org/ark:/61903/1:1:6XY4-PKRC
This family is NYC but I unexpectedly found two siblings in Buffalo. When I started into their extended families, I was mostly working out of those two census and my perspective must have been off.
0 -
Found a non-census result, a naturalization record.
https://www.familysearch.org/ark:/61903/1:1:68HY-1SD7
0 -
I found a 1900 census where the location should be Buffalo, Erie, New York, USA
but is State University of New York at Buffalo, Buffalo, Erie, New York, United States
ref: https://www.familysearch.org/ark:/61903/1:1:MSXX-B48
That record indicates an edit was made and the correct location was was appended. The edit appears when I Expand Edit History.
I'm not sure what the point of the edit is however. In the record, the edit is hidden by default.
And the correct location doesn't manifest during an attachment. correction: It doesn't display during the attachment preview. At this point, State University… is presented as the location to be attached.However, during the attachment process, the correct Buffalo unexpectedly populates the Location field. This is a good thing (not the unexpected part, the other part).
I appreciate it when I don't have to correct every attachment.
Not having received any feedback on the issue, I will hope this record-edit-thing indicates progress.
0 -
Since the activities of the autostandardizer are now secret, and the results of index editing are likewise not fully communicated, I'm afraid that we the users of FS have no hope of diagnosing where in the complex tangle things are going wrong. All we can report is that they are going wrong, persistently but unpredictably. We continue to be unable to fully trust anything that FS says about "where".
(To be fair, I don't think index editing's miscommunications are necessarily deliberate. [Hiding the autostandardizer's output, on the other hand …])
Specific to the topic raised just above, of unexpected (though in this case welcome) mismatches between what's shown and what Source Linker transfers, I have a theory: the two sides of Source Linker must be taking the location information from different points in the automangling-and-index-editing timeline. After people reported SL's undesirable behavior regarding edited event locations, they must have tweaked the algorithm to use the latest revision of the location value instead of whatever original or intermediate value it had been going for. However, that change only applies to Source Linker, not to the algorithm that determines which part of the indexed-records database is displayed in the left-hand column. Hence the mismatch.
3 -
The underlying data may be of interest (suggest click on the JSON button to make it easier to read).
The original event place (EVENT_PLACE_ORIG) is given as 'Election District 2 Buffalo city Ward 19, ED 156, Erie, New York, United States'.
All other EVENT_PLACE's including 'Buffalo, Erie, New York, United States' appear to be 'interpreted', i.e., presumably, subject to FS placename algorithms.
1 -
@Julia Szent-Györgyi I'm chewing on your post. I can absorb slowly but @MandyShaw1's post helped slot most of it into place. I trust your assertions by default but need to get caught up on what's behind all the curtains.
0 -
I didn't know the dev portal was a thing. My hyper focus on research might be stunting my curiosity.
Your post helps.
0 -
Much of the developer portal stuff is not available through the browser, but the /platform/records stuff seems to be, fortunately.
1 -
In relation to my last comment, the /platform/records URLs don't work in the browser for all records.
It appears to fail on the ones showing 'Image Unavailable' and to succeed on all others I have tested (whether or not the record is attached to the Family Tree).
1
