full place names carried into searches

LegacyUser

Donald Allen Soper said: Place names in a person’s record and place names in the (family) search records.

Eliza May Soper gqcc--hzf
Birth 1894 Horsham, Sussex, England, United Kingdom
Death 23 Jan 1947

If you do a search for records, that screen shows her birthplace as ‘England, United Kingdom’.

That search give records that possibly belong to her spread over two pages.
Three on the first page, three on the second page

If you change ‘England, United Kingdom’ to ‘Horsham, Sussex, England, United Kingdom’ then seven hits are found on the first page for her and they are one after another from the top of page. One of the hits is found with her middle name different.
Shouldn’t the full birthplace from the person’s record be carried over to the search for records screen?

LegacyUser

Tom Huber said: Welcome back to the community support forum for FamilySearch. FamilySearch personnel read every discussion thread and may or may not respond as their time permits. We all share an active interest in using the resources of this site and as users, we have various levels of knowledge and experience and do our best to help each other with concerns, issues, and/or questions.

You did not mention how you start your search -- whether it was from the Search... Historical records, or from the FamilySearch icon on a person's details page. Given your concern, I suspect it was the latter.

What happens is that FamilySearch, when you start from a person's details page and press FamilySearch under Search Records;

is that setting up the search works on the idea that in computer searches, too much information can result in no results, so a certain number of places has been established for searching from that link.

You'll need to do exactly what you did. Keep in mind that the more information you have for search parameters, the fewer the results are going to be. But, in order to not miss finding something, you often need to start with minimal information and add parameters as needed to narrow the search results.

There are other ways to narrow the results, including filtering by collection, by place, and so on.

LegacyUser

David Newton said: Those default search parameters are almost worthless for anything but rare surnames. Familysearch have repeatedly been told and told and told and told that those default search parameters are almost worthless for anything but rare surnames. Yet they persist in using those default search parameters for the main website.

Why do I not use the main Familysearch website for record searches now? Those default search parameters and because I have an alternative available which actually does precisely what the OP wants: the Familysearch Android app. It has proper default search parameters, taking the full place name across into the search. Result? Vastly more useful default search results. Considerably less time wasted altering the default search parameters every, single time a search is run. I certainly still have to alter the default search parameters on occasion to find records, but it is not virtually every single time I run a search.

This is NOT a problem with the search engine. This IS a problem with the default search parameters. It is an easy problem to fix and would have a large positive impact if fixed. Therefore it should be an extremely high priority to fix. There are problems with the search engine, but this is not one of them.

The OP is correct and the development team have not covered themselves in glory by refusing to deal with this issue.

LegacyUser

Lundgren said: Thank you for your input on this topic. I replied to the other thread in more detail. Here I just wanted to note that different records provide different levels of detail on where a person was born.

Extremely detailed places will cause records that only contain general places to be excluded. Adding a birth location that contains city, county, state, country may preclude records that do not contain that place.

Consider this tree person:
https://www.familysearch.org/tree/per...

This is her SSDI record:
https://www.familysearch.org/ark:/619...

If you search for that person with her first and last names exactly as they are on the record with her correct birth place and year, filtered to correct collection:

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

You will not find the record.

