Question about gedcom import

[Woody]

Hi all,
i test a little bit the import from my main genealogy programm GES 2000 to Gramps 5.2.0. (I know thas a beta) I think about to change to Gramps. I work on Win 11 64bit.

GES 2000 have a Places hierarchy an export this in the gedcom 5.5.1 and gedcom 7.0.
Is there a way to import this in Gramps? Currently most places only show up as an import error.

here’s an example:

0 @I1439@ INDI
1 UID a279899a-014c-4efb-a5f0-33bb16fd75ef
1 NAME Adam/Bruckner/
2 GIVN Adam
2 SURN Bruckner
2 _RUFNAME Adam
1 NAME /Brugner/
2 TYPE OTHER
3 PHRASE Variante:1686
2 SURN Brugner
1 SEX M
1 BIRT
2 DATE 19 MAY 1686
2 PLAC Wultendorf,,,,,,
3 _LOC @L69@
2 RELI rk
1 _KINDNR 1
1 FAMC @F4322@
1 CHAN
2 DATE 23 JUL 2023
3 TIME 11:22:18
2 _CHANUSER STANW
1 CREA
2 DATE 5 JUL 2021
3 TIME 10:06:57
2 _CREAUSER WOODY


0 @L69@ _LOC
1 NAME Wultendorf
1 _LOC @L5026@
1 _GOV WULORFJN88FQ
1 MAP
2 LATI 48.6667
2 LONG 16.4667
1 CHAN
2 DATE 31 AUG 2023
3 TIME 11:43:47
2 _CHANUSER STANW
1 CREA
2 DATE 31 JUL 2021
3 TIME 17:07:07
2 _CREAUSER WOODY


0 @L5026@ _LOC
1 NAME Staatz
1 _LOC @L7810@
1 _GOV object_310720
1 MAP
2 LATI 48.6700428571429
2 LONG 16.4993428571429
1 CHAN
2 DATE 31 AUG 2023
3 TIME 11:50:31
2 _CHANUSER STANW
1 CREA
2 DATE 31 JUL 2021
3 TIME 16:28:54
2 _CREAUSER WOODY

0 @L7810@ _LOC
1 NAME Bezirk Mistelbach
1 _LOC @L7809@
1 _GOV object_215365
1 MAP
2 LATI 48.60729365707965
2 LONG 16.569363422566358
1 CHAN
2 DATE 31 AUG 2023
3 TIME 11:54:11
2 _CHANUSER STANW
1 CREA
2 DATE 31 JUL 2021
3 TIME 11:08:12
2 _CREAUSER WOODY

0 @L7809@ _LOC
1 NAME Weinviertel
1 _LOC @L6974@
1 _GOV A17623
1 CHAN
2 DATE 31 AUG 2023
3 TIME 11:54:11
2 _CHANUSER STANW
1 CREA
2 DATE 31 JUL 2021
3 TIME 11:08:12
2 _CREAUSER WOODY

0 @L6974@ _LOC
1 NAME Österreich unter der Enns
2 DATE BET  AND 21 OCT 1918
1 NAME Niederösterreich
2 DATE BET 22 OCT 1918 AND 12 MAR 1938
1 NAME Niederdonau
2 DATE BET 13 MAR 1938 AND 26 APR 1945
1 NAME Niederösterreich
2 DATE 27 APR 1945
1 _LOC @L7670@
2 DATE BET 1512 AND 4 JUN 1945
1 _LOC @L7671@
2 DATE BET 5 JUN 1945 AND 27 JUL 1955
1 _LOC @L7670@
2 DATE 28 JUL 1955
1 _GOV object_215341
1 _GOV object_306018
1 MAP
2 LATI 48.239729405581656
2 LONG 15.533644487408127
1 CHAN
2 DATE 29 SEP 2023
3 TIME 11:21:54
2 _CHANUSER STANW
1 CREA
2 DATE 11 APR 2022
3 TIME 23:12:33
2 _CREAUSER STEFAN

Greetings
Woody

