Some people eat, sleep and chew gum, I do genealogy and write...

Sunday, August 12, 2012

Revisiting Standardized Place Names

It is time to revisit standardized place names, an invention of computer programmers that is antithetical to careful genealogy. The genealogical standard is simple, you record the name of the place (location) at the time the event occurred. Period. No exceptions. If the place name has changed over the years, then you record that information separately. Improperly recorded place names is one of the most significant contributing factors to "lost" relatives. It is also very important to record the

There are some practical exceptions, for example, you could record a person as born in Arizona or Utah before those places became states because there is very little possibility of confusion. But in almost all other areas, the place name recorded should be the one used by the jurisdiction at the time. This is particularly true in places like Eastern Europe where place names may have changed several times over the years.

As an example, how many times have you run across relatives that said they were from Russia, when at the time they were born, they lived in the Austro-Hungarian Empire or in the Ukraine.

This problem becomes acute when dealing with county records. Every state in the U.S. has changed their county boundaries multiple times. I have had a lot of experiences where researchers were searching in the wrong county because the place recorded was the modern county, not the historical one.

Now, standardized place names come on the scene. At the very least, unless the "standardized" place is accurate at the time of the event, then the standardized place name should be disregarded. I always refer to my own family. When the pioneers arrived in Northern Arizona, it was, of course, a territory of the United States. The place where the Tanner's settled was called Allen's Camp and was in Yavapai County. By the time all the name changes and jurisdictional changes occurred from Yavapai to Apache to Navajo counties, without moving, they ended up in Joseph City, Navajo, Arizona after 1923.

So how many of my ancestors that were born before all of the name changes are reported to have been born in Joseph City? Nearly all of them. Using a standard place name will obscure the historical reality as well as mislead subsequent researchers who are not careful enough to search out the history of the place. This is not a speculative problem. For example, the new Family Tree program manual at page 41 provides the following:
If the Family Tree can apply a standard, it does so, even if you did not choose an option from the drop-down list.
 This is exceptionally dangerous. However, FamilySearch is not alone in its use of "standardized" places. They also appear in other programs such a when you type in a place to search. will then suggest a standardized place name. This whole issue does not arise from genealogists (even careless ones), it comes from computer programmers' desire to avoid work. They don't want to be bothered with "messy" reality, they would much rather impose their own structure on the world and make us all conform to it.

Here is the justification from FamilySearch's Family Tree Manual at page 31 for imposing standardized place names:
When you enter dates and place-names, Family Tree helps you select a standardized
place. Using standardized dates and places helps clarify the information that you enter.
It also helps the system find people with the search feature.
In other words, it makes the computer programmers' job easier. Unfortunately, the by-product makes the genealogist's job very much harder or even impossible.

I certainly understand that FamilySearch Family Tree allows for variations in place names, but based on the instructions, you would be led to believe that you were not "playing by the rules" to ignore standardized place names. I must admit, that when the standardized name agrees with the place name in my database, I use the standard, but I also systematically ignore the standard when it makes sense to do so. 


  1. You might want to check out "A Proposed Standard for Names, Dates and Places in a Genealogical Database" by Gary Molkotoff, Avotaynu, Vol XXIV, Number 3, Fall 2008. Gary was addressing issues that Jewish genealogists have in Eastern Europe, but it is a universal problem.

    It may be viewed at

    1. Web research is "forever" and Googlers, like me, that find their way to this discussion may want to view Mr. Molkotoff's paper which is now at

  2. The problem with place name as the event happen is that it is hard to see if the person moves or not. What genealogy software has to support is aliases for place names. In my Swedish research a person can be born, married and died in three different parishes but never moved.

    Should the place reflect the division where the data is stored or the true historical division?

    Example from Sweden.
    Nederluleå,Norrbottens county,Sweden "data stored"
    Nederluleå,Västerbottens county,Sweden "true historical"

    The county Norrbotten was formed 1810.

  3. James, kudos for pointing to this issue. It is complicated in FS-Family Tree because the system has been programmed to include myriad nonexistent and garbled place-names from trees and GEDCOM material that made its way into n.FS. They are included in the drop-down list of suggestions as among the "standard" suggestions. As so often, the advocates of proper methods need to get their own house in order.

  4. Regarding your comment on drop down menus...On Ancestry, when you type in Missouri, you get Missouri City, Texas and this appeared on my ancestors in other's family trees. In fact 3 of the cases it was my great grandfather and I know he was not born in Missouri City Texas. It comes down to people not watching what they are doing and not checking it later. Very frustrating to have to contact them and ask them to correct it.

  5. I haven't been at this as long as you, but, maybe this will solve the problem. I am using Ancestry and Family Tree Maker. This is how I handle the problem.

    In the place field I enter the Current Place Name. This standardizes the places for geographical purposes (map) and I can quickly see all places on the map. Then in the description I enter the Historical name.

    I decided to use the description for the Historical name rather than vice versa because any one place can go through various place names over time. The description field in these programs is not large enough to hold all permutations. However, there is only ONE current name and I can put the Historic name in the description per event as it was recorded at that time. When running the Place report I can see the history during the time my ancestors were there.

    1. Even this technique has a flaw. Namely the ONE current name can change in the future, which you may not detect and hence are not able to "stay current" over time. In other words don't assume that all place name changes have already happened in the past.

  6. The recommended practice on is to first enter the *accurate* modern location using the built-in Google location lookup ... because that captures a GPS coordinate pair for the location (even though it's not visible at the present time). Then, edit the individual location hierarchy fields to match the historical location names at the time of the event / record.

    (n.b.: Some prefer to always leave the "modern" location for a burial site, on the supposition that someone might like to visit that location)

    Another 'complicating factor' with location lookups is when the same name exists for different hierarchy fields ... such as Jamaica the island country vs. Jamaica in New York City. Since many U.S. records have been kept at the county-level (not by cities), that can also confuse the "auto-lookup" when the city-of-the-same-name is in a completely different county from the county-with-that-name -- sometimes in a completely different state, too.

  7. I make all my entries at least designate townships and counties as such, I use "Co" for counties. I have found the standardized naming leads to errors and reports that do not read well.