That is because the birth location Tenn, USA is not on the record. (It standardized that out to the correct Tennessee, United States, changing that doesn't make a difference.)

9+ Years ago, the system was modified to not return records that do not include records that do not birth supplied in the search.

In this case, don't return records that don't match a birth place of Tennessee, USA, records without a birthplace can be returned.

That feature was added based on user requests and complaints of records from the wrong countries being returned. (Or so I was told, as it was done before I started working for familysearch.)

If you remove the birthplace of Tenn from the search, and use only USA:

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

Then the first record returned is the correct one. That is because this entire collection comes from the US, and this record is no longer precluded because it does not contain more detailed birth information than the record.

This is just one (personally irritating to me) sample of a record where including more detailed places in a search causes a record not to be returned.

Providing a more general place will allow more specific places to be returned. That usually makes it a better place to start than a more narrow place, as frequently records, or indexes, will not have the more specific place.

The level of detail provided from a tree search was intentional because of this feature. For consistency, all of the familysearch tools should use the same levels when sending searches from tree to records.

Thank you again for your input, hopefully this will help.

LegacyUser

Paul said: Donald

This used to work just fine but unfortunately the engineers tinkered about with things and the specific place name was no longer carried across.

It appears from David's comments that the Android app works much better. Sadly for those of us with primitive phones and reliant on our PCs, development is prioritised to the mobile phone user area.

LegacyUser

Adrian Bruce said: Lundgren - I am sorry but this issue of truncated place-names is causing continued grief and frustration for anyone submitting a search from FS FamilyTree into Historical Records where the UK is involved. And not just the UK, but, IIRC, Germany as well (it searches on "Prussia, Germany", for instance - never mind if the province in Prussia was quoted).

FSFT knows that the person was born in "Horsham, Sussex, England, United Kingdom". When submitting it as a search into Historical Records, a search with a birth-place of "England, United Kingdom" is valueless. It doesn't even prioritise Horsham because it's not there. There is no point in the search because the person is not going to be visible in the answers except by purest chance or a rare name.

You refer to research done by FS before your arrival - how about the complaints FS have had since the truncation from people trying to search the UK? What research has FamilySearch done there? (Please note that I have tried to type further sentences at this point and given up because they're all sarcastic and / or plain rude).

The only way anyone can use UK based searching is to immediately alter the parameters, making FS's attempts at a consistent experience absurd since the first thing we do is discard the experience.

The principle appears to be "For consistency, all of the familysearch tools should use the same levels when sending searches from tree to records." I agree - that level should be what is on the profile in the tree and the system should start from there.

FamilySearch will continue to get flack from UK genealogists while it persists with this absurdity.

LegacyUser

Adrian Bruce said: I am having difficulty with the analysis of Joy Hodges in the SSDI.

The principle is "don't return records that don't match a birth place of Tennessee, USA. [I added a full stop here, correctly I hope. AB] Records without a birthplace can be returned." (This seems perfectly sensible).

Firstly, why are 254 records returned at all when the search uses a birthplace of "Tenn, USA"? The SSDI, as I recollect, does not have a birthplace on at all and won't therefore have birthplaces of "Tenn, USA".

Logically, therefore, no records on the SSDI will match a birth place of Tennessee, USA so none should be returned unless they are without a birthplace. This would suggest that the 254 returned are all without a birthplace - and therefore the others have a birthplace which isn't Tenn, USA.

Now consider the search using a birthplace of "USA". 1,061 records are returned. But under what criteria? We have already established that only 254 are without a birthplace - so it seems to me that the 807 new ones must have a matching birthplace of USA. Yet, as I said, my understanding is that the SSDI does not have a birthplace, not even USA...

So, confused I am. (I am fairly certain that the US SS system as a whole does have details of birth-place within it - my GG aunt's application had her Scottish birthplace on it - but I can't find instances of SSDI records with birthplace at any level.)

This matters not because I'm trying to catch anyone out but because if I am to suggest any alternatives, I need to understand what's on the files.

LegacyUser

Adrian Bruce said: I'm even more confused now...

I just repeated the search with a birthplace of "Memphis, Shelby, tennessee, united states" - it gives 210 results.

Then with a birthplace of "Shelby, tennessee, united states" - it still gives 210 results.

Now with a birthplace of "Tennessee, united states" - it gives the above 254 results.

I cannot understand why, given the criteria of "don't return records that don't match a birth place of Tennessee, USA. Records without a birthplace can be returned", we suddenly have 44 extra records - won't these 44 have something different about their birthplace? But what????? Surely they can't be birthplace TN? I may be missing something in my analysis - or there's something odd going on in the search engine.... Which is worrying.

LegacyUser

Lundgren said: The search engine also tries to further find records based on the search parameters provided.

It will search in additional fields beyond the birth field.

In this case, all of the records returned from the search with Tenn, USA, contain information about Tennessee, or just the US. (They are death places in this case.)

We are going back through the search functionality and will be evaluating these features.

For now, this is the way it works.

LegacyUser

David Newton said: Unfortunately that particular example does NOT support your case for truncating the place names. I took the liberty of properly standardising the place name for the birth place to give a true comparison.

So Android app has search parameters of Joy Louise Tippitt Memphis, Shelby, Tennessee, United States 1927 1931. Main website has search parameters of Joy Louise Tippitt 'Tennessee, United States' 1927 1931 'Colorado, United States' 2005 2009.

There we can see the different default search parameters. One truncates the birth place, together with adding a truncated death place.

The profile has 5 sources attached to it: 1930 census, California marriage record, California divorce record, US public records entry and SSDI entry. How many of those sources do the default parameters from the Android app and the main website return? One in both cases: the 1930 census entry as the first result in both cases. So far as I can see none of the other sources are returned on the first page of the results.

Turning to the SSDI which set of default parameters produces the most SSDI results? Main website produces 0 SSDI result hits. Android app produces 12 SSDI result hits. None are the correct SSDI entry. Why? Absolutely nothing to do with the place name truncation. Everything to do with the name search parameters. Both main website and Android app produce default search parameters of Joy Louise Tippitt. That will never find anything under Joy Louise Hodges.

Change the searched named to Joy Louise Hodges in both cases and leave all other parameters alone and how many SSDI hits are there? 4 for the website and 108 for the Android app. In neither case does the correct SSDI entry appear.

What's the easiest way to get the SSDI result to show up? Search in the Android app. Filter to SSDI only. Change the surname. Delete the birth entry entirely. Ping! Correct entry shows up as fourth SSDI result. Do the same on the main site? Correct entry is first SSDI result. Difference? Place of death.

So on default search parameters it's a score draw. Both produce one useful result and then a load of rubbish. The problem for the search engine is that for datasets that don't actually have a place of birth and do have a date if birth, GRO death index for example, the system is still confining the death place search by the birth place geography if no death place is entered into the search. In the example's case it is searching for deaths in Tennessee in the mobile app and knows nothing about Colorado or California.

Finally I experimented with the search parameters in the Android app as Joy Louise Hughes Memphis, Shelby, Tennessee, United States 1927 1931 Elizabeth, Elbert, Colorado, United States 2005 2009. Top result? Correct SSDI entry.

So actually those results would not only seem to not support your contention, but actually directly contradict it.

LegacyUser

David Newton said: There may be a way out of your dilemma: Bluestacks. Never used it myself, but it's an Android emulator for Windows.

LegacyUser

Lundgren said: When I began the search for that record in 2013, I did not know when or where she died.

The example I provided matched the search that I did back then.

Adding her birth location to the search prevented me from finding the SSDI record.

Eventually I did find the death location and her death record.

Once I found the record I created a bug report for the search system that it was excluding this result. I then learned that this was a feature that was added.

The search you ran contains the death location which I discovered later.

I provided this example to illustrate that providing detailed locations can cause records to be excluded from results.

If you are doing research to locate information you do not know, then using specific locations can cause records you are interested in to be excluded.

Each case is different. When the research was done, they took many cases into account and decided which parameters and values should be passed to the search UI as a starting place.

The website is passing the values that research recommended.

LegacyUser

David Newton said: The default search parameters are actually irrelevant to the original SSDI search. As I have demonstrated in this case they both produce results of approximately the same value. Both produce the same relevant record at the same rank: 1930 census at first result. Score draw.

However my own experience of the system would suggest very much otherwise than the contention of the research section (and since I personally created 1/10000th of all new profiles in the system last year and personally attached 1/5000th of all new sources in the system last year I think I can actually speak from something rather more statistical than anecdotal when compared to the average user). In my use of the system I have almost uniformly found that the Android app's default search parameters are more useful than the main website's parameters. That is true of American records just as much as it is true of UK records.

I also directly proved that your contention is incorrect. Inputting the full death location details produced a useful and correct result. Inputting the truncated death details produced no useful results. Trauncation HARMED the search result accuracy which is the opposite of your contention.

What I am describing and what the OP is describing is a fault with the search parameters from the main website. Easily fixed.

What you are describing on the other hand is a fault with the search algorithm in the main search engine. Not easily fixed. The search algorithm restricts non-birth location geography to the geography of the birth location where no death or marriage information is entered. That's dreadful. That's a completely unwarranted assumption, particularly in the modern world. Should locations close to the birth location be given more weight? Certainly. Should locations away from the birth location be excluded completely? Absolutely not.

If I have a name and birth date match to the GRO death index then that match should show up high in the search results regardless of birth geography. That GRO death index does not have any birth location information at all, just date of birth from 1969 and age from 1866 to 1968. Any search algorithm which fails to display such a GRO index match is defective. The FSFT search algorithm fails in such a manner when any geographical information is inputted into the birth place search whilst the death place search is left blank. Therefore the FSFT search algorithm is defective.

I'm not claiming fixing the search engine defect is easy. I know it likely isn't. I am claiming that fixing the default search parameter issue is easy. I know it is given what it is.

LegacyUser

Lundgren said: The search functionality that tries to increase recall by expanding search beyond the original query was developed years ago.

I see you are not happy with the idea that the search engine is doing things behind the scenes that you didn't request.

The search system today does not have the flexibility to allow users to have complete control.

Many users want less control than what is offered today and feel overwhelmed by the number of fields and options presented.

To some of us, being able to tune the importance of every search field and it's impact on the search results is appealing. To other users, they would like the search system to work like a single field search and just go find everything for them.

What we have today is a compromise between the two. We are working on improving what is available for both types of users.

LegacyUser

Adrian Bruce said: Lundgren, I appreciate your efforts to explain what's going on and why.

The essential problem for UK users with truncation springs from the concept of "just go find everything for them". They / we do get everything - everything from across the whole of England. The output is just not useful. If the place name is standardized to exclude the United Kingdom bit - which is incorrect for post 1801 - then the truncation searches across an entire county, which may be useful unless you're looking for Smith in Yorkshire.

It's not just a matter of our procedural preference - it's that dumping that many responses on us results in a response that is useless. It's not prioritised by place because the place doesn't even go into the search parameters.

The frustrating part is that when I do direct searching of the Historical Records, with the full place name, it will do exactly what we want - exactly matching place at the top if there is one, partial matches below. So even if the baptism birthplace mismatched the census birthplaces (quite likely in my experience) I still get several choices, including the right one - assuming that the place name mismatch isn't too big. This is my point - FSHR search of things like UK censuses does exactly what we ALL want, already, without truncation.

LegacyUser

Paul said: Thanks.

LegacyUser

Adrian Bruce said: I spelt "flak" wrong... How annoying to (a) do so and (b) notice it!

LegacyUser

David Newton said: So what's more important for default search results? Number of hits or accuracy of hits?

Familysearch and by extension Lundgren seem to believe volume of results is most important. Adrian and I on the other hand believe (correctly) that accuracy of results is most important. 8 in the top 20 v 3 in the top 20 accurate results. 3 in the top 20 v 1 in the top 20. In one non-truncated search results just over twice as useful and in the other three times as useful. This is typical behaviour. Compare that with the score draw (atypical behaviour) above.

LegacyUser

Jeff Wiseman said: David, I'm not really sure of the answer, but all of this digital searching is using indexed data. There are reams of mistakes in index files, so it seems that in order to make sure you've gotten as many of the actual records (i.e., the ones that may actually apply to the name you are searching for), you would need a "looser", or "less precise" search to return a set of records for your starting point.

If all index data had been copied correctly from the originals, and all of the originals were recorded exactly and accurately as they should have been, then a "precise" search such as the one you are talking about would be fine. But we are searching in a database of indexes and originals that are FAR from accurate in many cases.

So it just seems that a highly accurate and precise search would be counter-productive in this environment. I suspect that some kind of custom balance between accuracy and "Loose" matches is needed. I can only assume that that is why we are encouraged to use a loose set of search data, and then refine that search with the filters.

Finding that balance is obviously an art form that I haven't mastered, especially with the search algorithms changing frequently and being tweaked all the time.

LegacyUser

Adrian Bruce said: My thought there Jeff is that the supposedly "precise" search returns so many that it's a reasonable expectation that the "precise" search will cover most of the errors in indexes (and originals!). If I'm looking for census records for G-GF William Taylor, the looser result set of 5046 is just - useless. In fact, the tighter result set contains 977 which is still actually impractical to look through.

That's what I really, really don't understand about the "one button to get it all" brigade - absolutely no-one is going to look through a full result set. Well, not unless your relative's name is Theophilus P Wildebeest.

If stuff doesn't turn up in the first few screens of the "precise" results set then I'd start doing searches specific to a collection, rather than trying to widen my search parameters. Now that sort of thing isn't simple and I intuitively suspect to be beyond the people who can only use "one button to get it all" - I'd be restricting to specific collections while derestricting other aspects, and then potentially adding in extra items like parents while removing surnames... This sort of strategy is not easy to explain but at no time would I be opening up my search to look at the whole of England instead of a subdivision of it.

Yes, finding a balance is important, as you say. But crippling our searches to be just to England instead of a county (say) is leaning on that balance and saying, "What, useless answera? Can't imagine why..." (Proportionally I suspect it's like denying USA genealogists the ability to search by state and saying "East or West of the Mississippi?" )

LegacyUser

David Newton said: "If stuff doesn't turn up in the first few screens of the "precise" results set then I'd start doing searches specific to a collection, rather than trying to widen my search parameters."

Yep. When you get to modifying the default search parameters you are already into an area that is beyond the ken of many users. Hence the fact that the default search parameters need to produce the most useful set of records possible. Hence my disdain for the truncation of the place names which as I have shown and Adrian has shown produces less useful sets of results.

LegacyUser

Lundgren said: What you are describing is called precision and recall. There is quite a bit of research on the topic.

We are trying to strike a balance between the two. Because of this, the top two jurisdiction levels are passed. If recall was the only desire, no places or dates would be passed and the entire world would be returned.

i understand your desire to have maximum precision. In the cases you describe, where you have all the information for a persons life this level of precision may return the exact results you want. There may also exist a record in a place that you don't have knowledge of that you will miss.

None of the rest of this post speaks to your desire for maximum precision. I'm not trying to say you are right or wrong. It is just information.

A bit more info on why the whole of England is being passed instead of a more meaningful third level jurisdiction:

The system currently uses the top two levels jurisdiction levels. That does not work well for cases where the top two levels are very broad like:

England, United kingdom.

In other parts of the world, the top two levels get the desired behavior:
Coahuila, México
Kalmar, Sweden
Ontario, Canada
Colorado, United States

Going three levels deep would increase the precision and improve the experience for England, a search could become:
Chesire, England, United Kingdom.

But for counties not requiring three levels, adding a third level would sacrifice more recall than what we wanted based on the research.

For the United States, that would mean narrowing the searches down to the county level. (I.e; Arapahoe, Colorado, United States) If you know the county before you search for the record, then you may find it.

My experience is that many people in the US do not even know the county they were born, let alone the county their grandparents were born. We generally do not use the county when identifying where we are from or where we live.

There are many ways that places are defined in the world. Going for maximum precision (including the use of exact) has value. Going for maximum recall also has value.

This feature (search button) that we are discussing was added as a nice to have option. When it was initially added, it did not use date ranges and did not charge the jurisdiction levels at all. After some research the decision was made to increase recall by using date ranges and modifying the places, at the expense of precision.

We are aware of the problem that this is creating for England, United Kingdom.

Familysearch needs to find a solution that will work well for the situations above as well as others not considered in this thread.

What is being done today does not work well for England, United Kingdom, or other places that have very broad second level jurisdictions.

I'm also very much in favor of giving experienced users more control of the searches. We have to create that in a way that doesn't scare off inexperienced users who don't understand what all those buttons do.

Experienced users might love it if they could sit down in the cockpit of a jet liner. Inexperienced users would just leave though. We are trying to work on solutions for both going forward.

LegacyUser

Adrian Bruce said: Lundgren - two-ish things.

Firstly, the way that the FS Historical Records search appears to work, there is still a massive amount of recalled data when searching with maximum location precision. In fact, I'd suggest that even with that maximum location precision, there's too much data returned - at least in my examples. So to me, the default settings with full place names but no exact match markers set, are actually tending to imprecision.
Caveat - I have no idea what the results would look like if I set the location names to exact.
Caveat 2 - I have no idea what the results would be if a similar test were run on, say, US data.
Caveat 3 - your SSDI example is a counter example to my suggestion of putting everything in, but it seems to me that there is something decidedly odd about the results returned there.

For clarity - I do totally accept the idea of a trade off between precision and recall.

Second point - so far as I recollect, your comment in the final sentence accepting that the logic doesn't work well for places that have broad second level jurisdictions, is the first time that I remember seeing an acknowledgement from FS that UK searching has problems. Thank you for that - I had feared that we simply weren't getting through. And no, I won't take that as an official promise. Been there, done that myself.

LegacyUser

David Newton said: The problem with the precision and recall point for the US is that there are also enough areas of the US which are plenty big enough to have the same problem as the UK. California. Texas. Florida. New York. All of those areas would very much show the same kind of problem that occurs with the UK when searching at the England level. Heck even within England there is London which is big enough by itself to show much the same problem at the next jurisdiction level lower!

What I would suggest is that a database-by-database approach for precision might be required. Each database being assessed and assigned a coefficient based on what jurisdiction level to treat things at. So for US federal censuses it would be 2 as you rightly say that in those transcriptions things are at the state level for births within the US. However with UK censuses it would be at 4 because we often have birth information down to the village or even the hamlet recorded in those censuses. Big concern for that would of course be server load. You might even have 0 level databases such as the GRO death index which has a birth date after 1968 but never has any birth location information at all and so is pointless searching with any birth location.

From a systems architecture point of view there could be a considerable degree of parallelism possible with a query structured using a jurisdiction coefficient. In other words run searches on the 0, 1, 2, 3 and 4 level databases independently at the same time and then synthesise the results together so that from the point of view of the user things are seamless. One other thing to consider is that different parts of the query might have different jurisdiction coefficients. So taking the example of the GRO death indices, the birth date information would have a 0 since as indicated above entries in the index have no location at all, whereas for the death information itself it would be a jurisdiction coefficient of 3 since it has death information down to the registration district level which is at a level below the England and Wales legal jurisdiction.

For an awful lot of profiles even using the full four levels of information produces an overwhelming number of hits in a lot of cases. I have also seen plenty of cases where a full four levels of information produces hits which are at a much higher level. For example the default Android client search for MNW3-2Z1 which I am working on at the moment produces 148 hits, of which the first six are all applicable to that person. After that it very much gets a lot wider, a lot quicker. Hit number seven for example is the Canada Passenger Lists 1881-1922 database with a birthplace of "Eng", hit number eight is the England and Wales, National Index of Wills and Administrations 1858-1957 which has no birth data at all and hit number nine is Massachusetts Deaths 1841-1915 with birth information of 1841 England, and a complete wrong name! The default website search information comes in at 5,300 hits. Five of the six correct hits are also present with this search at hits 2, 3, 4, 6 and 7. The missing one is is marriage registration index hit. Said marriage registration hit is in those search results, just at hit 10 when restricting things to the marriage registration index alone.

My first priority when dealing with this system is to improve the search result quality of the top hits it produces with the unaltered default parameters. Go beyond those top hits and it is extremely unlikely that anyone will wade through the hits. Narrow the databases searched and it is extremely unlikely that the novice user will undertake that task. Alter the default search parameters at all in any way and it is extremely unlikely that the novice user will undertake that task.

I do all of those things, and I also go in and conduct searches where I define all of the parameters when I am being systematic and link… [truncated]

LegacyUser

Lundgren said: Your solution would also need to handle the density of results in a place change over time. The concentration of people in New York State in 1700 is very different than 1900. Likewise large numbers of Europeans emmagrated to the new world causing possible stagnation or contractions.

Additionally the density of records that familysearch has for a place in a time can change significantly over just a few days as collections are added. (Or a collection owner requests the removal of data.)

We are not working on a system to dynamically modify the jurisdiction level used in place values based on record and population density like the one you are proposing.

LegacyUser

Lundgren said: It is also worth noting that search is generally considered a tool that is used to find information when the hinting system does not find the records already.

The hinting engine compares all of the data for every person in the tree against all of the records we have and scores the likelihood that they are a match. It's results are presented on the tree as hints. Each time a tree person is updated it is revaluated against the records to find possible matches.

That is a totally different system from the search system. It is a machine learning based system that users do not directly interact with. It finds a great number of the records for the users. That system is evolving as well and has different criteria as well as precision and recall settings that are not visible to users.

LegacyUser

Christine said: If we all agree that the United Kingdom (required standardization) throws off the search for many of those records in England, then why do we have to add United Kingdom? Why can't we just list Bulwell, Nottinghamshire, England?

LegacyUser

Brett said: Christine

Many of us agree; and, would love "FamilySearch" to 'ditch' the "United Kingdom" altogether as a "Search" Level.

Personally, I would prefer that the "Search" Levels started from 'left to right' (smallest to biggest) as entered, rather than 'Top Down' (biggest to smallest).

Brett

.

LegacyUser

Adrian Bruce said: Christine - my heart says that the country is indeed England, not the UK. My head is less sure. And the issue is, I believe, wider than the UK. Searches in German families will get truncated to the last 2 nodes. If your target lived in "Hamburg, Germany", which was an independent, city state, the search launched will be based on Hamburg - very tight.

If your target lived in "Prussia, Germany" then the search will be based on Prussia, which was proportionately a very big part of Germany - the way too wide approach. I doubt that anyone would seriously suggest discarding "Germany" as an entity. If they did, the smaller Duchies, etc, would become a puzzle to most of us.

So, yes, my heart might want to discard the "UK" but my head says that worse problems arise if other union nations followed suit.

LegacyUser

David Newton said: "I doubt that anyone would seriously suggest discarding "Germany" as an entity."

Pre-1871? I certainly would. No such political entity existed prior to 1871 and so no such entity should be part of the standard place names prior to that date. I will certainly agree that the German petty states can get really confusing. Saxe-Coburg was a pretty egregious example of that. If the petty states are a mystery I say good! Encourages people to either go and do some research if they are properly dealing with the subject or it encourages them to go away and stop bothering us if they're just a fair weather genealogist. Either outcome is positive as we either get someone increasing their knowledge or we get less junk input into family trees.

LegacyUser

Paul said: Lundgren

As 90% of my research relates to England, my selfish instincts tell me (as already suggested) just simply remove the "United Kingdom" bit for the search routines straightaway. This will help the thousands of users who confront this avoidable issue every day.

Obviously, there needs to be a solution relating to countries (e.g. Germany) where the solution is not quite so clear but, hopefully, these too can be dealt with in time.

As a general point, for all its faults, I much prefer carrying out searches within FS than in Find My Past and Ancestry. I work with FMP quite a lot and here there only seems to be prioritising of results (even when checking "exact match" boxes) and I hate the "+/- 10 years, etc." option, as opposed to entering my preferred rage of years (say 1814-1827), as I can in FS. With FS I find I CAN often get down to a handful of results, so I'm relatively happy about the search engine. Just exasperated. like others, that just a little tweaking isn't taking place to help in dealing with the main topic being discussed.