Setting Country in Search Engine
The LOCATION is a great feature for general use.. However...
At times having to reset it to a specific country repeatedly can be frustrating. As is often the case when you are focusing on a specific country for records in your locality. Otherwise as it defaults and continually brings up records and in particular records in the USA! Which is great if that is what you require :-) For others this is not true. 😑
Suggestion please make it possible to set the country as it does always indicate which it has been set to.
On logging out - then revert to ALL countries as one may forget and actually want a general search to be performed by FamilySearch.
Comments
-
I am so frustrated that the wrong country has been selected in over 900 entries.
The records clearly state SOUTH AFRICA but all the indexing is for Maryland, United States.
I am correcting all of these entries, one by one.
How can this be prevented in future?
Example attached:
0 -
It seems to appear that the filters (algorithms) on the search function on FamilySearch are not able to restrict to just the country where users are particularly focussed on.
I do agree it makes little sense when guests need to trawl through hundreds of possible records to possibly find a thread to follow.
This is frustrating and hopefully the more feedback is given by guests when the time is right a solution may be found.
2 -
This is yet another example of the widespread metadata errors on FamilySearch caused by automated attempts at associating indexes with the places database.
Up until a few years ago, indexes were completely separate from the places database. There were locations associated with events and names, but it was all just text, and the search/match algorithms were purely text-based. If I told it to search for "Pécs", it would not turn up any records that were labeled "Fünfkirchen". (No idea if there are an indexes labeled that way; this is just a theoretical example.)
At some point, FS decided that indexes needed to use the places database. This meant that the text strings found in the location field(s) needed to be parsed and associated with a matching database entity. They applied various automated processes to make these associations.
Now, if I search for "Pécs", it doesn't matter how many "exact" checkboxes I mark, it'll bring up records labeled Fünfkirchen, and I have no way to get rid of them. (Again, theoretical example. My actual experience was with looking for records from a specific church, and failing miserably, because the places-database-based search "helpfully" ignored every phrasing of my request for "only THIS church, you dratted thing!".)
But aside from the changes caused in Search's behavior, the biggest problem with incorporating the places database into indexes is that more often than not, the association-creating processes Got It Wrong. South African places got mapped to Maryland, Indiana ended up in India, and who knows what else. And there's no mechanism in place for reporting these system-wide errors, never mind getting them fixed.
2 -
totally agree with Julia
but . . . whats the best way to get this fixed - - surely going one by one is not the best way to do it?
can we get someone from FamilySearch to respond to this??
3 -
I do see some of the problems here - there are actually two discussions going on in this thread - one an idea and one to address problems where automated systems at FS may be incorrectly changing record indexes and thus searches being found when the Researcher is trying to only obtain results in a particular country - it is difficult to determine whether the problems are the reason for @GEH9 post here (for which the suggested idea will not resolve) :
for example, since I do not have access to @sharonjennings2 search/parameters I searched a few on the Results list from her screenshot.
The result for Leon was corrected by someone - the next couple appear to still be defaulting to Maryland - so
I am trying to understand @GEH9 idea post, and am just wondering ... is this problem being caused by:
overzealous Americans (perhaps myself included) - wanting to help 'fix' placenames but ACTUALLY harming the index by picking the wrong location?!!! I am guessing this could be the cause of the problem - I don't know about automated processes @Julia Szent-Györgyi - again this is AN IMPORTANT EDUCATION process for people wanting to help with Standardizing placenames to understand. I tried myself the other day and don't know that even though I got the Country right (hopefully) - I don't really know if I 'harmed' the neighborhood.
So IF I am understanding GEH9 concern - it is that us overzealous Americans 'correcting' placenames - are actually NOT helping or getting it right!??
Solution as I understand it: Only allow those 'fixing' placenames access to those records from the localities they reside - they will have a much better chance of knowing/fixing the placename correctly.
These problems are SEPARATE from the idea being posted here.
NOW back to GEH9 posted idea above: This is also a Question/Discussion under Search where I have done my best to address the issue. I believe GEH9 idea here has merit - a setting to remember User login Search focus based on a User controlled setting. I can support such an idea while referencing the capability of the User to do essentially the same thing through a bookmark/shortcut on their own system.
1 -
The trouble with any attempt at fixing the "improve place names" process by restricting people to areas they know is that the whole point is that the computer doesn't know where the places are. The process can't assign things to people from the same region, because all it knows about "where" is "somewhere on planet Earth".
However, the Improve Place Names process is not responsible for the ever-more-widespread metadata errors in FamilySearch indexes. Improve Place Names applies to Family Tree, not to indexes.
0 -
@Julia Szent-Györgyi Good to know. Well, I mean not good to know that automated systems maybe/are the cause of this problem - but good to know that placename 'fixes' would be separate 'only in the tree' - or HOPEFULLY that's the case. I sure would not like to cause problems by 'getting it wrong' in placenames!
Comment: Certainly the computer would at least be able to match the country in the index and the country from the FamilySearch user (in their user settings)?? If the automated systems cannot determine country level on the document - then I don't think they should be automating changes.
1 -
The source of the entries in Improve Place Names is people typing. Sometimes, it's exactly the country (or continent!) that's most in question.
The post-processing that tries to turn an index's pure-text placename fields into database associations likewise is mostly dealing with the result of people typing. Knowing what country the records come from doesn't say much of anything about things like birthplaces or prior residences that may have been indexed. Although I suppose Occam's Razor does imply that if you're in Ohio, "Kny" means Kentucky, not Kenya...
0 -
Right, but there is only one correct index location that should be generated for the document. My point I guess is that the Project in Indexing should obviously know the location the records are from - and any change to the contrary should not be allowed - whether that's country, state, etc. So I don't really get whether the problem is from automated processes 'changing' an index produced by humans OR whether it's the automated process generated index. Either way the Project should determine some level of placename accuracy and not 'allow' variation from that level.
0 -
Index entries can contain multiple places. A census, for example, could contain current residence, prior residence, birthplace, father's birthplace, and mother's birthplace. In order for those fields to be searchable by the current algorithms, they all need to be associated with entities in the places database, but the only one that the location of the record has any bearing on is the current residence. The rest could theoretically be any populated place on the planet.
There's a reason indexers are almost always instructed not to expand abbreviations or correct spelling, but to index what they see: sometimes "Kny" isn't Kentucky. I don't know why or how FamilySearch now expects a computer to do what they didn't trust people to do previously.
0 -
@Julia Szent-Györgyi perhaps pre-index processing could set a geo boundary for the records and leave field entries where boundary external locations could vary not be restricted to those bounds?! Especially country!
0 -
Fortunately, in all the cases I have seen, the indexed record includes the original place as well as the probably post-processing automatically "corrected" place, such as this example: https://www.familysearch.org/ark:/61903/1:1:QGLX-D8C2 from the database Sharon is concerned about:
Unfortunately, I think FamilySearch is going to have to decide that this attempt to fix place names was a bit of a disaster, delete all the place names, restore the original place names, and try again.
I wonder if this change in place names is the underlying cause of complaints from people who state they can no longer find any records and who are blaming it on the new layout of the search form.
The reason I think this is all post processing is that I have run across a large number of these errors in some new Norwegian databases which are just imports of the same database on the Norwegian archives website. On the archive's site one can see exactly how the record was originally transcribed and compare that to what happened between there and the FamilySearch version of it.
3 -
@genthusiast 1, the major problem with your idea is that people move. Even a century or two ago, sometimes people moved clear to the other side of the planet. Therefore, there cannot be any limits on what indexers enter in placename fields, other than the one identifying where the record was created -- and that one is almost never up to the indexers.
0 -
@Julia Szent-Györgyi I think you misunderstand. The record WAS in/recording a particular place at a particular time. Thus has nothing to do with people's ability to move halfway round the world. If there are fields that indicate moving from/to - then yes - those could be left open/unrestricted. If persons moved the physical location of a record halfway round the world - the record still refers to that other location at a particular timeframe ...
Perhaps an example will help - take Ireland an island - a record from there with fields of 'residence' - will of necessity be restricted to the island. Fields of whether they were 'from' or 'moving to' Scandinavia, Scotland, Britain, Wales, France, etc - are not common unless you refer to larger manuscripts/collections than parish records. So what I am saying is bound the record geographically with common placenames leaving outliers such as you are indicating open for the Indexer to index what they see. I hope this helps explain - it seems like you are seeing the 'negative space' and I the 'positive' - it's the same space and can coexist.
Yes - Records from earth are bound to earth and typically won't have any other entry (unless broad 'fiction' is included as a record type). But what I am believing is that records can be geographically bound - in a pre-indexing process - to allow/not allow entries beyond those bounds... I hope I am clear. Post-index processes should not change India to Indiana, South Africa to Maryland - based upon the name of a South African hospital, etc. These algorithms should be in place to prevent what I am assuming the discussion above is about - post indexing processes changing the Index. Even if the Index is indexed 'wrong' or from a partner site these algorithms should identify discrepancies and allow for their 'efficient' correction (a reindex of incorrect larger portions) versus researcher piecemeal/difficult correction. I hope I am identifying the problem correctly - these are my suggestions.
0 -
I guess you haven't done much indexing on FS, @genthusiast 1. I alluded to this in my comment: the location of the record is almost never an indexed field. It's added in pre- or post-processing. The only record type I can think of where indexers have any input on the "event place" or similar field are U.S. censuses.
Putting bounds on the pre- or post-processing step might help with the Maryland-versus-South Africa type snafus, but putting bounds on the human-input parts of the process Aint Gonna Work, and in any case, that's not where the problem comes from.
0 -
@Julia Szent-Györgyi you are welcome to your assumptions and opinions - that is Community - i never claim to be the expert - you may claim expertise as you wish - I see a post/issue and address it with my genthusiasm. I have stated in previous posts that I am returning to indexing recently - even in that limited time I have already run across 'placenames' so I am at a loss from your statement of 'superior' indexing. If you say that this isn't an indexing problem - then again - I think we're on the same team here - the 'problem' whether 'during indexing' or not should be bounded in both pre and post indexing algorithms. To me the problem is obviously with 'indexing' that is where the problem is 'visible'.
There is also the original issue of this post - being able to Search in a particular Country and have those settings stick until reset by the user - as I mentioned in my reply above - there are at least two threads going on here. Setting Search> Records stickiness is typically not a problem - GEH9 has this problem. So I have also been trying to address that concern.
0 -
0
-
At least since five years I've already seen this problem of automatic location name fixing for source locations by FamilySearch. I think fast action is needed since most people in this world are not perfect genealogists and just copy into the tree what they see, even if it's wrong. So the incorrect locations are more and more spreading around, and the only way to correct them is one by one by someone who is aware of the errors.
The problem is how to bring all this into attention to FamilySearch. I tried this already for the last five years, but never got any satisfying answer. Since this forum seems to be a replacement for the regular feedback I really wonder if anybody who can fix the problem will take notice and action.
0 -
I am a volunteer, not an IT functionary. There are still two different topics being discussed here. 1: User location affecting results. 2: Placename being incorrectly indexed in records.
1: I've never noticed that results were being modified by the user's defined location. I take your word for it. Am I correct in interpreting the OPs request, that they want the Location field in the search facility to be populated by default with the user's location. Thus reminding the user that they are only getting results limited to that location. That seems to be both practical and sensible. As I say, I didn't think that the search was using the user's location even though the location field was empty. However ....
2: If the placename is incorrectly indexed, then it doesn't matter, you still won't locate the data unless you remove location from the search limits. Then you get so many results it is impractical to locate the item of interest.
In the past I have reported those cases of incorrect indexing that I have found. Support have been both courteous and quick to fix the problem. It really is a benefit to all of us that we identify such cases and report them. A peice of incorrect information n a database isn't just one fault, it's two. The wrong data is in the right place, but that also means that the right data is in not the right place. By not being in the right place search results fail and attachments cannot be made. Having the wrong data in the right place means false relationships and attachments are made which create a mess that can be real hard work to repair.
0 -
They are aware of it and apparently working on the problem. See: https://community.familysearch.org/en/discussion/102829/errors-in-indexed-record-updated-place-names#latest
0 -
To exemplify my case:
https://www.familysearch.org/ark:/61903/1:1:QL4J-DXCM?from=lynx1UIV8&treeref=LK1G-95M
Here one can see the original birthplace: Putten
without any further description
So FamilySearch somehow translated this (23 August 2017) into:
Putten, Noord-Holland, Nederland
instead of what should be:
Putten, Gelderland, Nederland
This is also clear from the citation showing Gelders Archief (the archive of Gelderland) as a contradiction to the wrong assumption of Noord-Brabant.
Of these cases there are several thousands comparable ones available. More over in Nederland or if you will the Netherlands I found more than 50 communities showing the same type of errors with each thousands of incorrect occurrences.
So to mention all these cases apart is too much, and if after at least 4 years nothing has been done to solve this problem the consequences will grow more and more everyday.
I remember the New FamilySearch disaster well and this will on the long run be a comparable problem disrupting the whole FamilyTree since this not only goes for the Netherlands.
So the solution will be as mentioned before: start all over naming the Locations and be sure to select the right ones, or take advice of people with local knowledge and allow these to alter incorrect citings.
0 -
just a volunter ....
I followed your trail and looked at that record. Now I can understand your frustration. It seems that the database has been through some sort of place-name rationalisation and as a result it has replaced the place name that would have applied at the time the record was created with the place name for the administrative region that applies now. This is not valid. For example: A town that was in say Czechoslovakia when somebody was born, would mean that the person was a Czech. If later that town became part of Germany, it would not mean that all people who had been born there in the past were born German. Clearly the place name for a given record should be the one that applied at the time. If the modern name for that place is different, then it should have a different field name, such as 'Present Place Name'. That might mean the techs need to use some sort of geographical reference for the actual place, and that will always be the same, but the present place name field will show the name of the place at that location even if it changes in the future.
0 -
By the way I meant Noord-Brabant instead of Noord-Holland which was error of my side
0 -
There is clearly a bug in the standarised place name handler I've just tried adding some new people using a census record where the place name is incorrect in the indexed record. When I type in the correct address, the Standardised Place drop-down allows me to select the place name I want, but then it writes the data from the entry that is one line below that into the person record. For each person I added from the census, I had to go the person record and change the birth place and residence place name to the correct one.
I foresee great disaster on the horizon !
0 -
pianoplayer13
Have you seen this post ?
0 -
Yes, working out my pretty long list with examples, will be there shortly
0 -
My listing is posted now at the forementioned post
0
