This project is read-only.

Missing Relationships from export

Dec 7, 2009 at 6:58 PM
Edited Dec 7, 2009 at 7:01 PM


I've got my family tree exported from, but lots of people are missing the relationship between the children and thier mother - i.e. only the father is shown.

It looks like the code in GedcomImport.ImportFamilies only adds the relationship details to the husband, if present. If the husband is not present then the children info is added to the wife.

This doesn't work if there is no marriage info between the husband and wife - the info is added to the husband, and as the husband is not-null then the child info is not added to the wife.

I originally fixed this by changing


if (husbandPerson == null && wifePerson != null & childPerson != null)
                        RelationshipHelper.AddChild(people, wifePerson, childPerson);

to be

if ((husbandPerson == null || husbandPerson.GetSpouseRelationship(wifePerson) == null)
                            && wifePerson != null & childPerson != null)


- that means that the links between the children and their mothers in the tree now show up.

However, the marriage link is missing.


The real problem is that genesreunited is writing out the family info out to the GEDCOM:


0 @F517@ FAM

1 HUSB @I1839@
1 WIFE @I1837@
1 CHIL @I1841@
1 CHIL @I1842@
1 CHIL @I1840@


but ImportMarriage is failing as genesreunited doesn't write out a MARR tag as there are no details entered (it's dead easy to create a marriage in genesreunited without bothering to enter any of the marriage details).

As we know about the marriage from the FAM tag we should instead fix up the marriage. I changed GedcomImport.ImportMarriage to be:


DateTime? marriageDate = null;
            DateTime? divorceDate = null;
            SpouseModifier modifier = SpouseModifier.Current;
            // See if a marriage (or divorce) is specified.
            if (node.SelectSingleNode("MARR") != null || node.SelectSingleNode("DIV") != null)
                // Get dates.
                marriageDate = GetValueDate(node, "MARR/DATE");
                divorceDate = GetValueDate(node, "DIV/DATE");
                modifier = GetDivorced(node) ? SpouseModifier.Former : SpouseModifier.Current;

            // Add info to husband.
            if (husband.GetSpouseRelationship(wife) == null)
                SpouseRelationship husbandMarriage = new SpouseRelationship(wife, modifier);
                husbandMarriage.MarriageDate = marriageDate;
                husbandMarriage.DivorceDate = divorceDate;

            // Add info to wife.
            if (wife.GetSpouseRelationship(husband) == null)
                SpouseRelationship wifeMarriage = new SpouseRelationship(husband, modifier);
                wifeMarriage.MarriageDate = marriageDate;
                wifeMarriage.DivorceDate = divorceDate;


And this fixes the missing relationships from my tree. Will this (or a variation on this) make it into the next release?

Also, as an aside, there don't seem to be many checkins to this project - what's the deal if I wanted to contribute?




Dec 7, 2009 at 7:56 PM


There were some logic problems when importing GEDCOM files in version 3.

The issue you describe is quite tricky to solve but if you dowload the preliminary release of version 4 on the Source Code tab, these issues are hopefully fixed.

If not, post back and I'll try to help.



Dec 8, 2009 at 6:09 PM

Hi Elyoh,

Thanks for the reply - I got hold of version 4 and the issues are fixed ;-) It's looking good!

There are a couple of minor features I wouldn't mind - when the GEDCOM dates are parsed, info on whether the date was approximate (ABT or a quarter) is lost, ABT 1836 gets turned into 01/01/1836. It'd be good to see on the UI whether a date is approximate. Also, my GEDCOM is malformed with lots of bad dates - it'd be great to get these as an optional report with warnings on import.

Parsing my (admittedly very malformed) GEDCOM was quite slow, with only 400 individuals, - there are loads of FormatExceptions thrown (and caught). I don't know whether you can use TryParse in lots of places? Just by replacing the DateTime.Parse in GedcomImport.GetValueDate reduced the time to import from 18 seconds to 12 seconds.






Dec 8, 2009 at 10:29 PM

There are definately some performance issues with GEDCOM import and large family collections in general.  I have looked at this and it is due to the type of object collection used to store people and families.  It gets a little bit slower for each person added to the file.  After 400 people the issue can be quite bad.  In fact extracting dates from GEDCOM can be a complete nightmare!!

