Has a bug led to place names that had already been standardised needing to be standardised again?

LegacyUser

Paul said: I have come across at least a couple of other examples of this problem recently, as shown below. Obviously, this can happen if one enters the place name, forgets to click on the standard place name option, then quickly move off the page. However, I am sure I had standardised this, as it is a page I check from time to time, so would have noticed the warning flag when returning to it previously.

I'll keep a watch for more examples, but am fairly convinced I have not been sloppy with my original input.

LegacyUser

Gordon Collett said: I've seen this, also. In fact, the place name for where my wife and I got married was suddenly not standardized. And I am absolutely certain that previously it was standardized just fine. I'm not sure but from some comments regarding the volunteer project to improve place names that was recently started, I have the impression that work to improve and clean up the standards database itself led to this.

This blog post: https://www.familysearch.org/blog/en/...
also talks about some clean up work in Family Tree that removed some place name standards but it only talks about place names that were not really place names. This was not the case certainly for my marriage place because when I re-standardized it, the displayed text was still identical to the standard, just as it was before.

So I don't really know if this was due to improvements in the Places standards database or due to improvements in Family Tree or whether the clean up work mentioned in the blog got over zealous in removing standards that didn't need to be removed and is another demonstration that automatic routines in Family Tree, that people occasionally plead for on this board to "clean up everything," are fraught with hazards.

LegacyUser

Tom Huber said: This goes back to when the profiles were imported into FamilySearch. I worked with the BYU standard places which, I believe, became what we have today and the standard list (and has since had a lot of additions).

I was irked by the fact that the standard from the BYU Labs was not recognized and I had to go through and set the standard all over again.

Look at the date last changed in the example. It is 2013. That was before FamilySearch had obtained the standard list. I asked repeatedly that FamilySearch recognize the BYU standard, since it matched the FamilySearch standard.

Eventually, just a year or so ago, FamilySearch finally ran a routine to set the standard if there was no ambiguity and there was a direct match with a standard. A lot of places were not set by that routine for one reason or another.

LegacyUser

FamilySearch Moderator said: Paul, engineering reports that they looked at the change log for John and Elizabeth and do not see where anything has changed with the standardized place name. They say it was created that way from the start. Perhaps another example?

LegacyUser

Gordon Collett said: I'm pretty sure that LHY7-R2B is one that had lost standardization for birth, christening, death and burial and I had to add all back in last week.

It's hard to be sure, because the change log does not show changes to standardization. But there is no other reason I would have done this:





And I can assure you that when I first worked on cleaning up this information in 2017, under my wife's account since this is her 3rd great-grandmother, I did not enter all four vitals without a standard! Ever since Family Tree opened in 2012 I have been tireless in trying to get people to understand and properly use standardization. I have just started seeing random people who have lost standardization in the past couple of months. On June 26 I went to my wife's fan chart and there were about five direct line ancestors like the above example that had lost standardization of place names and I fixed all of them.

Here are three examples I have not corrected yet.

https://www.familysearch.org/tree/per...
https://www.familysearch.org/tree/per...
https://www.familysearch.org/tree/per...

These are my wife's grandfather's three siblings. When I last left their records these were properly standardized.

Now all three look like this:



About every other year I go through my wife's entire watch list, which consists of her direct ancestors back ten generations, all their children, and all their children's spouses to look for incorrect changes and any problems. This usually takes a month or so. Looks like it is time to do this again and re-standardize everyone that needs it.

LegacyUser

Don M Thomas said: If he/she serves as Moderator fine. If he/she serves as a participant in this forum they should have a community name, and preferable their name in that he/she is showing an employee of FamilySearch.

LegacyUser

Paul said: FSM

Please refer to Gordon's examples, as I cannot find any other examples of my own at the moment.

However, as with Gordon, I would have definitely standardised anything for my ancestors, if there had been a warning flag.

Are you sure any action taken remotely would be recorded in the change log? I thought this contained a record of direct changes made by users, not items that were the subject of change by a piece of computer programming, as I believe this probably to be.

LegacyUser

Adrian Bruce said: I am as certain as I can be that I have lost standardised values for place-names. I set them up. The standards are no longer there. Basically, there is now no longer any doubt in my mind that I have lost them.

Paul, I believe that what's happened with your example at the top is that your Loughborough event is in 1830. The display name omits the "United Kingdom" and I would strongly suggest that you selected the standard place-name that terminated in "England".

Some background routine then came along, recognised that your standard was not date-appropriate, and removed it. If anyone is looking in the Change Log - well, I suspect that the Change Logs originally didn't capture background place-name changes. Not least because some people on this forum stated very loudly that they didn't want to know about background changes, only what users had done.

