Migrating from Gensdata Pro

Help
1

(Gramps 5.1.6 / Windows 11)

My father has spend his last twenty odd years on building the Paternotte family tree. He’s getting pretty old now and is loosing touch with many things in life, including computing. It looks like that I need to take over his administrative legacy.
Dad has always used Gensdata Pro, which is the genealogy software program from the Dutch Genealogy Association (NGV).
Gensdata Pro originates from ye ole MS-DOS era and has grown and grown to date with numerous extensions and added features. Apart from a ‘Windowsification’ I don’t think it has ever gone through a thorough rebuild from scratch, so we can imagine the Spaghetti-monster here. It does not adhere to Windows application standards (e.g. installs in c:\ and requires admin rights) and as such I am reluctant to continue dad’s work within that environment. I think I need to take up the task of migrating to something more up-to-date and open source, such as Gramps.

I want to start off with generating a GEDCOM export from Gensdata Pro. What options should I enable to smoothen the subsequent import in Gramps?

When I import this GEDCOM into Gramps, what challenges should I expect?

Dad’s GDP-database includes a large number of images. What’s the best way to transfer these?

Dad’s Paternotte family tree includes large branches of other families. E.g. from the 2nd generation, the database called “Paternotte” includes the full ancestry of grandmother “Horst”. What is the recommended method of structuring family trees into seperate databases?

Thanks in advance, Stephan

2

I have no idea what options you have in the legacy software you have. The best is to try exports and imports until you find the right mix. In gramps you can create as many database versions as you need.
You will have to carefully check that nothing gets missed. The images will have to be manually copied to the gramps media folder.

1 Like
3

Welcome Stephan!

There is only a single thread with of the GensData (or GensData Pro) tool in the old maillist archives. That is a brief mention by @ennoborg as one of the genealogy tools used in the Netherlands. There is not detail.
The process of GensData export in GEDCOM dialect and import into Gramps is not yet described in the “Import from another genealogy program” wiki article.

In a long rambling review more than 12 years ago by Tamura Jones, the developer is chastised for charging a fee for GEDCOM export. And also for having a 2-stage process (database to XML, XML to GEDCOM) that runs out of memory with medium to large datasets. One hopes that most of his complaints have been addressed in the last dozen years.

Another Gensdata user reports that their exported GEDCOM definitely uses custom tags. Gramps probably won’t recognize those but will instead store them as Notes… which allows post processing.

Of particular ethnic importance is the _PATR tag for identifying Patronymic surnames. That would be an issue common before Napoleonic invasion (1795) and annexation (1811) when surnames became codified.

So it would be reasonable to start with some sample GEDCOM data from Gensdata Pro and see what other custom tags will have to be handled. Perhaps some can be handle before import and maybe the one of the other GEDCOM dialect handlers recognize others.

If the Gensdata database links images to online folders, there is a free DownloadMedia addon. If the files are local, there is a free Media Verify Tool addon. These are used after import.

To move the Gramps database and images to another computer, the backup packs both the media objects and the tree database into a compressed .gpkg format archive. After installing Gramps on the destination machine, create a new tree and import the .gpkg format archive.

The consenus has been to recommend against segmenting into separate lineage databases.

Generally, there are interconnections between ancestors, not just between modern spouses. In close-knit communities, spouses tend to be near cousins. But even with widely separated peoples, individual tend to be distant cousins. (We are all related if you go back far enough.) Prematurely segmenting your research just means more work updating the distance ancestors in related trees.

Instead, consider filtering to lineages (and omitting data marked ‘private’) while exporting. Then sharing that filtered subset.

1 Like
4

I will leave the GEDCOM export options to our Dutch speakers that would better understand available options.

If your father has maintained each family branch in separate databases/trees you can create individual databases/tress in Gramps to do the same.

If however, all of the family branches are maintained in a single database, I would continue to do so in Gramps. A single database/tree is preferred because you would not be maintaining separate Place and Source databases. Filters can be created to create branch trees for reports etc.

1 Like
5

@Davesellers, @emyoulation and @DaveSch Thank you very much for the information you were able to provide me with.
I’ve figured out that GDP can export to GEDCOM or GEDCOM with profile images and that - indeed - non-standard information will be added into Notes. I’ll give it a few goes these days and try to keep track of my experiences along the way. Possibly this’ll lead to something of a GDP-Gramps migration guide.

6

@emyoulation would you be interested in a (partial) gedcom export from GDP to see what’s in there?

7

Hello Stephan,

