So in this thread someone reccomended importing from TMG to RootsMagic and then to Gramps via GEDCOM:
(Dont go there because it got locked becuase it became off topic)
When I import the GEDCOM Files, There are like 2k errors that come. There are different kind of Errors. 1. On Families, All the errors looks like these:
Records not imported into INDI (individual) Gramps ID I0100:
Line ignored as not understood Line 1825: 2 _PRIM Y
Line ignored as not understood Line 1829: 2 _PRIM Y
What do that mean?
2. And on sources the errors looks like these:
Records not imported into SOUR (source) Gramps ID S0007:
Line ignored as not understood Line 2581: 1 _SUBQ , <I></i>.
Line ignored as not understood Line 2582: 1 _BIBL . <I>1900-telling for Bergen. Ikke kval.sikret at det er riktig person</i>. : .
Line ignored as not understood Line 2584: 1 _TMPLT
Skipped subordinate line Line 2585: 2 TID 10000
Skipped subordinate line Line 2586: 2 FIELD
Skipped subordinate line Line 2587: 3 NAME Title
Skipped subordinate line Line 2588: 3 VALUE 1900-telling for Bergen. Ikke kval.sikret at det er riktig person
Skipped subordinate line Line 2589: 2 FIELD
Skipped subordinate line Line 2590: 3 NAME ShortTitle
Skipped subordinate line Line 2591: 2 FIELD
Skipped subordinate line Line 2592: 3 NAME Author
Skipped subordinate line Line 2593: 2 FIELD
Skipped subordinate line Line 2594: 3 NAME PublishDate
Skipped subordinate line Line 2595: 2 FIELD
Skipped subordinate line Line 2596: 3 NAME Publisher
Skipped subordinate line Line 2597: 2 FIELD
Skipped subordinate line Line 2598: 3 NAME PublisherAddress
Skipped subordinate line Line 2599: 2 FIELD
Skipped subordinate line Line 2600: 3 NAME CD
That spesifc Source ends up looking like this, this is the only of the sources in this spesific tree that ends up having no references at all, all others do have it.
There are some missing photos in others, from my understanding, TMG did store media files in the project file itself, do that also mean that they also are inside the backup file of a project? because if not I can only consider them lost, if they are, then I can try to get them
3. And finally there is these ones that I have no idea what is:
Records not imported into Top Level:
Unknown tag Line 4785: 0 _EVDEF Parent-Fst
Skipped subordinate line Line 4786: 1 TYPE P
Skipped subordinate line Line 4787: 1 TITL Parent-Fst
Skipped subordinate line Line 4788: 1 ABBR Parent-Fst
Skipped subordinate line Line 4789: 1 SENT NEED TO DEFINE
Skipped subordinate line Line 4790: 1 PLAC Y
Skipped subordinate line Line 4791: 1 DATE Y
Skipped subordinate line Line 4792: 1 DESC Y
The format for GEDCOM tags each chunk of data. Programs are supposed to use STRICTLY standardized tags.
But since GEDCOM is primitive & doesnât support many modern features, many applications create non-standard custom chunks that only they read & write.
That is your unknown tag. The subordinate lines are all the attributes within that unknown tag ⌠or until the next Standard tag is found.
My guess on the PRIM Y lines in the INDIvidual tagged chunks is that it appears to a custom attribute. Possibly the person is marked as related to the primary âYâ line. As in XY (male) chromosome pair 23. So part of the patrilineal lineage.
Possibly the doubles are direct ancestors of their equivalent of a Home Person. While singles could be any descendant of the line Progenitor.
Hey! Any crappy theory postulated is better than no theory at all. Disprove by finding several INDIviduals with different PRIM Y levels. Then compare & contrast⌠with an eye to the theory postulated.
The _PRIM tag is non-standard, usually it means to use the associated media item as the persons photo, but if it is subordinate to some other tag (not OBJE) I donât know what it means. Recent versions of Gramps should be supporting this if under the OBJE.
_SUBQ, _BIBL, _TMPLT, _EVDEF are all non standard tags, I have no idea what they mean. And anything subordinate to those (with greater âNâ in front of the tag) is skipped because Gramps doesnât know what to do with it in context.
That costs money, and I dont know what difference it would makeâŚ
Everyone is Y, all indeviduals and all families
In the Gedcom file they are like this:
0 @I203@ INDI
1 NAME Karl Ulrik /Gaustad/
2 NPFX DS-fører
2 GIVN Karl Ulrik
2 SURN Gaustad
1 SEX M
1 _UID 283A75F7D4B543789F72D6F74BB69F0595E2
1 CHAN
2 DATE 1 NOV 2020
1 BIRT
2 _PRIM Y
2 DATE 5 APR 1861
1 CHR
2 DATE 26 MAY 1861
2 PLAC Trondheim
2 ADDR Frue Kirke
1 DEAT
2 _PRIM Y
2 DATE 3 DEC 1898
1 REFN 203
1 FAMS @F81@
1 FAMC @F96@
Should I just ignore it? Also, anyone know what the _UID is? In Gramps it comes up under Attributes. REFN also comes up there but I am guessing that stands for Reference Number and is just one of the two programs ID number. Maybe _UID is the same thing just the other program? So maybe I should ignore it.
This is an example of where _EVDEF is in the GEDCOM file:
0 _EVDEF Military
1 TYPE P
1 TITL Military
1 ABBR Military
1 SENT [person] served in the military< [Desc]>< [Date]>< [PlaceDetails]>< [Pl
2 CONC ace]>.
1 ROLE Witness
2 SENT [ThisPerson] witnessed the military service of [person]< [Date]>< [Plac
3 CONC eDetails]>< [Place]>.
1 ROLE Witness
2 SENT [ThisPerson] witnessed the end of military service of [Person] <[Date]
3 CONC > <[Place]>.
1 PLAC Y
1 DATE Y
1 DESC Y
0 _EVDEF Mission
1 TYPE P
1 TITL Mission
1 ABBR Mission
1 SENT [person] served a mission< [Date]>< [PlaceDetails]>< [Place]>.
1 ROLE Witness
2 SENT [ThisPerson] witnessed the mission of [person]< [Date]>< [PlaceDetails]
3 CONC >< [Place]>.
1 PLAC Y
1 DATE Y
1 DESC Y
Maybe those are to ignore.
Maybe Y means that the field was empty?
Example on other ones in the GEDCOM file:
0 @S18@ SOUR
1 ABBR RHD digitalarkivet. 1900-telling for Ă lesund
1 TITL , <I>RHD digitalarkivet. 1900-telling for Ă lesund</i> (: , ).
1 _SUBQ , <I></i>.
1 _BIBL . <I>RHD digitalarkivet. 1900-telling for Ă lesund</i>. : .
1 _TMPLT
2 TID 10000
2 FIELD
3 NAME Title
3 VALUE RHD digitalarkivet. 1900-telling for Ă lesund
2 FIELD
3 NAME ShortTitle
2 FIELD
3 NAME Author
2 FIELD
3 NAME PublishDate
2 FIELD
3 NAME Publisher
2 FIELD
3 NAME PublisherAddress
2 FIELD
3 NAME CD
Records not imported into SOUR (source) Gramps ID S0018:
Line ignored as not understood Line 2826: 1 _SUBQ , <I></i>.
Line ignored as not understood Line 2827: 1 _BIBL . <I>RHD digitalarkivet. 1900-telling for Ă lesund</i>. : .
Line ignored as not understood Line 2828: 1 _TMPLT
Skipped subordinate line Line 2829: 2 TID 10000
Skipped subordinate line Line 2830: 2 FIELD
Skipped subordinate line Line 2831: 3 NAME Title
Skipped subordinate line Line 2832: 3 VALUE RHD digitalarkivet. 1900-telling for Ă lesund
Skipped subordinate line Line 2833: 2 FIELD
Skipped subordinate line Line 2834: 3 NAME ShortTitle
Skipped subordinate line Line 2835: 2 FIELD
Skipped subordinate line Line 2836: 3 NAME Author
Skipped subordinate line Line 2837: 2 FIELD
Skipped subordinate line Line 2838: 3 NAME PublishDate
Skipped subordinate line Line 2839: 2 FIELD
Skipped subordinate line Line 2840: 3 NAME Publisher
Skipped subordinate line Line 2841: 2 FIELD
Skipped subordinate line Line 2842: 3 NAME PublisherAddress
Skipped subordinate line Line 2843: 2 FIELD
Skipped subordinate line Line 2844: 3 NAME CD
Gramps has a similar system of 2 IDs per object. We have a short (User changeable) ID that you can also type into Search filters. But thereâs also a looOOooong hexadecimal string which is the (immutable) internal handle. Those internal handles make it possible to renumber IDs without worrying about messing up the Tree.
For instance, the hyperlinks in Notes are based on the internal handle rather than the ID. So a merge doesnât have to worry about scanning hundreds of text notes for broken links every time you merge anything.
Did you notice that the REFN was the ID text string found between the @ (âatâ) symbols with the leading Alpha stripped off? Just a numeric representation of an ID. Doing searches & sortd with a number is a lot faster than a text string.
When you interpret that source record, youâll notice that it is a Bibliographic record with most of the reserved fields left blank. But it does tell you that the reference is from the Digital Archives (Digitalarkivet); which is the Norwegian National Archivesâ channel to publish parts of their archive material. In this case, it seems to be a CD-ROM with the 1900 telling ( Norwegian Google translates âtellingâ as âcensusâ) from Ă lesund, archived by the Registreringssentral for historiske data (Registration Center for Historical Data; or RHD).
The _UID is a way to uniquely identify people, families etc. The current versions of Gramps doesnât support this, but an upcoming version will (someday). When supported, the attribute will get converted appropriately. You can ignore these; the feature would only come into play when merging data from other GEDCOMs that were in some way related to your original one. Which would only happen if you are collaborating with people.
It looks like the _PRIM is a way to identify the preferred Birth/death etc. record. Which implies that there may be more than one such record supported by the program. I think these can be safely ignored. Gramps will import all records, but will assume the first of any given type is the primary (preferred).
The program that exported the GEDCOM file may have options on how to make the file. Usually the GEDCOM is exported so that when imported by the same program, minimal or no data is lost. But other options may make the export more compatible with other programs, like Gramps.
Most of the lines that Gramps doesnât handle can be ignored, but those that contain obviously useful data may need some attention. These should end up in notes attached to the nearest associated object. So you can look for notes where this occurred and edit them to make the data more readable if you wish.
The point was that a LOT of that information had named fields. But the appropriate information was not in the named fields.And the part you did not notice was NOT in a named field.
So that mean the person who filled in the database in TMG was not following standards. Importing becomes exponentially less reliable when information isnât in the prepared places. Even if the GECOM import was tweaked to recognize TMGâs dialect, TMG info in the wrong place would flow to another wrong place in Gramps.
After looking, its CD on every single source, but its not the type of source as that is listed as Book. My grandad either had all the sources on a CD or it just dont mean anything.
I just tried and either TMG do not store media files in the backup file or he did not add them to the program itself, I dont know because they are not there. Will have to consider them lost or try something else. Might have also be messed up as I first converted it from TMG 6 to TMG 9 and then got the things from that because I had to.
You might want to look around for a small library of CDs. It could be that a lot of those reference books were downloaded & offloaded to removable media. (CDs or thumb drives)
(Hopefully, other relatives didnât mistake them for bootleg music CDs or âmix CDsâ and dispose of them.)
Such a collection would be a welcome discovery⌠one that would save you a lot of effort in the future.
One of the early genealogy programs (Family Tree Maker ??) had a collection of CDâs that provided many references that are now available in other forms . Some of the CDâs also offered user submitted GEDCOMS.
Did a search on my local libraryâs catalog using âFamily Tree Makerâ as the search term and at least one library in the consortium still has a collection of these CDâs.
Iâve been wondering if a good Gramps enhancement would be a facility for allowing users to do some custom mapping of GEDCOM tags to Gramps data elements for purposes of importing and exporting.
No, In gramps, the sources do have citations that point to people/events.
Looks like to me that TMG specify the name of the CD field in the Source but the contents of that field is not.
Whatever is the Citation Detail field in TMG, ends up the Volume/Page field of a citation in Gramps, and is not shown in the error lnote on that source. But I then wonder why the CD is even added to the GEDCOM file at allâŚ
Well, dont know what is TMG and what is because RootsMagic, as it was Rootsmagic that created the GEDCOM but data is from TMG, or i it is just both.
