Migrating from Gensdata Pro

Help
21

@StephanP , @ursus , there is one thing that I’m curious about: Have you ever tried the Ancestris program?

I mention that, because Ancestris is an open source program that pretends all sorts of GEDCOM files. And its developer say that, because the program has no dedicated database, like Gramps, so there is no reason to try to forge everything into that format, during import. And if this is real, the program may give you better insight into your tree than Gramps will, after conversion.

Ancestris is written in Java, and uses lots of memory on large trees, but it may be a better choice than Gramps.

Here’s the GEDCOM import manual, in Dutch:

There is an English version too, but that one doesn’t mention GensDataPro.

22

I admit that a dislike towards GDP caused me to look into a possible migration to Gramps, the latter being of modern design, open source, multi platform, not recommending admin rights and under active development.

Ancestris I had not discovered yet and I will look into that as well. I do have concerns about its speed at certain functions as it’s based on Java RTE, but we’ll cross that bridge when we get there.

For the moment, me and my dad are entrenched in GDP, sifting out the suspected duplicates that came to light after the first migration attempt. Best to do that in the preprocessing stage of things.

When I’ve got a new gedcom, I’ll throw it at Gramps as well as Ancestris and see what that does.

[Edit: corrected typo’s Ancestris]

23

@ennoborg
I have been playing round a bit with Ancestris. Alas several GEDCOM import errors have come to light. GensDataPro is not mentioned on its ‘official’ recognized imports. It does an internal conversion of the GDP-Gedcom first. And although it mentions to be successful, it was not. Yet again unmarried persons are flagged as married. Ancestris seems to support marriages only.
It does list all DATES (like new residence) but the street names (etc etc) are not always linked. Source texts seem to be gone. (Like text from birth records)
I suspect that if I would want to use Ancestris I would also have to start from scratch.
I hadn’t realised before how much trouble converting would be. Since GDP provides a dedicated Pro-GEN import that worked impeccably.
Would this mean to stay with GDP? Probably at this time.

24

Today I found that there’s a completely different route, that might also interest our boss @Nick-Hall and that’s called Paradox.

I did some digging inside the GDP installation folder, and not only found the Borland Database Engine there, but also found that the GD3 file that stores the Oranje example tree actually is a ZIP file containing a dozen other files, with DB and MB extensions, and of these, the DB files appear to be in Paradox format:

For Paradox, there are lot of tools, and when I download the viewer referenced at the bottom of the Wikipedia page, I can inspect all tables from that database, and see that there is a person table, and one for relations, and another one for locations, and sources, and so forth.

A quick Google search suggests that there are a couple of tools that can read Paradox tables, including libraries for Linux, and Python wrappers. There are also tools that can convert Paradox tables to other formats, like MySQL, PostgreSQL, CSV and XML, for example:

And in the mean time, I also found the problem with persons married against their will, which is twofold:

  1. In Gramps, there is a setting for imported families, that you can set to married, unmarried, and maybe a couple of other values,
  2. In your test file, I found families with MARR events, some of which have TYPE (partners). And that type is meaningless for Gramps, just like types (civil) and (religious).

I know many Dutch people who think that Dutch genealogists must use software made in Holland, because only Dutch programmers know about surname prefixes, which is nonsense, because they are supported by GEDCOM, and Gramps. And because of that, many Dutch users have lived in a bubble, in which they created their own data models, which are quite different from the ones used by American programs, like PAF, RootsMagic, and Gramps. And when these developers are sponsored by organisations that live in their own bubbles too, like the NGV, this is what you get.

Converting Pro-Gen files is much easier, because the Pro-Gen datamodel is much simpler, and is more like a subset of the model that we use in Gramps.

1 Like
25

If you email me the GD3 file, I’ll take a look.

26

Done. I sent it to your gramps project address.

27

I tried reading the database using pxlib and pypxlib. Unfortunately, it just core dumps when I try to open a table.

28

