Incompatibiliy with the MacFamilyTree export of GEDCOM places?

Help
,
1

Does anyone have MacFamilyTree and able to export sample GEDCOM data from it?

A new user on Facebook reports that the GEDCOM being exported by MacFamilyTree has Place data that is mangled during Gramps import. The user is doing the usual “you should be able to infer the whole problem from this scrap of data”

The particular example had a Place or Event set to “Dundas,Kent County,New Brunswick,Canada”. It comes in as the state of “New Brunswick” with an enclosing place (probably Canada) and an alternative name with the full title.

image
image590×506 61.3 KB

The developers of RootsMagic and Heredis seem to have encountered whatever idiosyncratic syntax is used to describe Places (or Places in Events) by MacFamilyTree. They built a special GEDCOM import decoders for whatever that particular non-standard implementation happens to be.

The MacKiev site says places are customizable through “place templates” and “customizable administrative levels,” which suggests a unique approach to hierarchical place modeling inside the app. And implies they use custom GEDCOM tags in the export.

A data sample of the GEDCOM would tell us exactly what MacKiev chose to do. (And whether this was their GEDCOM7 or 5.5.1 export.) With that, we would have a better idea if it warrants a tweak the GEDCOM, the importer, or post-processing the screwy imported data

2

MacFamilyTree v.11.2.3
I have exported for one person only. Since MTF can export to GEDCOM 5.5.1 and 7.0.3 there are two files.
The data has not been entered into MTF, but imported from a Gramps export GED file.
MTF-5.5.1.ged (38.1 KB)
MFT-7.0.3.ged (37.7 KB)

3

Thanks @csam!

Ahhhh. I see what they are doing and why the data is coming in oddly. Their FORM defines the enclosing order of Administrative Division types of the CSV data. And it uses localized Administrative Divisions for its Place hierarchy. Meanwhile, Gramps only recognizes English types as having innate Level structure. (Custom Types have no innate Level structure)

And the Parser does not even recognize the localized Administrative Divisions as being custom types. So the full CSV is preserved as an ‘alternative name’ of the deepest recognized Administrative Division element.

So we are not doing the appropriate thing with the unrecognized. Administrative Divisions found in the FORM tag.

Ideally, it would use that data to expand the (Level unknown) Custom Types list (wherever necessary) and use the CSV order to set the hierarchy for that specific PLAC object. Both on a case-by-case basis.

So for the example below, the Parser would have to recognize “Country” but add Custom Types for “Regioner”, “Kommuner”, and “Place” before importing the actual Strings for the placenames:

Danmark (Country)
  Frederiksborg Amt (Regioner)
    Holbo Herred (Kommuner)
      Græsted Sogn (Place)

GEDCOM5.5.1

1 EVEN Flytter til Esbønderup
2 DATE 16 MAY 1852
2 TYPE Flytning
2 PLAC Græsted Sogn,Holbo Herred,Frederiksborg Amt,Danmark
3 FORM Place,Kommuner,Regioner,Country
3 MAP
4 LONG E12.280000000000001
4 LATI N56.065999999999995
2 _COR
3 _LAD 56
3 _LAM 3
3 _LAS 57.6
3 _LOD 12
3 _LOM 16
3 _LOS 48
2 SOUR @S0007@
3 PAGE Niels Aggebo, afgangsliste
3 NOTE @N0844@

GEDCOM7

1 EVEN Flytter til Esbønderup
2 DATE 16 MAY 1852
2 TYPE Flytning
2 PLAC Græsted Sogn,Holbo Herred,Frederiksborg Amt,Danmark
3 FORM Place,Kommuner,Regioner,Country
3 MAP
4 LONG E12.280000000000001
4 LATI N56.065999999999995
2 SOUR @S0007@
3 PAGE Niels Aggebo, afgangsliste
3 NOTE @N0844@
4

… and to make things more complicated
The division of Denmark into ‘Kommuner’ (Municipalicies), ‘Regioner’ (Regions) and ‘Land’ (Country) is still quite new - this division is from 2007.
From 1970 Denmark was divided into ‘Kommuner’, ‘Amter’ (Counties) and ‘Land’.
Before 1970 Denmark was devided into ‘Sogn’ (Parish), ‘Herred’ (Shire), ‘Amter’ and ‘Land’.

So for the above example the FORM should have been

FORM Sogn, Herred, Amt, Land