* Import vs Merge from FindMyPast

[Normie]

I am trying to build a single project to contain all persons linked to an address; similar in concept to a one name project.

I have separate trees in FindMyPast for each family. I created the initial project by importing a GEDCOM file from FMP. I then merged a second GEDCOM file for the second family into the project (No individual was duplicated).

However not all of the facts were imported. Taking the same GEDCOM file into a new project, ALL the facts were imported.

I attach copies of relevant project windows.

Strangely if I export a GEDCOM file from the new FH project for the second family, and then merge it into the 'single project', the ALL the properties are imported.

It appears that the 'merge' function is not to be trusted to transfer all the facts. Or perhaps I am missing something?

Thanks in advance for any suggestions.

[tatewise]

Yes, I have confirmed what you discovered.
The FindMyPast GEDCOM probably has badly formatted details that break the GEDCOM rules.

I suspect that when you import into a new Project there is a Family Historian Exception Report.
See the Window > Log Files... that should have retained a copy.
It will probably have many INFO ONLY: Detected & fixed ... messages.
Therefore, the badly formatted GEDCOM details have been fixed and thus will Merge OK.

When you directly Merge the FindMyPast badly formatted GEDCOM the problem data is simply discarded.

See the FHUG Knowledge Base advice for the Merge/Compare File feature.
That advises that a new temporary Project is created and cleaned up before attempting a Merge.

Also, see FHUG Knowledge Base Importing to Family Historian with general import clean up advice.

[Normie]

Mike,

Thanks for the reply and explanation.

I have looked at the GEDCOM files generated by both FMP and FH. I can see that all the missing facts are designated 'EVEN' by FindMyPast and converted to 'FACT when exported by FH.

As FH can interpret and fix on importing a FMD GEDCOM file, why can it not fix them when merging?

[tatewise]

Although FH can fix some problems on importing a new Project, it often cannot fix them all, and even the automatic fixes may not be the best solution for you. However, you know the problems only exist in that new Project.

I would venture that the Family Historian Exception Report mentions data that could not be fixed (such as UDF).
The most common fix is to move EVEN data to the local Note, but that may not be the best solution.
See FHUG Knowledge Base Importing to Family Historian that summarises all manner of imported data problems and fixes.

So if the FH Merge applied the same fixes as a new Project, the data that could not be fixed or was not the best fix could be scattered throughout the merged Project making it more difficult to find and fix.
In your case, as there was no actual merging, only the new records would contain the problems, but in the general case, the problems could be infiltrated anywhere into any records that had been previously 'clean'.
That applies to ALL types of records, not just Individual records, but also Family, Note, Source, Media, etc, etc...

See FH Help page Transferring Data into Family Historian that echoes the Knowledge Base advice.

[Normie]

I appreciate what you say about FH not being able to fix all 'anomalies'. However, what I am seeing is the when merging a FMP file, it ignores ALL census and 1939 Register facts. I assume the underlying issue is that FMP identifies these as Events (EVEN) whereas FH identifies them as Facts (FACT).

Taking an example for the FMD file:

1 EVEN was age 3 and the daughter of the head of the household
2 TYPE Census UK 1891
2 _PRIM Y
2 DATE 5 Apr 1891
2 PLAC Ashton Under Lyne, Lancashire, England
2 ADDR Queen Street
2 SOUR @S5@
3 PAGE Archive reference: RG12; Piece number: 3276; Folio: 120; Page: 23; Schedule: 144; HouseHoldID: 4781800; Record set: 1891 England, Wales & Scotland Census; Subcategory: Census; Category: Census, Land & Substitutes; Collections from: United K
4 CONC ingdom, England;
3 REF http://search.findmypast.co.uk/record?i ... 0022627303[/b]

After import this into FH, FH exports it as:

1 FACT was age 3 and the daughter of the head of the household
2 TYPE Census UK 1891
2 DATE 5 APR 1891
2 PLAC Ashton Under Lyne, Lancashire, England
2 ADDR Queen Street
2 SOUR @S5@
3 PAGE Archive reference: RG12; Piece number: 3276; Folio: 120; Page: 23; Schedule: 144; HouseHoldID: 4781800; Record set: 1891 England, Wales & Scotland Census; Subcategory: Census; Category: Census, Land & Substitutes; Collections from: United Kingdom, England;
3 REF http://search.findmypast.co.uk/record?i ... 0022627303
2 _PRIM Y

