Localities - A Real Problem
If one enters a present-day locality, such as Brynica, Opole, Poland for a 1880 time period, have the computer see that there was not a jursidiction at that time and change it automatically to the jurisdiction it was in 1880. Have the computer know that Brinnitz, Oppeln, Silesia, Prussia, German Empire = Brünne, District Oppeln, Silesia, Germany = Brynica, County Opole, Poland for set time periods. At log-in people should select the language they want it to appear in, then for Polish subscribers it might be Brynica, Gmina Łubniany, Opole, Polska. Have the computer spit out a message in English (or Polish for Poles) what the current jurisdiction was for the date they entered, then only place the correct jurisdiction for the entry at that time. Right now, all kinds of junk is being entered that are not correct for jurisdictions that did not exist at the time. But to mix languages (with your latest change) such as Brinnitz, Opole, Poland, when it should be Brynica is mixing the German name with the Polish name. Adding County would be great, as there is a Wright County in Minnesota and a town of Wright in Minnesota. By adding the word County would straighten out the Wright, Minnesota by making it Wright County, Minnesota. I used to work at the Family History Library and suggested a few things with Steven Blodgett (a locality expert), but it seems like suggestions at that time would always fall through the cracks or were not taken seriously.
Comments
-
I assume you are talking about entering place names in Family Tree. The basic problem is that the Places database is so far from being complete. Fortunately, it is slowly and gradually being improved. Also, fortunately, the programming in Family Tree allows us to put in the correct place name as fully and completely as we need and link it to an appropriate spot on the globe that is in the database.
I'm lucky to be working mainly in an area where the areas are complete and things work the way you wish it would, although not automatically, because the Places database is in pretty good shape. Automatic processes can easily lead to more trouble than they are worth because it is so nearly impossible to account for every possible combination of needs.
For example, if I want to enter the farm of Årskog for a place name I am given three choices for the place I intend:
- Årskog, Stord, Hordaland, Norway, Unknown to 1861
- Årskog, Fitjar, Hordaland, Norway, 1862 to 2019
- Årskog Fitjar, Vestland, Norway, 2020 to today
It is up to me to pick the correct one for the time period I am working in.
You should check around in the Places database and if there are places that need to be added or improved, you can make requests there for this to be done. It can take time for requested changes to get completed.
The database is here: https://www.familysearch.org/research/places
Then entry for Brinnitz/Brünne/Brynica is here: https://www.familysearch.org/research/places/?searchTypeaheadInputText=Br%C3%BCnne,%20District%20Oppeln,%20Silesia,%20Germany&text=Br%C3%BCnne,%20District%20Oppeln,%20Silesia,%20Germany&focusedId=9409666 You can see that all three names are listed under Alternate Names. It does look like it needs historical periods added and to be configured to have the correct place name for each time period. You could request this.
To see why we need so often to enter the correct place name and then link it to a "standard" in the database, you can review my presentation on Norwegian place name and the Places database at: https://youtu.be/veP6UcEkHaA
Regarding adding County to a place name when that is needed to be absolutely clear, just go ahead and do that. If you don't like the look of the name for a place as it is currently in the Places database, such as your concern with mixing languages, just be sure to enter it correctly and link it to the "standardized" version currently available. For your example above, this would look like this:
0 -
Given the uselessly corrupted database that has resulted from "the computer" associating database entities with indexed text fields (the auto-standardization flustercluck), please, no. Just no.
The problem starts with needing a complete and correct database of place jurisdictions to work with. No such database exists, and no such database is likely to be completed in our lifetimes. Hopefully FS's Places list will eventually come close, but other genealogy websites aren't even trying -- they "simplify life" by enforcing modern names and jurisdictions for all conclusions, regardless of how ridiculously wrong those are for the time of the event.
For individual database errors, such as language mishmashes like "Brinnitz, Opole, Poland", you can suggest a correction using the "Improve This Place" button in the Places tool.
For the inclusion or omission of place types in place names, there are conflicting opinions and practices even within FS's Places team. For example, they've added the word "county" to Pozsony, one of Hungary's pre-WW1 counties, but all of the other 62 counties that I've checked omit the place type. (This includes other counties that share their names with cities and are now partly or wholly in Slovakia, such as Komárom and Zólyom.)
In general, the place type should be apparent from its position: "Wright, Minnesota, United States" has to be the county, because the city is "Wright, Carlton, Minnesota, United States". The problem, of course, is that people miss this nuance, and associate the county with their city and thus end up with entirely the wrong place. Adding the type might reduce the frequency of such errors, but it would not eliminate them: someone unaware that the city is not in the same-named county could easily decide that what the heck, the county is close enough.
2 -
It is very, very difficult to use a correct place name if you don't know what it was. I attempted to create a new place name in the database, but I was unable to because the database knew that the province I thought was the name at that point in time wasn't created until later. Researching the evolution of provinces in the Russian Empire is not as easy as researching the evolution of counties in Virginia. So I gave up and some records for my family ancestors have a non standardized place of the town's name in the early 1800s, and other records have the standardized current day town and county which is in Ukraine. I think this contributes to the problem as well as the issue that which Julia Szent-Györgyi is talking about. Referencing what she is talking about, I have seen really dumb standardized place names which cannot be fixed by us. I reported one, and it did get fixed, as the source was not editable. A 1820ish marriage record in Knox County Indiana was standardized as being Knox Atoll, Marshal Islands in the middle of the Pacific Ocean. Really? Luckily that was fixed.
0 -
The FamilySearch Community team is actively capturing the information shared in the community so the product managers can access it either immediately or when they are getting ready to tackle that specific issue. Some product managers are busier than others, regardless they really appreciate the feedback, and they will be reviewing it.
Just wanted you to know that your feedback is appreciated and we are actively working to make sure feedback patrons are sharing isn't going to fall through the cracks in the future.
1 -
Also, the places team has a group within the community related to updating and improving the database. You may want to consider joining it and sharing inaccuracies you identified there. https://community.familysearch.org/en/group/68-familysearch-places
0
