Please explain background updating of standard place-names in FSFT

LegacyUser

Adrian Bruce said: Ok - a full and complete explanation is no doubt utterly impossible but some sort of explanation of at least this example would be welcome...

Summary: I really, really want to know why my grandparents no longer have a standardised marriage place. Is it my incompetence or a software bug?

Detail: My grandparents John Griffiths (LDYH-JWM) and Gertrude Hannah Cooper (KGL8-MNC) have a marriage event of 29 September 1924 at (display place-name) "Nantwich Registry Office, Nantwich, Cheshire, England". There is currently a red exclamation mark against them both saying:

Missing Standardized Marriage Place
This couple does not have a standardized marriage place.

Now, I can look at the "All Changes" for them and see this


So - on 19 Feb, 2017, I attached the source for the marriage index, created the marriage event at "Nantwich, Cheshire, England", saved it, and then immediately updated this by "decorating" the display place-name by adding "Nantwich Registry Office" to the front. I know how I do things 99% of the time - I add a simple, standard place-name, save it, then decorate the display name. That means I have two chances to enter a standard place-name.

I simply cannot believe that I did not enter a standardized marriage place.

If anyone can check the actual updates and tell me I'm wrong, believe me I'd be perfectly happy but since "All Changes" shows only the display(?) name, I'm not hopeful anyone can do this.

My suggested explanations:
1. Despite my denials, my decorating the place-name with a prefix really did clear out the standard value.
or
2. At some point in the proceedings, a background run has attempted a standardisation; has failed to find a standard place-name for "Nantwich Registry Office, Nantwich, Cheshire, England" (possibly because there are multiple standard places called "Nantwich, Cheshire, England"?) and has left the standard place-name empty.

I have to say that I don't think much of my suggestion number 2 - I've never seen any suggestion that such background runs would actually remove standard place-names.

Can anyone explain?

LegacyUser

Juli said: I don't have specifics like Adrian's, but I've noticed the disappearance of formerly-fine standards all over the place. They've mostly been the christening place associated with an indexed baptism, and I know for absolutely certain that they used to have a standard chosen. I know this because the index-based placename is always a 20th century name and jurisidiction, which means that for any place that's now in Slovakia, the name and jurisdiction did not exist at the time of the event. Many times, I go back and change the placename on such entries, but sometimes I consciously choose not to, contenting myself instead with making sure that the standardization points to the right place. Now suddenly those standardizations are no longer there.

LegacyUser

Adrian Bruce said: Hmm. My cynicism is getting dialled up a level.

I tried looking at a couple of the Volunteer Project profiles suggested for me. There were some very detailed census residences that had no (i.e. empty) standardisation, and since the profile that I was looking at, had evidence of care taken over it (someone was watching it, which is a good start!) I dug around a bit. The residence that I looked at was marked up as being updated by FamilySearch in 2020. That surely has to be a background standardising run.

At that point I had a bright idea - the 2020 update was quite recent - what was on the Beta Site? The Beta site had odd update dates, suggesting that the Beta site had been used for bulk testing of background updates - which is part of what it's there for. However, that did mean that I couldn't see the pre-update value of this empty standardised place. I did try restoring the original value in Beta but that didn't work - not sure whether that's an effect of being in Beta or what. I am not going to try that in production.

So my bright idea didn't, in the end, tell me anything.

But, given that you've just been as certain as me, Juli, that these places were once standardised, I'm now beginning to revert to my previous conviction that these entries did have a correct standard place but have had it removed. And not by me or any human being...

LegacyUser

Paul said: There definitely seems to be a problem. Just browsing through my WRIGHTSON ancestors and found my 3x great-grandfather Stephen now has a number of "Data Problems" flagged. With the exception of the Death one (which I still believe I had standardised) they are all perfectly acceptable in the database. No way can I see I would have not standardised them properly at the time of input.

LegacyUser

Adrian Bruce said: I am an idiot... Removal of standard place-names is exactly what the recently publicised background run was intended to do. I even queried the Blog to understand it properly! See https://getsatisfaction.com/familysea... - specifically "In cases where a place listed in the Family Tree is not a location, FamilySearch will remove the attached standard, though the original text entry will remain."

But now what disturbs me is the scope of what it's picked up...

The detailed example had a display name of "Nantwich Registry Office, Nantwich, Cheshire, England" and a standard place-name (I believe) of "Nantwich, Cheshire, England". That is a standard name, though it isn't date appropriate because the date appropriate name is "Nantwich, Cheshire, England, United Kingdom."

So why has the background run decided that
Display = "Nantwich Registry Office, Nantwich, Cheshire, England"
and
Standard = "Nantwich, Cheshire, England"

is, in terms of this run, "Not a location"?

This could actually be an even bigger issue than I first thought...

LegacyUser

Cindy Hecker said: With the recent addition to the app to help Improve Place-Names, are the changes happening due to that? I did try the app Improve Place-Names and did not like it when presented with a place such as Franklin with no other information as to what state it may be in. I did not want to guess and I hope others would not but that part of the app could make lots of messes if it is changing what we enter into FamilySearch when we enter our information.

LegacyUser

Paul said: Okay, so they all should have a "United Kingdom" suffix, as they are post-1801 events, but that has never caused a problem in the past.

LegacyUser

Paul said: Following my previous post, why is there no problem with his son's vitals' entries?



In fact, in a several-generation landscape view, only one other individual is shown up with having the problem.

LegacyUser

Adrian Bruce said: Maybe only some have been done?

LegacyUser

Adrian Bruce said: Indeed.

LegacyUser

Adrian Bruce said: This is going to be seriously annoying if the "Not a location" criteria includes a check on the date.

1. I originally made a habit initially of choosing the "England" option for post-1801 places because, like many, though not all, UK genealogists I didn't add "United Kingdom" to the end of place-names. Still don't on my laptop.

2. Today I saw place-names in the list of Standard Places in Germany with wholly incorrect dates.

3. I do remember one of our correspondents on GetSat saying that she'd used "Utah Territory" in a date correct manner in FSFT but run into so many issues with submitting queries from FSFT that she'd reverted to date-incorrect "Utah" (i.e. the state but before statehood).

4. It's clear that there are people who haven't agreed with the concept of using contemporary place-names and are using today's place-names. Maybe they're wrong but they're also going to have a lot of work dumped on them.

Everything depends on why those places lost their standards.... It might not be a dating issue - but we don't know...

LegacyUser

Adrian Bruce said: I don't think this is the same issue - the app change is about adding place-names. At least, that's the theory!