For some NONEXISTENT value of "exact"

LegacyUser

Juli said: ("EASE UP ON THE ALL CAPS IN YOUR TITLE. It looks like you're shouting." And you need to shout that at me because...?)

https://www.familysearch.org/search/r...



Can someone please explain to me how the following could possibly be interpreted as exact matches to a birthplace of Sérc, Sopron, Hungary?

Deutch Schutzen, Hungary
Cseszie, Hungary
Schutzen, Ungarn
Deutsh Schutzen
Krout Schutzen, Eisenburg, Hungary

Németlövő (Deutsch Schützen-Eisenberg) was in Vas county; it's now in Burgenland, Austria. Horvátlövő (Kroatisch Schützen) is still in Vas county (despite the two villages being walking distance from each other). There was (is) a Lövő in Sopron county (now in the combined-remnant Győr-Moson-Sopron county) which is Schützen in German and was previously sometimes called Németlövő, but it's a full 25 miles (as the crow flies) south of Sérc.

Sérc (older spelling Sércz) is now Schützen am Gebirge, Burgenland, but its German name while it was still in Hungary was Gschiess, and a plain "Schützen" is highly unlikely to refer to it.

"Cseszie" from the NY naturalization record is most likely a typo for Cseszte, Pozsony county (given the husband's birthplace of Pozsony and their marriage location of Bazin). I presume it's showing up in my search because it sorta-kinda resembles one of the other alternate names of Sérc, Csesznó.

"Sorta-kinda resembles" is NOT a synonym of "exact match".
The fact that Lövő and the Schützens have variant names that resemble variant names of Sérc does NOT somehow magically make them into the same place.

When I search for events in a specified location and check the "exact" box, I want and expect ONLY events that actually took place IN THAT PLACE, not in some other town fifty miles away that kinda-sorta shares name variations with it. If the event place as indexed does not match the search term, and the location cannot be definitively determined based on the index, that item should not appear in exact placename searches.

LegacyUser

Brian Rhees said: Juli,

Thanks for the details on this issue. I've dug into these places and it looks like (for the most part) it was incorrect standards/places that have been fixed since. These types of fixes have a bit of a delay before they make it into the search results. We plan on having a data refresh shortly after RootsTech (so, in roughly a month).

You're correct that an "exact match" isn't a "sorta-kinda resembles". The issue here was the place names were standardizing too broadly which all thought they included "Sércz, Sopron, Hungary". All of them have been fixed since they were last refreshed.

The only exception is "Cseszie, Hungary" which still included Sércz as a potential place it standardizes to (when trying to correct spelling of Cseszte it finds the correct place and does not include Sércz).

LegacyUser

Juli said: So wait a sec: the search algorithm for places is using what comes up in the standardization drop-down to determine matches? Even when you check "exact"?? No wonder it's all so screwed up!

LegacyUser

Brian Rhees said: When a record comes into the system it will index the place on that record using standardization (we use a different call than what is shown on the the research places page; our results are a filtered list of those results). Sometimes records with vague place names, or a place that has changed names over time will be indexed for multiple places in the database.

When you run a search the place name you typed in will standardized to help find the matching location indexed on the records. This is where the "exact" checkbox comes into effect. It changes if results should be returned from surrounding areas (with closer results returning higher in the list) or if it should be restricted to the standardized place from the typed in text.

See this explanation I wrote last week from a similar problem you ran into on how the exact checkbox works:
https://getsatisfaction.com/familysea...