I have a lot of information in the NOTE section of a family tree and would like to be able to import it all easily. I will work on implementing this and posting a patch. I am reading the documentation for both the module & GEDCOM, and I'm having a bit of trouble slogging thruogh it all.
Currently it appears that each concatenation tag (CONC) is read in as its own fact. I would (if given no input) probably create a patch that combines the CONC tags into the preceding/parent tag and saves it there. Is there a reason I shouldn't do this?
Also, I will put a spot on the display for Notes.
Comments
Comment #1
seth.e.shaw commentedOddly enough, I have been working on the CONT/CONC fact bit lately. I think I have the kinks worked out although it does need some more testing before being submitted to the repository. (It is included below) I haven't been able to get the Source as node working well enough to check the update/new functionality while integrated into the module although my controlled tests seemed fine. I think part of the problem is that I am also trying to integrate the Source notes with the Source node body.
Basically, we are trying to follow GEDCOM fairly closely which places a character per line, i.e. fact, cap (147 I think) with no newlines. CONT tags were created to represent the start of a new line and CONC tags were created to continue excessively long strings. Another reason this is needed is that Notes are not the only tags that allow continuation through CONT & CONC. Many others such as addresses permit them as well. We need functions that work for both Notes and these other facts.
So, when a note is read it needs to find the parent tag, then all the subordinate CONT and CONC tags, and then string them together inserting a newline break when it encounters the CONT tag. Also, when we create a new note or update an existing one we then need to break down the string by the new lines (the CONT tags) and then if those resulting strings are still too large, break them into CONC tags.
These strings then have to be inserted into the database respecting the order of fact_ids (the only sort mechanism we have right now; ugly, I know, but all we have). Otherwise, when they are called back out they might not be in order when reassembled. I try to conserve database inserts by recycling existing facts, changing the fact_code if need be.
Comment #2
Tistur commentedThat really helps.
A super quick hack of family_line_indi at least shows me the notes. I'm not sure why I have to add 1 to the fact id - this may be because my GEDCOM generator is fairly old.
Next piece to work on: putting facts into the node body for the person. Would the tables have to change on editing a node, or would it suffice to change the tables once before an export?
After that, maybe a checkbox when importing to turn this on and off.
Comment #3
Tistur commentedComment #4
pyutaros commentedSetting to fixed.
Comment #5
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.