Bug Report: Place Standardization
The place standardization routine will not let me correctly link the custom place name to the proper standard in the following situation:
The routine needs to include the parent place "Ogden, Weber, Utah, United States" as an options in the drop down menu.
Answers
-
The Ogden Standard is not actually a place. It is the name of a newspaper and should not actually be added to the place.
The place Ogden, Weber, Utah, United States does exist in the locations database. If you type in just Ogden, Weber, it will pull up the town of Ogden. If you really want the newspaper name to be included (say a person lived in an apartment above the The Ogden Standard newspaper offices) you can type in the address and select that as the text.
0 -
But it can be, just like an address, a school name, a hospital or any other additional information that adds value to the entry. That is the entire purpose of the date and place name dual entry system that makes Family Tree such a great program. It works correctly for the Salt Lake Tribune:
The standardization program should be consistent in how it handles this additional information. Why does The Ogden Standard incorrectly insist the only name to link to is the Ogden Temple while Salt Lake Tribune does not even suggest the Salt Lake Temple?
2 -
By the way, how and why did this get moved to Search? I'm sure I posted it under General since I hardly ever go to the Search section and this has nothing to do with Searching. It's a simple bug report for general data entry in multiple places including working in Family Tree, the index editor, the Source Linker, the Places database and others.
1 -
@Gordon Collett Most likely the thread was moved here because Search is where errors in place standardization are reported.
People are born and die in hospitals, but what event takes place in a newspaper office?
0 -
@Gordon Collett It isn't anything to do with the Ogden Standard or the Salt Lake Tribune, it is the algorithm that is trying to find a standard location that most closely matches the information that you have typed. In these two examples, for the Ogden Standard, the closest thing that the system could find was the Ogden Temple. For the Salt Lake Tribune, the closest thing that the system could find was Salt Lake City.
0 -
@SerraNola , OK but this is not an error in the auto-standardization routine that has plagued the historical index. This is regarding just the usual routine where a user enters a place name then links it to the appropriate standard. The usual behavior is for the routine to ignore the lowest level place if it does not understand it and to look at the next place level to suggest the standard to link to. For some reason, that is not working for Ogden.
What takes place in newspaper offices? Obituaries are published. For the context of where I accidentally ran into the Ogden problem see:
Obituaries are being a problem in Data Quality Checker because they were indexed with the date of the obituary and the place of death which the Source Linker uses to create a Residence event for the deceased with an impossible date.
So to not confuse the issue with a metaphysical rather than physical place, the same error occurs when entering a hospital for Ogden:
Just plain, Ogden, Weber,…, should stay on the final list as does Salt Lake City:
Usually if there is any ambiguity, the drop down menu will have many potential place names so that the user can click the red text and then click on the default linked standard to reopen the drop down menu of possible standards and pick the correct one whether it is the first one on the list or the last one on the list.
1 -
I think the problem stems from the presence of Ogden as part of the additional place name information. Things work as they should when the lowest level of the place name does not contain Ogden:
Whatever is causing that glitch needs to be fixed in the programing.
The above is still not standard behavior because usually the choice for the temple does not show up unless the word Temple is in the entered place name:
1
