4

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:

enter image description here

  • 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.)

enter image description here

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: enter image description here

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)?

4
  • Please clarify: when RootsMagic adds a place you've entered to the database (which it seems it is supposed to do) does it fall outside the proper place hierarchy before you ignore it? Why are you ignoring it when you want it to be in the list of predicted places?
    – Jan Murphy
    Mar 2 at 5:57
  • 1
    "Ignore" is the terminology FTM2019 uses. Clarification is too long for a comment; I'll instead add it to the question itself.
    – BrianFreud
    Mar 2 at 14:19
  • Thanks for the update. I have RM7 and FTM2014. I can try some experiments but it may take a while.
    – Jan Murphy
    Mar 2 at 19:41
  • I'm using RM7 and 8, plus FTM2019. Of the three, RM7 is my preference, but attempting to run RM7 either in a virtualbox instance, or via wine, on linux, it consistantly won't connect to the net, so I flip back and forth between RM7 and FTM2019. Both have different strengths, but place-handling is surprisingly poor in both, moreso in FTM2019.
    – BrianFreud
    Mar 2 at 20:26

1 Answer 1

3

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.

4
  • 1
    The place authorities, even without geocoding, are also designed to show only one name per place, even though the multi-level place name may have changed over time. This shows up many places (counties in Ireland & Wales, territories vs. states in the U.S., etc.). Genealogical convention calls for place names to correspond to the date of the event, rather than the current name, but the place authorities aren't equipped to deal with that.
    – cleaverkin
    Mar 1 at 19:33
  • Most of the places I'm dealing with still exist today. They actually are in the ancestry database. They simply are not in the database of either software. This is not an issue of trying to go one level deeper in location then is supported; it is places which simply are not within the local database.
    – BrianFreud
    Mar 1 at 23:06
  • @BrianFreud Just to clarify "Ancestry database" = the Place Authority on Ancestry's online tree system. I was trying to debug what was happening, to see if the problem was that places were being added with their jurisdictions in the wrong level, and that was interfering with them showing up via the predictor.
    – Jan Murphy
    Mar 2 at 19:19
  • No worries. FTM2019 and RM7 both advertised 3m locations in its database, iirc. Similarly, RM8 advertised 3.5m. I've worked on enough databases of similar "comprehensive" intent to know that they will never actually have 100% coverage or accuracy, so you should always build in a way to add to or edit that local "comprehensive" database. RM almost gets there, but it's limited in it's one-off application. It doesn't seem that FTM2019 built in a way to do it, but I'm hoping there's perhaps a way to externally edit that database to accomplish the same goal.
    – BrianFreud
    Mar 2 at 20:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.