yEd limited to import only GEDCOM-tag NAME, sub-tags GIVN and SURN are filtered out

Question

Noticed to my disappointment that yEd only handles the Level 1 tags for INDI-NAME when importing a GEDCOM-formated file. No Level 2 and Level3 tags are imported.

Can not see them in the Data Properties either.

This means that you can not import the maiden-names for females which requires an  awful amount of manual editing.

Is there any work-around for this serious limitation?

It would be nice if the Name-tag and all sub-levels for he Name tag could be entered into Data Properties so it could be handled with regular expressions and Properties Mapper.

.

.

.

0 @I6000000074662690056@ INDI

1 NAME Ulla Maija /Sirén/

2 GIVN Ulla Maija

2 SURN Hannonen

1 SEX F

1 BIRT

.

.

.

 

Answer 1

The only workaround I can think of is adding the additional information you want to display as part of a NOTE tag (or any other tag that is not automatically handled by yEd).

Comments

No plans to add functionality for the possibility to import these sub-level tags in the near future?

Just imagine the effort to manually add NOTE-information for approximately 10.000 individulas just to be able to import name-information correctly. It will take me a life-time

---

I understand that manually duplicating the sub-tags as NOTE structures is not feasible for large data sets. Doing so makes only sense if you can automate the process in some way.

I have added a request for enhancement regarding the parsing of NAME sub-tags to our internal list of of possible improvements for yEd. Due to the tremendous size of that list I cannot make any promises when or even if we will be able to implement this feature in yEd.

To be honest, this improvement has low priority for us - especially considering the fact that even the GEDCOM standard draft release 5.5.1 (the latest GEDCOM specification as far as I know) warns against using NAME sub-tags:

Those using the optional name pieces should assume that few systems will process them, and most will not provide the name piece.

---

It just occurred to me that there might actually be a way to "implement" my workaround with a sensible amount of effort if you come up with a new tag name. If you insert said new tag right after the NAME line, yEd will import your new tag as a custom property. E.g.

0 @I6000000074662690056@ INDI
1 NAME Ulla Maija /Sirén/
1 XXXX
2 GIVN Ulla Maija
2 SURN Hannonen
1 SEX F
1 BIR

where XXXX is my new tag. With XXXX as custom property in yEd, it is possible to extract the desired data using yEd's properties mapper.

While you would still need to do that for each individual, this is actually something that should be possible using an advanced text editor like notepad++ that comes with support for replacing text based on regular expressions. I.e. open the GEDCOM file in text editor, replace all occurances of "1 NAME(.*)" with old value plus newline plus "1 XXXX".

---

Thank you for the prompt response - highly appreciated!

Before I go any further just a comment to the sentence :

“especially considering the fact that even the GEDCOM standard draft release 5.5.1
 (the latest GEDCOM specification as far as I know) warns against using NAME sub-tags:
    Those using the optional name pieces should assume that few systems will process them,
    and most will not provide the name piece.”

This sounds a bit strange !

In accordance to how genealogists write names in a genealogical database the following fields are most often used
- First name (all first names)
    - corresponds to the GEDCOM 5.5.1 tag INDI - NAME
- Given surname (name at birth - like patronymicons)
    - corresponds to the GEDCOM 5.5.1-tag INDI - NAME - GIVN 
- Last name
    - corresponds to the GEDCOM 5.5.1-tag INDI - NAME - SURN 

Genealogists always use name at birth as last name.

These are the only name fields I need.

This is also according to GEDCOM 5.5.1-standards (if I’m not completely wrong)

————————————————————————————————————

The GEDCOM Standard Draft 5.5.1 states the following

The syntax for Individuals is:

1 NAME <NAME_TEXT> /<NAME_TEXT>/ <NAME_TEXT>
    where at least one <NAME_TEXT> must be existing.
    Within the character "/" the surname is located.

Examples:

    1 NAME Ulla  Maija /Hannonen Sirén/

    1 NAME Matti Juhani /Sirén/

No special characters (except "/" as separator for surname) and digits are allowed in NAME.

According to the standard optional further sub-tags may follow NAME to better describe the parts of NAME:

    GIVN    : Given name
    SURN    : Surname
    .
    .
    .

Example:

    1 NAME Ulla Maija
    2 GIVN Hannonen
    2 SURN Sirén

    1 NAME Matti Juhani
    2 SURN Sirén

Said this,
I’m not talented enough to start arguing what’s right or wrong and what’s recommended and who’s not.
Just trying to follow the GEDCOM 5.5.1 standard as close as possible.

So if my expected feature is not going to be implemented - I can live with that.

I’m going to export the GEDCOM-file just once and will do the layout and additional work on the family-tree with yEd through the GUI using all features provided by yWorks.

This will not be a big deal.

I will take your advice as the best way forward and write a tiny script to tailor my GEDCOM-file so I can keep the name-structure the way I see right.

Yet again - thanks for your time and input on this matter.

---

Do not worry, I do not take your reply as arguing. I probably should have given a reference where to find the warning against NAME sub-tags in the GEDCOM standard, though. So, for completeness sake: you will find the quoted warning in the definition of PERSONAL_NAME_STRUCTURE page 38 of GEDCOM standard draft release 5.5.1.

Note, the warning refers to using NPFX, GIVN, NICK, SPFX, and SURN sub-tags, it does not refer to the formatting of the NAME tag value.

---

You are right. Missed that warning.