OK, thanks for trying. I can open the database with Windows tools, but I haven’t found good libraries for that either, so it looks like a direct import is out of the question.

In the mean time I found that a GEDCOM export from the demo tree shows the same problems as I had with ursus’ test tree, and has no privacy issues, because it’s all about royalty (public figures), so we can probably use that as a reference for a possible GEDCOM import expansion.

Shall I create a separate thread for that? Some of the issues may not be unique for GensData Pro, but are about locations and sources in general, and standard GEDCOM tags.

29

I had another look earlier this week, and need to make a few remarks.

  1. It seems that that GDP mixes up MAP and _MAP, LATI and _LATI, and LONG and _LONG, which is something that I see as an error in GDP. You can easily clean up this mess with a text editor.

  2. Witnesses are not supported in standard GEDCOM, so supporting those would mean that we have to write an extension to the GEDCOM importer to deal with them.

  3. Residences are a problem indeed, because Gramps ignores the ADDR tag, and also the _NAME tag that I found in the Oranje demo tree. That _NAME tag is used to export the name of an object like a palace. This means that for an event like

1 RESI
2 ADDR Akkerstraat 2  [F]
3 CITY Arnhem,GE,NLD

Gramps only imports the CITY line. That is a little weird, because it’s a subordinate of the ADDR, and hence should be ignored, but it is imported anyway.

For me, it’s quite easy to write a little program that replaces the ADDR and CITY lines with a single line, so that the RESI block is changed to

1 RESI
2 PLAC Akkerstraat 2  [F], Arnhem,GE,NLD

which is perfect for Gramps, and can be changed to a true place hierarchy later. I have no idea where that [F] comes from, but if you want to get rid of that, we have a tool for that in Gramps.

  1. Source texts are not lost. I checked that with the GEDCOM that you sent to me, and they are all connected to the sources that you can see in the citations tab of a person. There is a bit of a problem there though, because Gramps follows the recommendations made in 1996, with GEDCOM 5.5, to use a three level repository, source, citation model, and assumes that the actual source texts are linked at the citation level, where you also specify the volume/page and date of a record found in a source like a church book, or a civil registry. This means that by convention, a birth record should not be entered as a source, but as an entry in some book or registry, where the source holds the title of the book or registry, and the citation gives the volume/page, and date, and the actual text. Things work this way in good old PAF, and most American made programs that I know, including Gramps, and this means that getting to the source texts may require more clicks than you like. The quickest way to see them is through the citations Gramplet, that I have at the bottom of my screen, where they are all attached at the source level.

What you see here may be a consequence of how things work in Pro-Gen which is quite a primitive program, because it doesn’t follow these recommendations, and still relies on a single level source model. Aldfaer does that too, and when you’re used to it, it is OK, but GDP can do better. I can see that in the Oranje demo tree, which cites pages grouped under books.

There is one part ignored in Gramps, and that’s the source data block. I found that in your tree too, but for privacy reasons I qoute one exported from the Oranje demo tree:

0 @S33@ SOUR
1 TITL Europäische Stammtafeln Neue Folge
1 ABBR ESNF
1 DATA
2 EVEN EVEN
3 DATE FROM 1978
3 PLAC Marburg,HE,DEU
2 NOTE type: Periodiek
3 CONT uid: 19
3 CONT Samensteller: Detlev Schwennicke
3 CONT Uitgever: Stargardt, Klostermann

From this source, only the title and abbreviation are imported. All the other elements shown here are ignored, including the note, which is NOT the source text itself. These are legal elements in the GEDCOM standard, but it seems that we never found a reason to import those, most probably because they don’t appear much in the wild. I have never found them in any American made program, and they don’t appear in Aldfaer or Pro-Gen either.

It looks like GDP uses this note to export the citation elements that I found in the source table, where they are columns that can be defined by the user. And these are things that many GDP users probably like to see in a bibliography.

And to be honest, there are better ways to export these.

30

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.