Step 2 Create a GEDCOM using the FH Export Plugin v1.7-2.0

Export Gedcom File Plugin

export_gedcom_file_-_v1-7-c.fh_lua Export Gedcom File Plugin Version 1.7.C download 03 May 2015.

The Export Gedcom File Plugin V2.0 is now published in the Plugin Store.

Using the FH Export Gedcom File Plugin

As a general rule, synthesised items such as Source Records, Note Records, and Custom Events have their name prefixed with an Omega Ω to aid identification and sorting.

Tab 1: Basic Options

Field Content Note
CHAR UTF16 with a BOM FTM can import a UTF-16 GEDCOM exported directly from FH so any option should work.
Media ALL~ABS You may choose part (cropped) images (PART~ABS), full images (FULL~ABS) or both (ALL~ABS). A _PHOTO tag is automatically created to set the profile picture to the first image. Importantly, the export creates a separate image file for each face it crops from a full image and prefixes the file names uniquely. Getting back to FH the full image and crop co-ordinates is feasible because the original Media File path and Frame Area co-ordinates are preserved in labelled Notes, together with all other Media settings.
Folder FTM media folder e.g. C:\…\Family Tree Maker\{treename} Media. The export uses full paths to tree images (not relative paths to a sub-folder). To ensure paths images added to your tree are stored with existing images, export the GEDCOM and image files to the folder you intend to store FTM images in and (if necessary) rename the GEDCOM to {treename}.ged before importing to FTM.

Tab 2: Extra Options

Below are the default options when FTM 2014 is selected on Basic Options tab. In some cases alternative options are feasible. Comments have been added for discussion where an alternative approach might be chosen by the user or employed in a future version.

Options for: HEADer data

Field Content Note
Named List (1 _LIST) Remove OK: Named List data is preserved in the Header record. Optionally one might want to create a Source record. This creates a Source record for each List containing a list of such records in the Note (Comments field) and also linked to by each record in the list, except REPO/SUBM/SUBN.
File Root (1 _ROOT) Remove OK: Root (home) person information is preserved in the Header record and FH's ROOT Person gets repositioned to first INDI in file to make them FTM's Home Person. Optionally one might want to move the _ROOT tag to a Source Record Note linked to that person. Although the Home Person may later change in FTM the data retained would optionally allow reinstatement on Import.

Options for: INDIvidual data

Field Content Note
Person Nickname (2 NICK) Use "" in Name and Note OK: NICK and _USED move to NAME correctly (I assume the 1 ALIA option still works) and no issue is presented by ",". When both fields are moved there are 2 "quoted" inserts into the NAME with no adverse effects other than the field lengthening. NICK and _USED have separate options so a user can choose to use NAME or 1 ALIA for each if the NAME becomes too long. I considered a single option for both NICK and _USED but the options may be too many. Reconstruction would be from the Note with a warning/choice upon conflict.
Given Name (2 _USED) Use "" in Name and Note OK: See NICK above.
Record Flags (1 _FLGS) Record Note OK: Data preserved in the note. Alternatively, a custom EVENt can be created with a value of "Y", a Name with Ω prefix and Flag tag, and a Note with the Flag name.

Options for: FAMily data

Field Content Note
Marriage Status (1 _STAT) Record Note OK: "Marriage Status: value" is correctly put into a FAM record NOTE. Despite all previous information FTM does support a record NOTE (but not a citation) in both INDI and FAM records. The FAM note can be seen from the relationships screen.

Options for: Events & Attributes (Facts)

Field Content Note
Witness Role (2 _SHA%u) Fact Note INVESTIGATE AND TEST: Needed to reconstruct Witnesses on return to FH. Alternative option is remove entirely. I need to understand the purpose and test.
To/From Place (2 _PLAC) Fact Note OK: Into/From Place: appears in Fact Note only for standard IMMI/EMIG events
Custom Attribute (1 _ATTR) Custom event & Value OK: Custom _ATTR Value moved to EVENt Fact Description and duplicated to Fact Note together with all other relevant fields (Value, Date, Place, Address, Note).
Fact EMail (2 _EMAIL) Fact Note OK: Fact tags other than DATE, PLAC, NOTE, Value and citation tags get moved to a labelled Fact Note. These include EMail, Web, Phone, Age and Cause (for Cause of Death the tag line is retained instead of being deleted. FTM creates and uses a Cause of Death event). See Processing for: Events & Attributes (Facts) below.
Fact Website (2 _WEB) Fact Note OK: See Fact EMail.
Fact Phone (2 PHON) Fact Note OK: See Fact EMail.