The only perceptible change to change 'EVEN' to 'FACT'.

The workaround for me is to change the text EVEN to FACT in the FMD file prior to merging.

Fundamentally if you identify a new census record for an individual in FindMyPast, you cannot use the merge function to import that fact into Family History.

[KFN]

In GEDCOM there is not much difference between an EVEN and a FACT. Which are both valid in v5.5.1 GEDCOM, but not in versions prior to this release where only an EVEN existed.

What I do see in the example you provided is that the EVEN.SOUR.PAGE tag has a subtag of CONC which is invalid GEDCOM.

The rules of GEDCOM do not allow for a PAGE tag to have a CONCatenation, all PAGE data should be continuous.

In the exported FACT this is corrected.

[Normie]

FMP produces a GEDCOM file with an EVEN.

FH produces a GEDCOM file with that changed that to a FACT. It is version 7 of FH that has the CONCatenation.

My issue is that FH does not recognise EVEN when merging a GEDCOM file.

[Normie]

I'll retract the last comment; it is FMP that has the CONCatenation.

Is it the CONCatenation that the merge function cannot handle; although it seems to work for a FACT rather than an EVEN.

[tatewise]

The FMP file claims to be using GEDCOM VERS 5.5.1 but is breaking a variety of specification details:
EVEN with invalid description text on the same line
PAGE with an invalid CONCatenation tag
SOUR with an invalid REFerence tag
and probably others...
There are also _PRIM Y tags that mean nothing to FH and need to be cleaned.

This is all a fruitless discussion as the FH Merge/Compare File feature discards all such invalid details.
You are unlikely to fix all the invalid cases by manually editing the GEDCOM file.
So, create a new Project, fix any residual problems, such as _REF and _PRIM UDF, and merge from that.

FYI:
If you don't add a Description to Events in FMP then they are valid and do get included by a Merge/Compare File.
More importantly, you are strongly advised to use the standard GEDCOM Census Event (CENS) rather than the non-standard custom Census UK 1... events.

[Normie]

I now appreciate that FMP does not generate a valid GEDCOM vers 5.5.1 file, although it identifies that version in the GEDCOM file. As a result I concede that it is fruitless to discuss this further.

This renders the merge/compare function inappropriate when using FMP as the primary source of information.

Indeed the import from a FMD file exhibits a lack of information being transferred into FH, such as age. Other information such as occupation and where born are not even present in the FMD file.

Given that, I will explore Ancestral Sources as a means of entering census records.

I had looked at merge as being an efficient means of transferring numerous FMD trees into a single FH project.

[tatewise]

You are correct that FMP does not support the AGE field and so you cannot enter Age into a FMP Family Tree.
However, FMP does support the standard Birth Event and associated Place, and the standard Occupation Attribute.
So I don't understand why you say "Other information such as occupation and where born are not even present in the FMP file."
They are certainly present in my FMP Family Tree and in the exported GEDCOM that imports as an FH Project.
Perhaps you meant that those facts are not automatically created when a Census record is entered.
But that is true of every genealogy product that I am aware of including FH.
It is a special optional feature of AS that creates multiple facts from a Census record that can add Birth, Occupation, and other details automatically in addition to the Census event.

[Normie]

In my FMP Family Tree there is only ONE Occupation (and residence). In life, an individual will have multiple occupations and live at multiple addresses. Whist I can change these, there is still only the one you choose as being the most significant. In reality, all occupations an individual has had are significant.

Perhaps I have missed something with FMP.

[ColeValleyGirl]

in my FMP tree, only one occupation is shown on the Overview tab of a pesons full profile, but they are all there on the Facts and Events tab.

[tatewise]

Yes, that is similar to FH where usually only the Birth, Death, Marriage and one Occupation are shown on the Main tab summary of the Property Box, but the Facts tab shows all instances of all facts.

In FH V7, the Occupation that is shown is the instance with the Preferred Flag (or the 1st one if no flag).
In FMP, there is a similar option for setting the Primary Occupation in the Facts and Events tab.

FH has the ability to customise the Main tab to show whatever facts you like including multiple Occupation facts.

[Normie]

I stand corrected.

I now appreciate that you can add a new occupation fact to the individuals profile. In all the years that I have used FMP, the occupation has always been overwritten and only the preferred occupation kept.

Thanks for the information, that will be very useful.