How to add places to the master database in Family Tree Maker 2019/Rootsmagic?

Question

I've run into this same issue in both Family Tree Maker 2019 and RootsMagic 7/8. Both seem to use the same database of locations, as I find the same places missing in both programs.

When resolving place names, I know that you can 'ignore' a specific place and it'll be removed from the list of 'unidentified' places. However, that just papers over the display, while keeping the problems:

• The place does not get categorized with other places in that region. Here's an example; notice that Breitenbach is marked as ignored, which removes the "?" icon, but the village remains at the top-most level in the list of places, rather than moving into the proper place within Hersfeld-Rotenburg in the tree:

• Neither program will suggest those 'ignored' places when you're entering another fact for that place. Indeed, going with the same example, FTM2019 suggests both 'Breitenbach am Herzberg' and 'Breitenbach, Kassel', but not 'Breitenbach, Hersfeld-Rotenburg'. (Both are nearby, but are completely different villages.)

In addition to the randomly missing villages, nearly every German Hof I've tried is not in the databases.

I've run into the same issue with Canadian and US locations. In Canada, I've found a quite large number of towns in Nova Scotia are missing. In the US, I have at least a few dozen townships and modern-day ghost-towns that similarly are not in the databases.

This shouldn't be too big of a problem to fix; I'd happily add the places to the local copy of the database. However, how can that be done?

---

Clarification of the question:

Rootsmagic handles locations not in the master local database by letting you add a location that, once added, acts essentially the same as one from that database. (Rootsmagic only annoys me because you have to identify each location one at a time.) It'd be nice, however, to be able to add directly to that database, so I can reuse those same missing locations between different rmgc files, without having to re-enter them each time.

In FTM2019, you resolve unidentified locations in bulk, which is a huge time saver, using "Resolve All Place Names". However, as described in the question, FTM2019 does not allow you to add a location that is handled on par with locations from its local master database. All locations start as "unidentified". You then can either pick a location from within its local master database, or click the checkbox to "ignore" that location.

Continuing with the example of "Breitenbach, Hersfeld-Rotenburg, Hessen, Germany", this is a village not in the FTM2019 database. The four closest villages are:

• North: Bebra, Hersfeld-Rotenburg, Hessen, Germany - in the database
• South: Blankenheim, Hersfeld-Rotenburg, Hessen, Germany - in the database
• West: Lüdersdorf, Hersfeld-Rotenburg, Hessen, Germany - in the database
• East: Weiterode, Hersfeld-Rotenburg, Hessen, Germany - in the database

All 5 towns are equal in the number of "place levels". All five are 500+ years old. All five still are inhabited today. All five were listed in the Meyers Gazetteer, as well as within Arcinsys, the place authorities you'd likely consider for either the late 1800s, or for today.

However, of the five, one is not in the master database of either FTM2019 or RootsMagic. As described above, for RootsMagic, it's an annoyance, but a one-time pain per rmgc file. For FTM2019, however, "unidentified" locations not in the database cannot be created, only "ignored". Thus to restate this question, how can the master database itself be edited (especially for FTM2019)?

Answer 1

I suspect that your problem is an artifact of the way genealogy programs deal with place names. The fact that you're having the problem with both Roots Magic and Family Tree Maker may be due to the feature which syncs a Roots Magic or Family Tree Maker database to an Ancestry online tree. They have to do things in conjuction with Ancestry's API. Also, many programs are using geo-coding now, which also means the place list has to stay reasonably aligned with a modern list of place names.

It is not always easy to determine what the source of a place list comes from. (These databases are sometimes called a place authority.) For example, the catalog at FamilySearch, which lists the microfilm, books, and other holdings of the Family History Library in Salt Lake City, is standardized on Meyers Orts- und Verkehrs-lexikon des deutschen Reichs. The help for the online Meyers Gazeteer says:

The goal of the Meyer’s compilers was to list every place name in the German Empire (1871-1918).

If you are doing research in a place which was once part of the German Empire, and you want to find record in the Family History Library catalog, you need to know what the place was called in the period covered by the gazetteer, as well as the name that appears on the historical record you have in hand. If you want to geo-code the place, you need to know where the place is in relation to a modern map such as Open Street Maps (or whatever place authority the geo-coding algorithm uses). The most straightforward way to handle the place names in our software is to enter the place name in a form the geo-coder understands, and to record the historical names in our research notes.

In the Roots Magic Wiki, the page Geocoding Places says:

Approximating Places Not Found Be aware that the GeoCoding database may not work correctly for all countries, or all jurisdictions within a country. For instance, many provinces in Canada have four place levels, yet the Places Database only supports three place levels for Canada. As a result, place names, such as Peel Township, Wellington County, Ontario, Canada cannot be found and GeoCode suggests Peel [County], Ontario, Canada or Wellington [County], Ontario, Canada.

If the place database won't support enough levels for places in Canada and Germany, this may cause the kind of problems you're seeing, where you can't add places and have them show up in the right place in the place list predicitons. One thing you might try is to reverse the place list so that Canada or Germany or the United States is in the begining of the list, and cross-check your newly-entered places to see how the jurisdictions align with the standardized places in the list. You may have to record some of the jurisdictions that pertain to your place in your research notes instead putting them into the place list.

The RootsMagic Wiki article Working With Places does say that RootsMagic doesn't restrict the number of place divisions, and that the places you add automatically to the Place list are supposed to turn up in the predictions list as you expected. However, the article on Geo-coding contradicts this. Try disabling the geo-coding feature to see if that works.

As for the ghost towns in the USA, the Federal standard is The Geographic Names Information System (GNIS). The system is focused on keeping track of modern-day names for current uses, and some of the data genealogists use such as cemetery locations will be archived soon. If you are interested in having your own copy of the feature data, download the data from the page on Domestic Names.

Data Content:

Since GNIS staff has been unable to maintain Domestic administrative names for quite some time (since October 1, 2014), these records will be archived from GNIS database and will longer be available through the GNIS search application. The following feature classes will be archived: Airport, Bridge, Building, Cemetery, Church, Dam, Forest, Harbor, Hospital, Mine, Oilfield, Park, Post Office, Reserve, School, Tower, Trail, Tunnel, and Well.

It's unfortunate that we won't be able to search for these features in future. Knowing the locations of Post Offices can be useful for census research, and being able to search for cemeteries by name is useful for disambiguation. GNIS was my go-to site for finding the lat/long data for features so I could make use of geo-coding features. If you want this data for mapping your US ghost towns, download it now before it goes away, or see if you can find your towns via The National Map.