Options for: _PLACe data

Field Content Note
Place Record (0 @P%d+@ PLAC) Source Record OK: A Source record (with name prefixed with an Omega Ω for sorting) is created for each FH Place to retain place data, notes and objects.

Options for: REPOsitory data

Field Content Note
Record EMail (1 _EMAIL) Change to 1 EMAIL OK: As FTM only supports one EMAIL field, multiple instances of _EMAIL are appended to one EMAIL instance.
Record Website (1 _WEB) Append to EMAIL OK: As FTM only supports one EMAIL field, multiple instances of _WEB are appended to one _WEB instance in the EMAIL field.
Record Phone (1 PHON) Append to PHONe OK: As FTM only supports one PHON field, multiple instances of PHON are appended to one PHON instance.

Options for: SOURce data

Field Content Note
Source Type (1 _TYPE) Record Note OK: It appears that all FH Source tags without a specific FTM field (i.e. Title, Author, Publisher and Repository) are preserved in the Source Note. These tags are: the note itself, Short Title:, Source Type:, Text From Source:, Custom Id. The Short Title is also moved to the Title if it does not exist.

Options for: OBJEct Media data

Field Content Note
Picture Note (%d_NOTE) Local Note OK: This FTM field displays Picture Note: (with blank lines where necessary), Media File:, Media Date:, Keywords:, Auto Seq Id: (ASID), Frame Area:, Exclusions: Media Format:, Use Caption:.
Media Date (%d _DATE) Local Note OK: See Picture Note above.
Media Keywords (%d_KEYS) Local Note OK: See Picture Note above.
Media Exclude (%d _EXCL) Local Note OK: See Picture Note above.
Media Caption (%d_CAPT) Local Note OK: See Picture Note above.

Options for: Global data

Field Content Note
Date Field (%d DATE) Upper OK: Note that FTM sorts a year-only date as if it were 1 January, therefore a burial in 1900 can come before a death on 2 Jan 1900.
Updated (1 CHAN) Remove OK: FTM does not support timestamps so ignores them anyway.

Additional processing that has no Options

These are unconditional FTM 2014 export rules with no options.

Processing for: INDI & FAM data

Topic Action Note
Whole Record Citations Move to custom EVENt OK: INDI custom EVENt Ω <whole record citation> is created (not checked FAM) as FTM only allows citations at Fact level (not for the whole INDI or FAM). Sources and Objects (citation data) appear to attach well showing an appropriately composed Reference Note.
Citation local Notes Move to TEXT From Source OK: Citation tags (PAGE, TEXT, DATA, etc.) are similar to FH but NOTE must be treated differently. All citation NOTE (and _FOOT that only exists in FTM) tags are deleted and content appended to TEXT From Source to avoid FTM's Reference Note getting devalued as discussed in the forum.
Source Citations Media copied from Source OK: All OBJE & subsidiary tags (from the SOURce Record) are moved (or duplicated) to the citation. FOR INFO ONLY: OBJE tags could also be deleted from the SOUR where a citation exists. Note that FTM requires SOUR records to be linked to a fake person to enable access to them (perhaps manually before an FH export).

Processing for: Events & Attributes (Facts)

