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?

  • Surely this would be better asked on a GRAMPS support site / list? Here you are dependent on someone using GRAMPS - they might, but there'll be a lot more on a site specific to that software.
    – AdrianB38
    Sep 7, 2020 at 13:39
  • I asked here because the problem also affects WikiTree and so while it shows up in Gramps it's not specific to it. Probably more of an issue of Geni on how they are interpreting the standard.
    – phk
    Sep 7, 2020 at 14:32
  • You may very well be right about it being a GENI issue in terms of how they created the GEDCOM in question. But the point still holds. You'd surely be better asking in a forum / site / list dedicated to the software in question rather than a more general site like this where you're dependent on someone using whichever software it is that you're asking about. Only by asking subject matter experts can you resolve whether the issue lies with GENI (quite possibly) or whether both GRAMPS and WikiTree have the same import issue (possible but unlikely?)
    – AdrianB38
    Sep 7, 2020 at 14:46

2 Answers 2


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.:

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:

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.

  • I haven't been successful with tickets or forum posts or messages to their (single?) programmer in the past so I don't feel particular motivated to bother any more. Thanks for this post though!
    – phk
    Sep 7, 2020 at 20:27

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:

def makeBlockSingleLine(addrBlock):
    parts = []
    for line in addrBlock.splitlines():
        splitLine = line.split(" ", maxsplit=2)
        if len(splitLine) < 3:
        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",

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

# 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))),

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

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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