Export GEDCOM from geni.com and then importing not working properly

Question

When I export a GEDCOM (no matter whether in FTB oder GEDCOM 5.5.1 format) and then try to import into Gramps then I am getting a lot of warnings and many addresses are not showing up properly, e.g. if an event like birth has the location in the following form:

• Place name: House (conscription) number
• City: Village in question
• County/State/Country/…: As expected.

Then I am getting only the house number as the Place?! The same happens BTW if I try import the file to WikiTree next. Not very useful.

A bit of digging in the GEDCOM file itself makes me thing that the problem is whenever there is a PLAC as well as a ADDR element for an event. What also causes problems are entries imported to Geni itself which came from tools which generate multi-line address entries. in these cases we get CONT elements following the ADDR elements which also cause problems in Gramps (and the WikiTree GEDCOM import).

Are these known problems for which workaround exists?

Answer 1

Geni exports its places improperly into GEDCOM.

Normally the PLAC tag should be places at level 2 below the event it pertains to, e.g.:

1 DEAT
2 DATE 11 DEC 1901
2 PLAC Toronto, Ontario, Canada

Where the place is given as a place hierarchy separated by commas named from lowest to highest jurisdiction.

Geni instead incorrectly uses an address tag for this, and for the above example would produce the following:

1 DEAT
2 DATE 11 DEC 1901
2 ADDR Toronto
3 CONT Ontario Canada
3 CITY Toronto
3 STAE Ontario
3 CTRY Canada

Geni may in some cases include the PLAC tag, but seems to do so for a cemetery name or hospital name which should is normally not included in the PLAC value (if it is, then as the lowest jurisdiction of the place).

The ADDR tag in GEDCOM is designed to be used for street addresses and mailing addresses. Programs that correctly use the ADDR tag most often use it in an address book, and not for standardized place names associated with events.

So the problem is not with Gramps or Wikitree import, but with the Geni export.

The GEDCOM page in Geni's wiki states in their Known Issues section the following:

Lots of GEDCOM files contain place information in PLAC fields. This field is copied directly into the place_name field in the address record. It doesn't populate the address fields (city, state, country, ...). If you want the address fields populated, you need to make sure your GEDCOM file contains ADDR structures instead. Please feel free to update this issue with instructions on how to do this in various genealogy programs if you know how. Currently geocoding is done by city, state, country. I'm creating an enhancement ticket to have it geocode by place_name if those fields are empty.

This might be saying that Geni believes places should be in the ADDR field rather than in the PLAC field. According to the Wiki page history, this "Known Issue" was added to the page over 10 years ago, so it is an issue that they have not recently looked at.

If this is a major concern of yours, You could try the Geni community forum and raise the issue again. It was last raised by Kim Koblet in 2018. More info was requested six months later, but nothing happened since.

Alternatively, you can go to the Geni Help Center and submit a ticket and get a direct response from their customer service team.

Answer 2

Trying to reverse engineer the problem (independent of lkessler but I still thank him) I came up with the following quick-and-dirty Python 3 script which is modifying the GEDCOM in order to simply workaround the PLACes problem and also makes other changes in order to prevent import warnings from popping up:

#!/usr/bin/env python3

import re

with open("input.ged") as f:
    gedcom=f.read()

def makeBlockSingleLine(addrBlock):
    parts = []
    for line in addrBlock.splitlines():
        splitLine = line.split(" ", maxsplit=2)
        if len(splitLine) < 3:
            continue
        content = splitLine[2].strip()
        if content and splitLine[1] != "CONT" and content not in parts:            
            parts += [content]
    return ", ".join(parts)

# remove EMAIL + ADDR preceding it
gedcom = re.sub(
    r"^1 ADDR .*\n2 EMAIL .*\n",
    "",
    gedcom,
    flags=re.M
)

# remove SUBM
gedcom = re.sub(
    r"^0 .* SUBM\n(?:.*\n)+?(?=^0 )|^1 SUBM .*\n",
    "",
    gedcom,
    flags=re.M
)

# remove ADDR blocks after PLAC blocks and append it onto it
gedcom = re.sub(
    r"^((?:2 PLAC.*\n)?)(2 ADDR.*\n(?:3 .*\n)*)",
    lambda m: "2 PLAC {}\n".format(makeBlockSingleLine(m.group(1) + "\n" + m.group(2))),
    gedcom,
    flags=re.M
)

with open("output.ged", "w") as f:
    f.write(gedcom)

In detail what it does:

• Moves everything from the ADDR blocks onto the PLACes. Either existing ones or creates a new one. Tries to reduce recurrences and ignores CONT elements inside (since from what I have seen they do not add anything of value).
• Removes submitter (SUBM) blocks and references to it. I have no use for it and inside I get the problem again just on a different level which is why my regular expressions do not apply.
• Removes EMAIL elements, those are for the e-mails of members and Gramps does not have any use for it.

How to use: First, have an input.ged ready in your working directory. Then, run the script (using Python 3, not 2). Lastly, collect your output.ged.