If you want, you can also send a GEDCOM file to me, so that I can check whether it’s possible to write a text filter that replaces GEDCOM tags that Gramps doesn’t understand to tags that work. And things like that can help a lot.

I’ve tried GDP a couple of times, and I agree that it’s grown quite complex, and to me it still feels a bit like a DOS program in a Windows shell, with all those menu’s and function keys. It can do things that Gramps can’t however, especially with source templates, so a migration will require a bit of effort. Transferring images should be quite easy though.

May I ask how many persons you have in this tree? I support the idea to keep them all together, but Gramps can be a bit slow with large numbers, like over a hundred thousand.

groeten uit Driebergen,

Enno

8

@ennoborg is a better choice for that. He has the original software and speaks the language.

9

Stephan, I have just done that. Importing a Gedcom created by GensData Pro. I have experienced data loss and have experienced that most (if not all) custom tags ended up as Notes in Gramps. It needed a lot of work to get things right again. So much so that with this small database I started from scratch, as entering all the date from new was as time consuming as fixing all the Notes into their rightful places. Entering them from new also gave me the opportunity to fix most source citations, something I have found lacking inf GDPRo (That might have been me)
Sure a Gedcom transfer will yield a workable result. It might be the only way to go with a larger file, but it might need quite some work to get to a satisfying result. I am currently still contemplating if I want to transfer my large (10.000+ records) GDPro file. I have no definitive answer yet.

10

Thanks @ursus, it’s nice to see another user testing this. And as far as I’m concerned, you must have very good reasons to do a migration like this. I know from private messages with Stephan that call names (roepnamen) are lost, because they rely on a custom tag that’s not supported by Gramps, and there are also problems distinguisingh civil and religious marriages, because of the way they’re exported to GEDCOM by GDP.

From Stephan I know that he has more than 40,000 persons in his tree, and with such numbers the deep connections Gramplet can become quite slow too, although that can be much worse, because I have one tree with more than 300,000. Check & Repair is quite slow then too.

Your source problem is quite intriguing, because I think that (unlike popular programs like Pro-Gen and Aldfaer), GPD does support the repo/source/citation model, that we have in Grams too. OTOH, I also know that GDP supports template based sources, and we don’t support those in Gramps.

With all these, and the fact that GDP creates better reports too, or at least reports that fit better with what we’re used to in The Netherlands, my opinion is that one must really hate GDP or Windows to make such a change. In all other cases, it’s probably better to bite the bullet, and try to get used to the GPD menu’s, no matter how complex and messy they are.

11

Does Gensdata Pro have a published file format or database schema?

12

Not that I know of. It’s a one man project, and I know that it runs on something that was once called the Borland Database Engine, but there is no official public documenation, and not an unofficial one either, like there is for RootsMagic.

And I bet that it’s not in the interest of the author either, or of its sponsor, the Dutch Genealogical Society, so I would say that it’s a no go.

13

Perhaps going OT @ennoborg.
I did use Pro-Gen since 1992, When I emigrated to GDP its direct import was nearly flawless.
I do (sort of) agree that, when researching within the Netherlands, GDP is a much better tool then Gramps. Higly geared to our situation. And I also (mostly) agree that going from GDP to Gramps using GEDCOM is not a healthy road. There are however also points to make against using GDP, it is klunky, is protected bc it a proprietary program. It does need admin rights every time you use it. So yes I do use it for my own research, but for some trees I have switched to Gramps. I do not really hate GDP, but am not in love as I was with Pro-Gen when I first started.

14

@nick, @ursus

When I look at the specifications, and try the demo, including GEDCOM export, I get the impression that our data model is good enough to deal with most data exported by GDP. The on-site documentation suggests that nothing is lost, but unsupprted fields are moved to notes. Examples are notes you can attach to (event) dates and places. We have notes for locations, but they’re shared, and the documentation suggests that these notes are specific to the event.

Other possible difficult parts are source/citation templates, and a special field that allows one to enter a person’s name as it appears in a particular source, so that reports can show how a name was spelled in that source, which is something that we can of course put in a research note attached to that source, but you don’t always want to display those in a report. An example is my paternal grandmother, whose birth name was Christina Antonia Johanna, but who was baptized as Christina Antonia Maria.

Gramps can already store call names, but for most Dutch, the call name is different from all official names, registered at birth and/or baptism. This grandmother’s call name was Annie, which means that you can’t display it as an underlined part of her given names, because it doesn’t match. Adding some code to deal with this should not be too difficult, I think. Most users insist that a call name is not a nickname, so I guess that it would please them if we could make that change.