Now, here's where it gets really interesting - I had to go right back to my 3G-GM Elizabeth Low KHLY-ZFR to find someone with a missing standardized XXX place. I am pretty certain that only a few weeks ago, there were lots of my ancestors with a missing standardized XXX place. They have them now - date appropriate. It might be that the "Volunteer Opportunity - Help fix place-names" has fixed the "earlier" one - in which case, whoopee, thanks guys. Or???? Have further background runs taken place?

And before anyone asks - no, I did not set up Elizabeth Low with Birth and Christening both set to "Dundee, Angus, Scotland" for Display and nothing in the Standards. One I might. But not two. (Mind you, what I standardised it to, I can't guess. The debate there is whether it's Angus or Forfarshire).

LegacyUser

Adrian Bruce said: Several of us are convinced that we have standardized place-names and lost them - see below for my comments.

LegacyUser

Jeff Wiseman said: For what it's worth, I ran into this several days ago for some of my close ancestors (i.e. records that I have been watching for years). The locations were all marked as having "No Standard is Selected". But I know for a fact that these had all been set to exactly the same as the standard from the standards database years ago. Furthermore, they were a simple location (most of them Chillicothe, Ross, Ohio, United States). Since they are all spelled identical to the standard value that they were originally associated with, it is as if the association has just been deleted.

Since I knew that FS had been playing with improving those assignments both manually and programmatically, I just blew it off as yet another slip-up. So I have no notes on any PIDs that I could references since I have corrected everything that had mysteriously been broken.

LegacyUser

gasmodels said: I do not know for sure but I believe there was some auto exercise where some so called non-standard places were removed. Because they were removed the recent ask for help to standard places was undertaken. It may have been that places you thought were standardized had an unusual character or something like that which fit the removal category. Again I do not know this for a fact but am clearly guessing what may have happened. I believe I have also encountered the issue. I do not have any specific ID I can point to.

LegacyUser

Jeff Wiseman said: I suppose that's possible, but seems unlikely here. The same exact standard was assigned to HUNDREDS of events in my family lines (They didn't move around much). So if what you say is correct, then I should have seen far more data errors than I did.

LegacyUser

Adrian Bruce said: No, I can believe that somewhere I leaned on the keyboard at the wrong point but (a) you can only affect the display place name (surely?) by doing that and (b) there were way too many lost.

On the other hand, what I do know is that I standardized the missing names on a date inappropriate value. When I first started using the standard names, I was utterly opposed to terminating place names with "United Kingdom" so I chose the standard ending in "England" even for post 1801 events. I firmly believe that the background routines came along, detected these as incorrect names, because they were date inappropriate, and removed them.

I haven't seen any other explanation that makes sense, given the number of lost names and given what I am certain that I standardized them to in the first place.

I guess that there is another possibility - duplicate standard place names may have been removed where they made little sense - I'm thinking XXX parish and XXX village, where the XXX is identical and only the type changes. If one has been deleted from the standards, what happens to any profile using that as a standard?

But this still implies that a background run has taken place to remove them.

LegacyUser

Adrian Bruce said: NB - I feel that I should know what happens if a standard place name is removed, but it escapes me right now.

LegacyUser

Juli said: Dunno about employees, but volunteers with editing rights in the places database cannot simply remove places: we have to choose a place that the old choice will be redirected to.

LegacyUser

Adrian Bruce said: So that's sensible, thanks Juli.

I think I came up with that "deletion?" suggestion because I can see what went potentially wrong with my stuff - using a pre-1801 name for a post-1801 event. But I'd take a guess from what Jeff says, that an inappropriately dated name might not explain his issue. Hence I was trying to hypothesize some other potential cause for the loss.

LegacyUser

Adrian Bruce said: I honestly don't see how anyone could concoct any rules that said that certain types / categories of place-name had to be restricted to or excluded from certain event types - vital or otherwise.

Records of Poor Law Unions (for instance) contain vital records. Indexes for Civil Registration Districts clearly contain BMDs. Hundreds? (Which is a local government jurisdiction not a number in this context!) Less certain about that but I would defy anyone at FamilySearch to come up with a credible list of events that could not appear in records from Hundreds.

Now, of course the fact that it makes no sense to do such validation doesn't actually mean that there isn't any - just that I can't see any reason why anyone would spend their time writing that code!

If there is any processing that depends on the type / category of the place-name chosen, then we are sunk because there is no means so far as I can see to see what type is assigned to a place-name that appears on an event on a profile. I've just been trying some experiments in Beta and if I set a place-name to the Nantwich that is of the type "Hundred", and save it, then there is no way to see the type other than to enter "edit" mode. Even then I need to trigger the drop-down list and that always started in my experience with the most likely entry (the town) at the top - nothing told me that I'd previously chose the Hundred (or whatever).

So the type / category appears only while changing the value in edit mode, and I therefore really hope nothing depends on it.

LegacyUser