Topic Action Note
Fact tags Move to Fact Note OK: To preserve data, various fact tags are moved to the Fact Note. These include: AGE, HUSB AGE, WIFE AGE, CAUS, TYPE, AGNC, _SENT. There is an exception for the DEATh Event that also retains the CAUSe tag line as FTM needs it to create a Cause of Death Event. There is also an exception for the TYPE Descriptor applied to custom EVENts where the tag line is retained and no Note is created.
PLACe Retained & labelled Note OK: All Fact PLACe & subsidiary fields are moved to a labelled Fact Note. In addition the main PLAC tag line is moved to FTM's Place field so it can be normalised using Ancestry features. All PLACe fields no longer attempt to cite their associated Source Record (created to record Place Record data). DISCUSS: The citations are not appearing (not sure why these are needed anyway). Notably two place citations (to one place) exist…for LDS Spouse Sealing Place. MIKE: Should not be any citations since V1.7.A.
ADDRess Move to 1 [Event] Value & Note OK: All Fact ADDRess & subsidiary fields are moved to a labelled Fact Note. In addition the first line of main ADDR tag only is moved to the Fact Description for both custom and standard Events but not Attributes where the Value is moved instead.
INDI IDNO Custom event created Attribute IDNO is ignored on import so becomes a custom EVENt Ω IDNO.
INDI & FAM NCHI Custom event created Attribute NCHI is ignored on import so becomes a custom EVENt Ω NCHI.
FAMily CENSus Custom event created OK: FAM, CENS events (not INDI, CENS) are ignored on import therefore a custom EVENt Ω CENS is created to preserve this data. It is assumed that FTM's approach is that a Fact is either for an Individual or Shared.

Processing for: Media data

Topic Action Note
No further processing

Processing for: Source data

Topic Action Note
Use of Source Records Source records created OK: To preserve data for import back to FH, synthetic Source records (with name prefixed with an Omega Ω for sorting) are created for File Root, Header Rec, Named List, Place Rec, Repository, Submission, Submitter. DISCUSS: Apart from File Root, Named List and Place Rec, the others have no links to them therefore the tabs for Links, Notes and Media are disabled. To see details double click Source. [MIKE] Since these synthetic Source Records only preserve data for import back to FH, maybe it is better that the tabs are disabled and details difficult to find, and thus prevent accidental alterations? TEST: Link a source to a source via note, or link a Note Record to them all, where both are tried in v1.7.9 dated 13 Apr 2015, and all failed.). A warning source record above this group with a name like "Ω ~DO NOT ALTER THE RECORDS BELOW~" is also added (in v1.7.9 dated 13 Apr 2015).

Processing for: Repository data

Topic Action Note
Repository tags Move to Source OK: Repository records support Name (388), Address (945), Email (max 566 chars) and Phone Number (496), but only as one line fields. To preserve data all unsupported FH fields and notes are moved to a synthetic Source Record with same Name as the Repository appended with the Record Id.

Processing for: Other data

Topic Action Note
Custom ID (1 REFN) Record Note OK: REFN and subsidiary tag TYPE moved to record note for every type of record.
HEAD SOUR Changed to FTM OK: The Header Source of FAMILY_HISTORIAN is changed to FTM to imitate an FTM import. This is to force FTM to import Media Record Local Notes. In addition, all HEAD tags are copied to a synthetic SOURCE Record to preserve them during the round trip back to FH. This includes Named Lists, File Root, etc.
SUBM/SUBN records Move to Source OK: These are not supported by FTM, so each one is moved to a synthetic Source Record with same Name that is also appended with Record Id.
Record IDs Moved to Note OK: Although FH's Record IDs change when they pass thru FTM, the original IDs are preserved in the record note potentially for merging back to FH. For REPO, SUBM & SUBN records, no Note exists therefore the ID is appended to their name.
Other fields Move to Note OK Various sundry fields are preserved in FTM notes. These include REFN, RFN, AFN, RIN, PEDI, _PEDI, SUBM@. DISCUSS: Further work is necessary to identify all such fields.

Additional steps that might be automated

The GEDCOM exported from the FH Plugin would benefit from further work to import data more fully to FTM.

Topic Action Note
Warnings Check and warn DISCUSS: The Prototype currently scans and categorises tags to report what works, might work, doesn't work etc. Given a demand-lead evolution of the Plugin perhaps this approach should be employed?
Media Folders Investigate INVESTIGATE: It now appears that FTM can handle multiple media folders. There is no plan to support this at present. If this changes we need to ascertain how these are input (we know they can be corrected) and establish FTM handling of imports and exports. We then need to design the solution.