/Van Egmond/ mangled to /Egmond/ by gedcom import

Question

In connection with the Ontario project, I wanted to import details on Col. Anthony Van Egmond and his descendants.  However, all with the last name Van Egmond appear as "Egmond" in the import (120982).  

Why?  Is there some way to fix this problem?

One of Col. Van Egmond's grand-daughters is in WikiTree [1] but GedCompare doesn't find a match due to the mishandling of the last name.

[1] https://www.wikitree.com/wiki/Van_Egmond-83

Craig

Answer 1

The automated search system here has limitations. And it would appear that the software that created your Gedcom didn't interface well with the WikiTree algorithms that interpret Gedcoms. (The Gedcom "standard" isn't really a standard, so this sort of problem is not uncommon.)

Some of us WikiTreers have had an annoying habit of nagging people to search WikiTree for duplicates (don't just rely on the automatic searching) before creating new profiles, particularly for long-ago people (when spelling was highly variable and dates are often just guesses) and for names that are subject to variation (like Van Egmond vs. Egmond). Unfortunately, that's something you need to do in this situation.

Also, note that when you create a new profile using Gedcompare, you can (and should) correct errors, including the spelling of the last name, before you create the profile.

Comments

Such surname prefixes are not exactly uncommon and I know other software is able to parse this construct properly.  I think WikiTree should put some more effort into this.

I've read repeatedly now how people abandon gedcom uploads and manually enter all the details.  Sorry, but my time is precious and I know I'm not alone!  I think WikiTree might be more popular and attract more contributions by doing more upfront work to smooth out the gedcom import process.  (See also my other thread on date problems.)  This isn't rocket science.

---

WikiTree has thousands of profiles created from Gedcoms that have surnames similar to Van Egmond, and that were created without glitches in the surname. This is why I believe that the problem you encountered is related to some unusual interface problem between your Gedcom and the WikiTree software that parses Gedcoms.

---

I see on that other G2G question of yours that the surname Van Egmond was created in your file as two separate data fields:

2 SPFX Van
2 SURN Egmond

I believe that most imported Gedcoms with that type of surname have
placed the complete surname in a single SURNAME data field, separated by a space. SPFX may not be a universal feature of the GED data structure.

Perhaps the programmers here can advise on how the WikiTree gedcom-import software is supposed to handle the SPFX field, and see if the behavior can be improved.

---

For this person's name, my gedcom contains

0 @I2513@ INDI

1 NAME Susan /Van Egmond/
2 GIVN Susan
2 SPFX Van
2 SURN Egmond

I found a copy of the Gedcom 5.5 standard (pdf) at:

http://phpgedview.sourceforge.net/ged551-5.pdf

The NAME tag is discussed on p. 37-38 and says that the level 2 tags (GIVN, SPFX, SURN) are optional.  It specifies that the family name (surname) be separated by slashes, which is the case in the Gramps gedcom.  

WikiTree's parser is broken since it doesn't pick out /Van Egmond/ in the NAME record.  If it wants to make use of SURN, then it ought to handle the other level 2 tags.

How do I report a bug to WikiTree?  Do the devs monitor this forum?

Craig

---

The folks responsible for the software do monitor this forum, but I'm not sure that this particular thread (nor your other one) will get their attention. (And, unfortunately, they are running behind on implementing priority software improvements due to the distractions created by the need to make major changes to comply with the European Union's GDPR.)

I suggest that you assemble a report documenting the elements of your Gedcom that you think were parsed incorrectly, then post a question in the WikiTree Tech area of this forum with a title that succinctly summarizes your request for improvements to the parsing of Gedcom imports. Use the tags gedcom, gedcompare, improvements, and bugs.

Answer 2

I don't know much about Gedcoms so I can't speculate on what happened ... someone will know.

Anyway, one solution is to go to those profiles and change the Last Name at Birth (LNAB) to Van Egmond ... open the profile, click edit, about five entries down is the LNAB and, if you're the manager, there will be an 'edit' link on the right ... click that and input Van Egmond and save.  Hopefully you don't have too many of these profiles to change!

Note that Wikitree will put an underscore in place of the space but the profile will display correctly ...