Clicking the Date of Birth, Date of Death labels in Details panel changes the date description ABT to BEF to AFT.  ABT 1836 should be imported as ABT 01/01/1836 so I'll check this later.  If you don't mind sharing you file via personal message, it would be useful to track the performance issues and the loss of data.  Inevitably some data will always be lost in transfer.

Hope that helps





Dec 10, 2009 at 9:11 PM

Hi elyoh,

Thanks for the reply. It'll take me some time, but I'll try to strip out/replace the personal information out of my GEDCOM and send you a copy. My 400 relation GEDCOM is quite small - most of the others I've seen on genesreunited range from 1000 to 4000 individuals.

My number one feature, out of any genealogy software, is don't lose my data! If it has an import and export GEDCOM function, I'd expect that I can import a GEDCOM and export it straight out without losing any information - if the application doesn't know what to do with any of the data it should keep a note of it but otherwise ignore it, for export. Of course, any extra stuff the application can do (marking relatives on maps etc) may be lost, but I'd take the GEDCOM to be the lowest common denominator. I got burnt with some other software that ruined my GEDCOM file.

Thanks again,


Dec 10, 2009 at 10:13 PM

 I appreciate those concerns.  I would like to see an all singing all dancing program which can handle all GEDCOM info but to put this in perspective, I'll just include a quote about Family.Show from the Vertigo site:

 "Your friends told us Family.Show is a compelling, enjoyable experience and is unlike any other genealogy application out there, and that makes us extremely happy! But please keep in mind that Family.Show is not a “real product”. It’s more like a concept car that we built for geeky programmers and designers so they can poke around under the hood and test-drive some new and exciting Microsoft technology."

The contributions I have made to this project have given some momentum to providing a new release with some nice demonstration functions plus some bug fixes.  It's more of a program to show off your family tree visually rather than be a replacement for a GEDCOM editor.  But Family.Show won't ruin your original GEDCOM file.  It reads the info from it, and stores what data it can support in a new *.familyx format.  The original file will be absolutely unaltered.  I agree that perhaps appending all the unused info to the person's note would be a better compromise - I'll see how easily this can be done.


Dec 13, 2009 at 3:52 PM

Hi elyoh,

I understand the purpose of the project, I guess 'cause some GEDCOM bugs had been fixed, and you mentioned that you wanted to improve performance, that I got a bit carried away! is already much more appealing than any other genealogy application that I've used, there are just a few things stopping me from using it in anger which is a shame. It's almost enough to inspire me to write my own version, but that would be a massive amount of work, and seeing the amount of work that's gone into, and the fact that it's hosted on codeplex and is open source, I kinda of thought that maybe you'd be open to the community to contribute features?

I can also see the other side though - the intent of the project is to be a showcase demonstrating cool Microsoft technologies, with clear easy-to-understand code, and you wouldn't necessary want to pollute the codebase with stuff with goes against that intent, or have the time to review user's contributions.

Would the license (MSPl?) allow for a community edition fork of the project? Or if you really didn't want that to happen, at least if the project was written with the right set of extension points it'd allow users to add to the project in a safer way (there are a number of features I can think of that would be great for just visualizing the data, not editing - on another thread someone showed mapping functionality - that would fit neatly into an addin).

I hope I haven't rambled too much, and you can see my excitement (with a bit of bitter-sweet disappointment ;-) ). I wasn't having a go or anything, I think it's an amazing app (I initially came across it a couple of years ago before I was into genealogy, when getting to grips with WPF, so it definitely serves its purpose as a demo app!!!)



Dec 14, 2009 at 3:33 AM

The license is vague but I don't think that is prohibits forking the project as long as it still includes the license. You also may need to remove the Vertigo trademark. There are already a couple forks which I know about such as ActiveDirectory.Show and A Biblia Falada but they aren't for family trees. Technically, Codeplex is open-source but as this project was developed for Microsoft and is meant as a reference, it seems to be a little more restrictive. If you decide to start another branch of this project, please let us know.

Also, elyoh has developed a type of mapping functionality included in version 4 if you are interested in the source code tab.