Gordon Collett said: I think we are seeing a random hiccup in what I hope was a one time processing or clean up routine. This thought is mainly based on the fact that wherever I have run into this, all four place names under Vitals have lost their standardized values, no matter how different those place are as you can see in the screen shot from Erling above.

A possibly connected question to why this has happened in Family Tree, is why has almost every place name lost its standardized value on the beta site?

Here's Erling in Family Tree:



Here's Erling in Beta Family Tree:



All of the red represents "No Standard Selected" for birth, christening, death, and burial.

LegacyUser

Paul said: I was about to comment that it appears all post-1800 events for England have now been standardised to "England, United, Kingdom" by some sort of FamilySearch programming exercise. I checked numerous places with a display name of "...,England" and they all had been standardised with the "United Kingdom" suffix - and I'm sure not by me.

However, "one more" random check produced the below. A post-1800 event date that is still accepted as standardised by the system without the added "United Kingdom". There's another theory that goes out of the window!

Every random check on post-1800 events produced something like this:


But at last I found an exception:


I'm convinced, during the period I made these inputs, I was standardising everything with the "Helmsley, Yorkshire, England" format, regardless of year. Very strange.

LegacyUser

Adrian Bruce said: You get a gold star for finding that 1830 "England" entry!

Like you, I am convinced that I was originally standardizing on entries ending in "England" and while I now use "England, United Kingdom" for post-1801 entries, I'm also totally convinced that I've never gone back to "correct" things to "England, United Kingdom" for my original post-1801 entries. And yet, large numbers of them are correct - I'm not going to say "all" because I've not tried to get any impression about coverage.

LegacyUser

joe martel said: Beta is always suspect and I know it won't always mimic what is happening in the main production tree. Could you list some PIDs that you believe have lost the standardization? I'd be curious to see if this has something to do with patrons, automated clean-up process, or the volunteer process. thanks

LegacyUser

Adrian Bruce said: I hadn't realised until today just how bad the entries are on Beta re standard place-names. I say "bad" as shorthand for not-standardised and I know full well that FS are liable to alter things during their testing - that's not a problem as I do it myself - any change log for my granddad in Beta would show him in various places across the globe whereas in real life (WW1 excepted) he never left England.

This clearly suggests some extensive testing has been going on in Beta re standard place-names, which I would think suggests some extensive work will be / has been done in the same area in production. So I do wonder, like you, Gordon, whether we are seeing something from background tasks. Especially if people get a gut feeling that things look better now.

(I think I'd prefer "transient effects" rather than "random hiccups" - I think stuff does take some time to happen in FSFT, so we could be seeing temporary states)

LegacyUser

Adrian Bruce said: PS - thank you again, Gordon - I've just worked out how to get the Fan Chart to show data problems like your red Beta does. Previously I'd been scuttling up and down a tree looking for red icons. Much faster and easier to see things in the Fan Chart.

LegacyUser

Paul said: Two IDs I can find where standardisation has been lost are L6HF-4WC and M3T9-VVS. Thanks, Joe.

If interested, could also provide examples where the standard is still valid, but changed from what had been the originally standardised location (i.e. where "United Kingdom" now appears at the end of the place name, when wasn't there previously) and the one (illustrated above) that has retained its original format (still ending with "England").

LegacyUser

Gordon Collett said: The three I listed above are:
https://www.familysearch.org/tree/per...
https://www.familysearch.org/tree/per...
https://www.familysearch.org/tree/per...

The user name will show as my wife because we work in her account when working on her family. These were originally standardized properly.

LegacyUser

joe martel said: Gordon, those urls got truncated.

LegacyUser

joe martel said: Paul, those are for the marriage events rights? And you think that last one got changed to be non-standardized sometime after your change in december?

LegacyUser

Gordon Collett said: Tried to just copy and past from above. Here are the full URLs:

https://www.familysearch.org/tree/per...
https://www.familysearch.org/tree/per...
https://www.familysearch.org/tree/per...

LegacyUser

Paul said: Joe

Yes, I believe that to be the case. No hard evidence, but seems same problem as with my original post. Can only suspect some automated process, but only speculation.

LegacyUser

Richard Otter said: Many of my entries had standardized place entries but about six months ago, the standard place names were changed and that caused all of my entries to be no longer considered standard. Quite annoying as it affected about 5000 entered data items.

LegacyUser

Jeff Wiseman said: Richard, were the actual values of the standard places in the standards data modified? Or are all of those standard places in the database that you used still there with all the same spelling but were just "detached" from the display names that had been standardized with them?

The latter is what I observed. I can go into all those display names and just re-link the same standard place from the database that I had link to it before, since it is still in the standards database, and it is spelled the same as the display name I had used.

You sound like you are describing a situation where Standard place names in the standard places database that were MODIFIED and thus disconnected from the display name that was in the vitals.