[ennoborg]

Hallo Woody,

In this fragment, the place looks perfectly normal. The UID is in GEDCOM 7 format, and I see some custom tags, where I assume that the _LOC tag is meant as a direct reference to a top level place record. Is that right?

I’m assuming that _KINDNR means child number, right? We use the word ‘kind’ here in The Netherlands too.

groeten uit Driebergen,

Enno

[Woody]

Hi Enno,
yes, that is a fragment of a gedcom 7 file. As you can see, at the place @L6974@ _LOC Österreich unter Enns, even the name varies over time and the branching into the next level of the hierarchy is also controlled over time.
My problem when importing gedcom is that only the first location is taken over. Unfortunately, all other locations that are connected via the _LOC TAG are not.
My hope is that you can control the import so that Gramps imports it into its location administration as a location tree.

greeting
Woody

[ennoborg]

Hi Woody,

I forgot to scroll down, but now I see how this works. And knowing what we have in store for Gramps 5.2, which is something that you can also see on our bug tracker, I bet that you won’t see support for GEDCOM-L or 7 in that version.

That suggest that it would be nice to have a GEDCOM-L importer as a plug-in, which can work if we can find a volunteer to write that … and an exporter too.

When I look at the support for GEDCOM 7 world wide, relying on the list of manufacturers that I can find on the FamilySearch site, it looks like there is not much support outside Germany. I found one two person Dutch company listed under Germany, but when I visit their web site, I see nothing about GEDCOM 7.

As far as I can see, our database is good enough to support your hierarchy, including name variations over time. I don’t see room for the GOV codes though, at least not in 5.1.

Does that help you make a decision?

[Woody]

Hi Enno,
i don’t know why everyone has such a hard time with gedcom7. Each developer waits for the other to do something.
Gramps is on the right way, but just too slow.
Then I can only hope that Gramps 10.0 implements gedcom7
Thanks for your answer.

Greetings
Woody

[emyoulation]

GEDCOM7 would require some changes to the Gramps data model. See the notes in the Enhancement Request.

[Woody]

yes, I know it’s a lot of work. I don’t want to complain either. But when you know something great is coming, you can’t wait until you have it…

[ennoborg]

Hallo Woody,

I can understand what you mean, but the truth is that it isn’t great enough to spend time on. I’ve been involved (discussing) in earlier standards efforts, like Better GEDCOM, and also wrote a few comments on GEDCOM X, and none of these really took off. And that’s not only because people didn’t really listen to each other, or simply ignored problems that are only recognized outside English speaking countries, like for citations, but also because there is no real gain in it for the big companies. They don’t need a better GEDCOM, because they want you to stay with their software.

Most American companies, and a few others, adopted GEDCOM X for a part, because you need GEDCOM X to exchange data with FamilySearch, but they never offered it as an export format. And compared to GEDCOM X, GEDCOM 7 is just a step back.

GEDCOM-L works in Germany, because there are many small companies, run by a single author, and you also have CompGen, which works great to unite users and developers. And that is quite unique, software wise. Our own NGV sponsors 1 program, so we don’t have that type of cooperation in The Netherlands. I found one 2 person Dutch company in the list of German GEDCOM 7, and the status for their software (PRO-GEN) is tbd.

This means that, if you want support for your location hierarchy, you will probably have to write it yourself, like I once hacked the GEDCOM importer to include attributes that I get from FamilySearch, via other programs like Ancestral Quest and RootsMagic, and earlier via PAF (AFN, _UID). And those are person attributes, which already existed in our data model. Place attributes are not supported in Gramps 5.1, so they’re a bit more difficult, and I don’t see them in the 5.2 beta either. And that means that you will probably not be able to import the _GOV code that I found in your GEDCOM, or any other of the custom tags that I saw in the _LOC record.

Note that GEDCOM 7 does not have a hierarchical place structure like the one that you can find in Gramps and GEDCOM-L, so even if we support GEDCOM 7, it won’t work for your places, or mine.

Regards,

Enno