A brief summary of project status
← Back to: Exchanging Data with Ancestry and FTM
Starting simple for quick results
Although the benefits are clear, the users' demand for these functions is not. The scope is also unclear, how complex will things need to be to satisfy differing levels of users? Further, will the concept of a round trip work at all and what are the constraints?
To get something straightforward working quickly the keys steps are:
- Prototype a FH to FTM routine that includes basic (standard FTM?) information and images only.
- Prototype a FTM to FH routine that returns all (FTM) data and images (including updates from Ancestry hints) to FH, perhaps merging with existing FH data.
- Make changes in both routines as dictated by errors, research results and user demand for additional complexity.
This is a "Demand Lead Strategy". An audit report helps to make clear how fields (tags) are treated and identify tags that have yet to be considered. In the way users are clear and the routine can evolve according to demand. An early example of this audit report can be downloaded below. It contains sections for INDI and all other key records broken down by:
- INDI tags: known & work with no processing
- INDI tags: known & work with processing
- INDI tags: known & work partially with some processing
- INDI tags: known & might work with processing
- INDI tags: known & won't work
- INDI tags: unknown but may work
If you are sufficiently interested in this to contribute with research and testing please get in touch. We need to identify which FH fields get to FTM readily, which need manipulating and which cannot.
Converting FH data for FTM
Where we are today
The FH 'Export Gedcom File' Plugin 1.9 in the Plugin Store now handles most export to FTM features mentioned below.
The FH 'Export Gedcom File' Plugin 1.7.6 (after manually preparing certain data) already moves a fair amount of FH data and media into FTM to enable hint matching in Ancestry. A VBA Prototype routine (under development) currently manipulates Plugin data to improve what arrives in FTM and prepares some of the data for a return trip to FH.
The headings below provide a simple work-in-progress list of what exists already, what might be developed and what is unlikely to be achieved. Please refer to other sections for up-to-date detail.
What will convert to FTM today
|Name fields||FH name fields comprise NAME, NPFX, NSFX, NICK, TITL, _USER. FTM ignores and incorrectly stores certain fields directly from FH. Both the Plugin and Prototype store all of these in FTM appropriately although some reassignment of fields may be necessary on a trip back to FH. The Prototype also ensures that commas in the NICK field are replaced with "or ".|
|Events and Attributes||FTM's regards these both as Facts with a Value, Date, Description and Note. The Plugin allows the ADDRess and second _PLACe to be stored in a note. The Prototype moves INDI and FAM addresses to the Value field for specified events (the list needs enhancing).|
|Pictures||The Plugin enables part (cropped), full or both pictures to be stored in FTM. The Plugin and Prototype assign the first a _PHOTO tag to make that image the profile picture (where object records were been created by the Plugin).|
|Citations||FTM can store basic SOURce and REPOsitory fields only so the Plugin exports Source records putting certain fields in the note. FTM requires that SOUR, OBJE links also appear under INDI, Event, SOUR (a citation) to display properly which is not yet handled by the Plugin. Further, citations cannot appear against the INDI or FAM, only against an event or attribute therefore the Plugin will have to demote such citations to the first INDI,NAME (not sure where to put the FAM citation). The Prototype currently does this although other citation records are not yet output.|
|Other||Sundry other tweaks exist like renaming _FILE to FILE, _EMAIL to EMAIL, UCase(DATE) deletion of SENTence and _PLACe records, etc.|
What might convert to FTM in the future
The following matters are pencilled for inclusion:
|Home Person||Using the _ROOT tag to make the INDI first in the file so they are the home person in FTM.|
|Status||_STAT is not stored in FTM. Information in _STAT can conflict with MARR and DIV events which are stored. It is possible some of the other _STAT choices could result in the creation other family events available in FTM.|
|Use of notes||Notes fields and records could be used to store FH data in a structured manner. This approach may be used not only to record data for which FTM has no field (SOUR already done, REPO to do, etc.) but also for a UID to enable a automated merge back into FH (rather than a replacement of the FH file.|
What is unlikely to convert to FTM
Further research may result in solutions but these are some of the trickier matters.
|Lists||There appears nowhere to store these in FTM|
|Flags||There appears nowhere to store these in FTM|
|CHANge information||Audit fields (date, time and notes) are not imported by FTM.|
|Place records||Places are stored in FTM. Optionally, they can be matched (normalised) manually against Ancestry's database resulting in better hint matches, the removal of leading commas and abandoning of the user-defined structure (e.g. village, town, county, country). Text, images and co-ordinates found in _PLACe records cannot be imported or stored by FTM.|
|Witnesses||This is not yet well understood and it is uncertain if FTM has potential capability|
|Submitters||This is not yet well understood and it is uncertain if FTM has potential capability|
|Linked Aliases||This is not yet well understood and it is uncertain if FTM has potential capability|
Converting FTM data for FH
Development has not yet started. Notes and ideas are being formulated as work continues on the FH to FTM Prototype. See Step 6 Import your FTM GEDCOM back into FH