![]() ![]() And you can also rewrite the code that we already have in import & merge so that it can look for UID’s, or other ID’s that are more persistent than the standard Gramps/GEDCOM ID’s and handles. Items will then still have different Gramps ID’s, and handles too, but most of the other differences between GEDCOM dialects can’t influence things then. My take would be different, and that is to run comparisons at the Gramps (XML) level, when most of the harmonization has already been done by the GEDCOM importer. The problem is, that most of these programs are quite dumb, assuming that the GEDCOM files that you work on have quite similar dialects, and that’s not the case with the files that I deal with, where one file comes from my own tree in Gramps, and the other from an on-line service, like Ancestry, My Heritage, or WikiTree, that doesn’t give a dime (replace with your favorite alternative four letter word) about standards. And then my first question is, how can someone recommend such a thing? And I even know at least one, that was recommended on stack exchange, that can’t even load my tree within a reasonable time. There are a few programs that work nice on small trees, but I haven’t found any that can deal with real trees, say of size 10,000 and larger, and allow you to focus on what’s really important. ![]() And I think that, because my experience with GEDCOM comparison is quite bad. I understand that, but I don’t believe that it’s the right way, unless I’m still misunderstanding a few things. But the er_id, wikitree.page_id, and wikitree.privacy TYPE context is completely lost for those 3 REFNs. There is no direct reference to of the GEDCOM.įurther, there are 3 REFN Attributes ( 9567903, 10072967, 60) added to Person for the final parts of the GEDCOM segment for this individual. The Gramps ID for the Individual is I0003 … but that correlation was contingent on being imported into an empty Tree. The Individual attachment is known in the imported data but the NAME attachment is lost. The Note about the misunderstood level ‘2’ Tag is attached to the level ‘0’ Individual but is actually secondary to the level 1 “NAME” for that individual. Continue with line 148 2 CONC />Lawrence county, PennsylvaniaĢ CONT * for Wm. Lines 108-147 are just concatenated line from the Biography. Meanwhile, the original context in the “WikiTree_McCulloughWm1775.ged” GEDCOM source file starts at line 90 and runs through line 155: 0 INDIĢ PLAC Westmoreland, Pennsylvania, United StatesĢ PLAC 136 Boyles ave, New Castle, Lawrence, Pennsylvania, United States Line ignored as not understood Line 93: 2 _MIDN Franklin In the example of a WikiTree GEDCOM being imported, the “GEDCOM import” type Note is attached to the person with the content: Records not imported into INDI (individual) Gramps ID I000003: (The Note attached to the Person object, not to the more appropriate ‘preferred Name’ secondary object of that Person object.) I don’t see how since the Note is not attached as a secondary object to the same object. But it there enough context preserved to restore the data? Or even to do a meaningful post-processing of the ambiguous data. This content is preserved as a Note for the Person. Instead they write a _MIDN custom tag with that portion of the GIVN data. They break out a Middle name in their internal data structure and do not include that name the standard GIVN Given Name value. ![]() That is to say, will the GEDCOM Export write the custom tag back to the same place in the structured data? I had thought I had once stumbled upon a configuration option which allowed the user to by-pass the creation of Notes for problem imports, but I cannot find such an option now, so perhaps I am confused with some other gedcom-capable loader in some other implementation.When the Gramps GEDCOM importer plugin sees a custom tag, it adds the unrecognized content as a Note. It is taking upwards of 45 minutes for the deletes to complete. I understand and appreciate the implementation, but I am working with some rather large imports with rather large numbers of error reports, almost all of which I can simply ignore.Īs far as I know the only way to purge the db of those unwanted Notes, results in a record-by-record delete which is probably done in the context of a transaction with locking and logging overhead. The standard behavior of Gramps is to conveniently create a Note record tied to an INDI or FAM or SOUR record when the gedcom importer detects a problem.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |