Exploring a possible utility to standardize place names

#1 · 2026-03-07, 4:35 pm

For the most part, I have adopted the FamilySearch standard names in my work. I find they work well for international place names, and in multiple languages, both of which are important to me.

I'm thinking of creating a utility that will use the place names in RM to search for their FS standard names and place ID specifying a language and time period.

I don't think that it can be fully automatic as a search often returns multiple names.

I would probably use a "sidecar" pattern, so that the utility would create and update an auxiliary places table and leave the RM PlaesTable alone, until a command is given to swap the existing place names in the RM PlaceTable with the AuxPlaceTable names, or some such mechanism.

I just found out about the FS API to its place database and it worked well in some tests in Python.

Any interest or comment?

Richard Otter

Just noticed that the PlacesTable already has a column named fsID.

kevync has reacted to this post.

#2 · 2026-03-18, 8:40 pm

Personally, I am not comfortable with python. I have intermediate skills with Power Query, Excel, and Power BI, also SQLITE.

Yes I would be interested.

Kevin\

#3 · 2026-03-29, 9:41 pm

Richard,

Did you get a FamilySearch API key? I've been looking at their form for the key.

This part slowed me down, "API access is ONLY available for organizations with software development experience and application marketing history. All personal and academic requests will be denied."

My apps to this point have been for personal use. But I'm looking to start marketing them, in part to add an integration with FamilySearch.

Michael

keithcstone and kevync have reacted to this post.

#4 · 2026-03-29, 9:43 pm

not sure how but someone I interact with online got one not sure what they said to get it

#5 · 2026-03-30, 12:12 pm

I ran some sample code from AI and it worked.
I haven't investigated farther. My understanding was that because it's read only access, there is no key needed.

import requests

def get_german_name(place_string):

url = "https://api.familysearch.org/platform/places/search"

params = {"q": f'name:"{place_string}"'}

headers = {

"Accept": "application/json",

"Accept-Language": "de"

}

r = requests.get(url, params=params, headers=headers)

r.raise_for_status()

data = r.json()

# FamilySearch wraps results inside "places"

places = data.get("places", [])

if not places:

return None

place = places[0] # take the top interpretation

names = place.get("names", [])

# 1) exact German match

for n in names:

if n.get("lang") == "de":

return n.get("value")

# 2) any German variant (e.g., de-AT, de-DE)

for n in names:

lang = n.get("lang", "")

if lang.startswith("de"):

return n.get("value")

# 3) fallback: first name in list

if names:

return names[0].get("value")

return None

# Example usage

german_name = get_german_name("Vienna")

print("Preferred German name:", german_name)

kevync has reacted to this post.

#6 · 2026-04-02, 4:26 pm

This is interesting -- Power BI (or Excel PQ) could make user of this. Seems like some things are limited where other things might need a toxen or more depending

#7 · 2026-04-07, 9:22 pm

Years ago FamilySearch (and Ancestry) were much more open on their APIs. Back when FamilyTreeMaker went to Kiev and while RM 7.5 was in development both APIs were published and I even had a key for FamilySearch, although I did cheat with my @hp.com work address. Ancestry opened the door, then slammed it shut. FamilySearch realized that managing an API takes people (and money) and pulled back. Working on APIs for transportation scale (nearing 10,o00 per second) I can see why FamilySearch decided free was a bad idea. Ancestry has the ability to offer it, for people that subscribe, but chooses not to anymore.