Why are perfectly correctly inputted standard place names STILL being shown with a "Missing Standard
Someone in the team dealing with standard place names (sorry, perhaps in another department) is still allowing correctly standardized names to be shown as needing to be standardized (again).
This is causing me (and I'm sure many other users) wasted time in repeating this work. Will someone please stop this from happening? It was reported quite some time ago, but it seems someone (I'm sure with perfectly good intentions) is still not using the correct programming, thus triggering the "red flag" appearance. We know we have standardized these names properly in the first instance and could do without this unwanted use of our valuable time.
See https://www.familysearch.org/tree/pedigree/landscape/KJ56-B98 for one example of someone's tinkering that is causing this puzzling problem. Selecting the individual person pages (with red exclamation marks) will highlight the problem.
Answers
-
There is no one messing around. I have experienced the same. I am 100% certain that I had correct place standard and then the standard was gone and it had the red exclamation mark.
The reason for this is that there was on last May or June (sorry don't remember) a major update for standardized places and something in it went terrible wrong. In the update standardized places which were edited before that, were supposed to show the edited standardized place name in the Family Tree automatically. Instead those edited standardized place names were removed leaving no standard and that "red flag".
I looked your case. It seams that e.g. birth in 1809 has the place Thurton, Norfolk, England. Standard for that was changed to Thurton, Norfolk, England, United Kingdom
Here are standards for Thurton:
0 -
After that mess in update, every red exclamation needs to be corrected by hand.
0 -
Thank you for your responses, Heidi. I generally try to conform (in my inputs) with the standards displayed in the drop-down menus. So, say, for Thurton up to 1801 the standard is "Thurton, Norfolk, England". Otherwise it is "Thurton, Norfolk, England, United Kingdom". I was aware of that update being the probable cause, but the format adopted has never caused problems with standardizing - i.e. if one chooses the "wrong" one from the list (based on the date) there has never been a warning flag.
The main point I was raising here related to my suspicion that the problem is ongoing. I regularly check the branch to which I provided the link and do not remember seeing the data warning signs until today. I can accept nothing can be done by FamilySearch to turn back the clock - hence the necessity for users to manually "re-standardize" each one. However, I wanted to highlight the problem again to make sure there have not been (nor will be) any further actions by the engineers (post-May/June 2020) that will cause many more records to be affected in this manner.
0 -
I do not think that the red flag is because the wrong date.
I looked those places with red flags and last changes were done 2016 or earlier. I believe that when you chose the standard from drop-down, you chose "Thurton, Norfolk, England" and after that it was changed to "Thurton, Norfolk, England, United Kingdom". I do not know when the change was done and I really hope that it was done before the update. If the edit was done after that, it means that the problem is ongoing and then it is a big problem because places database is still under editing and it will cause a lot of red flags and unhappy people.
Yes, one of the engineers will need to look at it.
0 -
it can be because the actual standard place ID is no longer used (the standardized place was deleted and not connected with a new place ID).
0 -
🤷🏻♀️I dont know🤷🏻♀️ if this is helpful but I certainly understand your frustration. Why are there 2 boxes for place? Either way, I think as long as you put the place name in the first box, you then get a pop up in the second box that lists all the options for standardized places that match what you’ve entered in the first box. Please see my ss below. ☺️
0 -
posted a file. This shows only the first box filled out
0 -
0
-
posted a file. Adding second box info
0 -
Now there’s no ‼️
0 -
I usually go one step forward and make the date and the place display values the same as the standardized values. An easy way to do that is to change the display value by adding a space and then clicking on the popped-up standard version to quickly change the display version to the standard version.
0 -
@Paul W
.
Paul
.
MANY of mine are the SAME.
.
Especially, those from, England, Wales; and, Scotland.
.
Obviously, there have been, Releases/Updates; or, 'Passes' thru the "System"...
.
That "Marked" ALL those 'Places' in, England, Wales; and, Scotland, WITHOUT, the (TOTALLY "Unnecessary") SUFFIX of "United Kingdom"; as, "In Error", REGARDLESS, (ie. even) if they has been "Standardised", which in MANY of may cases they had. For me, PRIOR to "Standardisation", such we FINE; even, AFTER "Standardisation" was implemented, for many Years. And, even if they were BEFORE "Standardisation", they SHOULD have "Fitted" an applicable "Standard", all-be-it, WITHOUT, the (TOTALLY "Unnecessary") SUFFIX of "United Kingdom".
.
The aforementioned by 'FamilySearch' was just plain WRONG; and, should NOT have been allowed to occur.
.
'FamilySearch' SHOULD "Revert" ALL the instances where the aforementioned was applied, BACK to their PREVIOUS 'State'.
.
But ...
That said ...
.
It will NEVER happen.
.
Unfortunately ...
WE are just left to 'Clean up the [ Resultant ] MESS' ...
.
Brett
.
0 -
IIRC l have been assured that the "remove garbage and flag" routine does not do a check that the standard is date relevant.
The other point is that if you go to the Improve Place Names routine, there are no UK place names in the list because they have all been standardized again. Caveat - the list was a snapshot, so anything losing a standard after the IPN snapshot was taken, will not have been fixed. Which brings us to Paul's fear that the problem is ongoing.
My concern about trying to understand what's going on by looking at the Change Log, Heidi, is that I thought that standardisation (and presumably removal of standard names) did not show up in the Change Logs. I'm sure that has been said by analytical guys like Jeff W, so I'm not just making it up (though I could be misremembering!)
Whatever the answers, Paul's discovery of unfixed stuff (I've not looked at mine recently) is concerning, especially since we've seen no complete analysis of the source (s) of the problem (s). Heidi's comment about the update that went wrong is the closest I think we've got to confirmation of our suspicions. (Heidi - I don't imply that you are speaking on behalf of FS - rather that your work with place names puts you closer than some of us).
I'm writing this after breakfast and without the benefit of sources to cite, so corrections welcomed.
0 -
Jordi,
I do hope that you are not blowing away extra details that someone has labored over in making their place names more accurate. I've had to request many people to not do this because they were systematically walking through the families and throwing away very useful information simply in order to make the displayed value and the assigned standard value match exactly!
The dual name mechanism that FS has developed here is genius but was NOT intended to be used that way.
If I have entered a residence taken from a source that looks like:
"Lean-to behind the United Bank building at 1234 Black Street, Chillicothe, Ross, Ohio, United States"
it is obviously NOT a "Standard" location, but it HAS been standardized using the standard location of:
"Chillicothe, Ross, Ohio, United States"
It's a total nuisance when I have to go back through undoing someone's "improvements" where they have gone through and removed the extra details that I have collected and recorded (such as street addresses) in order to make the displayed place name exactly match a standard place name.
The red "!" is simply an indication that the displayed name has not had a standard name from the standards database linked to it (i.e., the displayed name has not been "standardized"). You "standardize" a displayed place name by just linking it to a standard place name from the database. Although you can do so, it is not necessary to make the displayed name value identical to a standard value. In fact, there are many times that doing so is totally incorrect.
0 -
A ways back when FS was running the tools to correct many standard names, something that happened was that many place names that were already CORRECTLY standardized had those associations broken. This is in spite of the fact that the standard name in the standards database HAD NOT CHANGED. Only it's link to the displayed name had been dropped.
I've seen MANY of these where the standard names had to be re-attached to the display names
0 -
Oh yeah I don't do that. If there are extra details that are important and useful and the rest of it can be standardized I usually highlight the extra, cut it, click on the standard, paste the extra and modify if needed. It is not necessary to make the displayed value and the standard value the same, but if they can be and still have the same amount of information, then you should.
0 -
You can see the standard values by hovering over the display values in changelog. Although if the standard place was deleted in FS Places database, I don't think it would show on the changelog, and programs run by FS to update standard values or whatever may not show on the changelog either.
0