I also think that many custom fields can be stored in attributes, which is a change that’s quite easy to make.

Here’s GDP’s own explanation about GEDCOM export, in Dutch:

https://www.gensdatapro.nl/ngvgdp/veelgestelde-vragen/gedcom-uitvoer/

15

In the US, the nickname is often a variation of the Callname. So a “John Robert Smith” might have a Callname of “Robert” but a variation of that Callname (such as Rob/Bob/Bert/Robbie/Robby/Bobbie/Bobby/Bertie) is the nickname.

So for your birthname example of “Christina Antonia Johanna <surname>” would have a callname of “Antonia” and a nickname of “Annie”

16

I see what you mean, and this variation is what we call a ‘roepnaam’, which sounds similar to the German Rufname, but is something different, because it is a variant. We call it a roepnaam, because it serves the same purpose as the German Rufname, meaning that the ‘roepnaam’ is what you normally use to address a person. The other names have a formal role, which means that they appear in the civil registry, in baptism records, and in your passport.

In mij world a nickname, or ‘bijnaam’, is exactly what I found on wikipedia:

A nickname or short name is a substitute for the proper name of a person, place or thing. It is commonly used to express affection, amusement, a character trait or defamation of character.

This difference is important in narrative reports, where you can introduce a person by her formal name(s), and use her ‘roepnaam’ for subsequent references, just like you can use short footnotes for repeated citations. Repeating a nickname can be quite offensive, so you may want to suppress that in reports.

See Nickname - Wikipedia

17

@ennoborg
I did a trial run, exporting my own research out of GensDataPro. Created a new GRAMPS file and imported the GEDCOM. I was shocked.

Within the first record alone (my own person-record) There are 88 lines of mixed GEDCOM tags not properly imported but all went to NOTES
REFN, ADDR, _MAP, _LATI, _LONG, OBJE. Skipped, not understood, minor rule skipped

example Birth record:
regarding birth record: Witness has been put in ATTRIBUTE
The relationship of the witness of birth declaration to the baby (the father) has been put into NOTES

This goes for all witnesses and relations of them to the subject
All residences have been completely put into the general NOTES (except place names)
ALL sourcetexts (like texts from birthrecords etc) are completely gone. Nowhere to be found. They are present in the GEDCOM-file with a TEXT tag (and CONC)
All partners are registered as MARRIED (even when they were not married in GensDataPro)
All citations where copied without contents. You’ll find birth certificate mentioned, but its source text as well as its citation are lost.
Events are only imported with their description, the date and a stripped place name. EVERYTHING else is gone (citations, source text)

I did seem to remember that, but with this test I confirmed my suspicion that GEDCOM from GensDataPro to GRAMPS is pretty much useless. Unless I missed something dramatic

18

I have no personal tree in GDP, but when I run the demo, with our royal family in it, the exported GEDCOM works quite well with Gramps. This may be quite a simple tree, without witnesses, so that problem is invisible then, but I can see sources with citations and page numbers.

If you want, you can send a GEDCOM, maybe with some privatized people, or deceased ancestors, to my email, which is my username here at Gmail.com

19

Typical examples of naming conventions in the Netherlands:

My father’s full name is Wilhelmus Lucas Maria Paternotte
Surname/family name: Paternotte
Given name(s): Wilhelmus Lucas Maria
Callname: Wim (which is a short form for Wilhelmus)
Nickname: -

My mother’s full name is: Petronella Catharina Adriana Post
Surname/family name: Post
Given name(s): Petronella Catharina Adriana
Callname: Nel (short form Petronella)
Nickname: -

I don’t think we have any nicknames in our family. Nicknames tend towards an adjective, sometimes positive, generally negative. If one single family member would have had a red beard, then his nickname could have been Redbeard, similar to Philip the Fair or William the Silent.

Maybe this could shed a little light on a slightly more relaxed usage of the field Callname where it does not necessarily have to be an exact element of the Given name. If it would be allowed that the Callname is NOT a substring of Given Name, then that would be perfect for the Dutch naming conventions.

1 Like
20

Today, I got a small test file from @ursus, and that proves that the GDP data model is too different for a quich migration. The GEDCOM that he sent has no custom tags, so at first sight, one might think that it’s all well and good, but in reality it is not.

When I test it with GEDCOM validator, I see just a few minor warnings, which suggests that the relations between objects are legitimate. Gramps can not deal with those though, and I see no quick way to fix that.