Create arrays for empty duplicate properties with sub-properties that have values

[alexc155]

(Apologies - this is a continuation of the previous pull request that I accidentally closed)

---

Issue #32 talks about multiple EVEN elements with no value that have sub-elements with values. The problem can be reproduced with:

0 @I1@ INDI
1 NAME John /Doe/
1 EVEN 
2 TYPE Census
2 PLAC London, England
1 EVEN
2 TYPE Employment
2 PLAC Paris, France
0 TRLR

Actual Outcome:

{
 "Individuals": [
  {
   "Id": "@I1@",
   "Fullname": "John /Doe/",
   "Events": {
    "Type": [
     "Census",
     "Employment"
    ],
    "Place": [
     "London, England",
     "Paris, France"
    ]
   }
  }
 ]
}

It's not possible to tell whether the Census event happened in London or Paris. The same for the Employment event.

Expected Outcome:

{
 "Individuals": [
  {
   "Id": "@I1@",
   "Fullname": "John /Doe/",
   "Events": [
    {
     "Type": "Census",
     "Place": "London, England"
    },
    {
     "Type": "Employment",
     "Place": "Paris, France"
    }
   ]
  }
 ]
}

The problem appears to happen when there is no value for the EVEN tag. I think that the second instance of the tag doesn't create an array of them as I might expect it to.

The YAML property CollectAsArray looks like it should fix this - but that only works on top level elements like INDI. The property has no effect on sub-elements like EVEN.

If you set the StartWith property to a value like "-" for EVEN it sort of fixes it - but all Events then contain a Value property set to "-" and it only affects that one tag - MARR tags still suffer from the same bug.

To fix this, the pull request submitted introduces a new property to the ParsedLine class called NoValue. If the GEDCOM line doesn't have a value part, then the NoValue flag is set to true and a placeholder value is set on the ParsedLine.

Later, this flag is used to identify the manipulated entries that had no value and remove the placeholder value so that it doesn't appear in the output.

---

Hi,
This seems to be already be working via the configuration without any code changes.

  - Tag: EVEN
    CollectAs: Events
    Property: Name
    Properties:
      - Tag: TYPE
        Property: Type
        MergeWithLast: EVEN
      - Tag: PLAC
        Property: Place
        MergeWithLast: EVEN

I'll add this to the default configuration yaml. Can you confirm that this works or do you have further problems?

---

Hi,

Thanks, your changes work great for the particular example I chose, but aren't generic enough for all tags.

It works for the EVEN tag, but what if the duplicates are for the Marriage MARR tag e.g.

0 @I1@ INDI
1 NAME John /Doe/
1 MARR
2 PLAC London, England
1 MARR
2 PLAC Paris, France
0 TRLR

Or a Divorce DIV tag?

0 @I1@ INDI
1 NAME John /Doe/
1 DIV
2 DATE 8 Aug 1913
1 DIV
2 DATE 10 Sep 1916
0 TRLR

Or any other tag that supports no value on the actual line and sub-tags?

The benefits of being able to define just one DATE tag in the YAML are lost because you now have to specify them many times under each tag that supports sub-tags.

[Jisco]

Hi,
yes, I understand the problem.
Unfortunately, the approach in this PR is too far-reaching for me, as I think you can see from the test on the "RESI" tag.

How about a different approach: you can mark certain TAGs with a property and these TAGs are therefore always assumed to be mergeable?

See PR: master...automerge-properties

To do this, the corresponding properties are simply mirrored, meaning that only a very small change needs to be made to the code for parsing.

What do you think?