Gramps: GEDCOM Import/Export Quirks (Open-Source Specifics)

Gramps is the most commonly used open-source genealogy program, and its GEDCOM handling reflects a design that's more capable than plain GEDCOM in several places — which creates a specific, well-documented set of gaps and quirks when data crosses the boundary in either direction.

What Gramps can't put into GEDCOM at all

A handful of Gramps fields have no equivalent structure in the GEDCOM standard and are simply dropped on export: Call Name and Family Nickname have nowhere to go in GEDCOM's name structure, Alternate Locations aren't supported by the format at all, and Tags — Gramps' organizational labels for grouping records — are excluded because they're an organizational tool rather than genealogical data GEDCOM has a place for. None of this is data loss inside Gramps itself; it's specifically a limitation of what survives the export to a GEDCOM file.

Gramps' data model is more complex than GEDCOM's, and export flattens it

Gramps supports a more elaborate citation model, more complex family relationship types, and independent source/citation/media/repository/note objects that GEDCOM requires to be attached under an Individual or Family record rather than standing alone. On export, all of this gets flattened to fit GEDCOM's simpler model — complex relationships get converted to whatever standard type is closest, or encoded into custom tags that other software generally won't interpret the same way.

A subset export still includes every source in the database

If you export a selection of people rather than your whole Gramps tree, be aware that the resulting GEDCOM file includes every source in the entire database — not just the sources actually linked to the people you selected. For a database with extensive source records, this can produce a much larger file than expected, and one that includes citation material unrelated to the people you meant to share. If your goal is a genuinely self-contained subset — say, one branch of the family to hand to a relative — the Tree Splitter takes a different approach: it only includes what's actually connected to the people in your extracted selection, with pointers rewritten to match.

Importing the same file twice can duplicate events

Gramps' standard GEDCOM import doesn't generally duplicate people if you import the same file a second time, but it can duplicate events in that scenario. If you're in the habit of re-importing an updated export to refresh your Gramps database, it's worth checking for duplicate events afterward rather than assuming the re-import merged cleanly. See Duplicate Individuals: How They Happen and How to Find Them for a broader look at how repeated imports create this kind of problem across different genealogy software, not just Gramps.

Encoding declarations aren't always trustworthy

Gramps' importer also has to handle files that misreport their own encoding — specifically, GEDCOM files that declare themselves as using ANSEL encoding when they're actually something else. Gramps accounts for this rather than trusting the declaration blindly, but it's a useful reminder that a file's stated character set isn't always accurate, regardless of which program produced it.

Sources: Gramps Project Wiki — Gramps and GEDCOM; Gramps Discourse Forum — Problems limiting sources on GEDCOM export.