Recent ben ik overgestapt van MyHeritage Family Builder naar Gramps (versie 5.1.2 op Windows 10). Vandaag heb ik mijn stamboom bijgewerkt en het overschakelen stamboomprogramma lijkt geen problemen op te leveren, op één na.

Het valt me op dat aan het einde van elke zin die gaat over een gebeurtenis met daarin een locatie, nogmaals de locatie zonder spatie achteraan wordt geplakt. Bijvoorbeeld: "Hij is geboren op 27 augustus 1721 in Mierlo, Noord-Brabant, NederlandMierlo, Nederland." en "Zij zijn getrouwd op 14 augustus 1746 te Mierlo, Noord-Brabant, Nederland, hij was toen 24 jaar oudMierlo, Nederland."

Ik ben in de GEDCOM gedoken. Ik heb zowel de nieuwe Gramps en oude MyHeritage GEDCOM van deze persoon onderaan dit bericht bijgevoegd.

In de Gramps GEDCOM krijgt elke gebeurtenis zowel een PLAC als een ADDR, waarbij de ADDR meer gedetailleerde informatie zou kunnen bevatten. Het is de tekst uit de ADDR die Genealogie Online aan het einde van de zin lijkt te plakken, wat de vreemde zinnen oplevert.

De Gramps GEDCOM:

0 @I0053@ INDI
1 NAME Johannes /van Hoof/
2 GIVN Johannes
2 SPFX van
2 SURN Hoof
1 NAME Joannes /Aerts van Hoof/
2 GIVN Joannes
2 SURN Aerts, Hoof
1 NAME Jan /Aert Peters van Hooff/
2 GIVN Jan
2 SURN Aert, Peters, Hooff
1 NAME IJan /van Hooff/
2 GIVN IJan
2 SPFX van
2 SURN Hooff
1 NAME Joannes /van Hoof/
2 GIVN Joannes
2 SPFX van
2 SURN Hoof
1 SEX M
1 BIRT
2 DATE 27 AUG 1721
2 PLAC Mierlo, Noord-Brabant, Nederland
3 MAP
4 LATI N51.4436
4 LONG E5.6188
2 ADDR
3 ADR2 Mierlo
3 CTRY Nederland
1 DEAT
2 SOUR @S0000@
3 PAGE meer dan 120 jaar oud
1 BAPM
2 DATE 27 AUG 1721
2 PLAC Mierlo, Noord-Brabant, Nederland
3 MAP
4 LATI N51.4436
4 LONG E5.6188
2 ADDR
3 ADR2 Mierlo
3 CTRY Nederland
2 SOUR @S0053@
3 QUAY 3
3 DATA
4 DATE 27 AUG 1721
1 FAMC @F0028@
2 PEDI birth
1 FAMS @F0026@
1 FAMS @F0313@
1 CHAN
2 DATE 25 MAR 2023
3 TIME 09:06:14

De MyHeritage FamilyTree Builder GEDCOM:

0 @I53@ INDI
1 RIN MH:I53
1 _UID 5c72de2b8546b1e9bc07e4a471cb97b9
1 _UPD 7 MAR 2020 00:10:26 GMT+1
1 NAME Johannes Aerts Peters /van Hoof/
2 GIVN Johannes Aerts Peters
2 SURN van Hoof
2 _AKA Jan
1 SEX M
1 BIRT
2 _UID 5c72de328546b1e9bc07e4a471cb97b9
2 RIN MH:IF112
2 DATE 27 AUG 1721
2 PLAC Mierlo, Noord-Brabant, Nederland
1 DEAT
2 _UID 5c72de324e1a61e9bc07e4a471cb97b9
2 RIN MH:IF113
1 BAPM
2 _UID 5c72e5a78546b1e9bc07e4a471cb97b9
2 RIN MH:IF119
2 DATE 27 AUG 1721
2 PLAC Mierlo, Noord-Brabant, Nederland
2 SOUR @S53@
3 RIN MH:SC28
3 DATA
4 DATE 27 AUG 1721
3 QUAY 4
1 FAMS @F26@
1 FAMS @F313@
1 FAMC @F28@

Dag Koen, als ik je goed begrijp moet GO de tag PLAC overnemen en de tags MAP, LATI, LONG, ADDR, ADR2 en CTRY negeren, als er 'n tag PLAC van de betreffende gebeurtenis is tenminste?

2 PLAC Mierlo, Noord-Brabant, Nederland
3 MAP
4 LATI N51.4436
4 LONG E5.6188
2 ADDR
3 ADR2 Mierlo
3 CTRY Nederland

Komt het in je GEDCOM ook voor dat PLAC niet gevuld is, maar ADR2 en CTRY wel?

Bedankt voor het antwoord.

Ik zie nergens lege PLAC tags. Deze tag lijkt altijd de volledige naam van de locatie te bevatten, of het nu een woonplaats, begraafplaats of huis is. Er komt soms wel een ADDR tag voor, waar geen PLAC tag is. Dit gebeurt wanneer een woonadres in Gramps als adres is toegevoegd aan een persoon.* Voorbeeld:

1 RESI
2 DATE 1830
2 ADDR Strabrecht 267
3 CONT Heeze
3 CONT Nederland
3 ADR1 Strabrecht 267
3 ADR2 Heeze
3 CTRY Nederland

Deze informatie wordt hier weergegeven: https://www.genealogieonline.nl/stamboom-van-hoof-van-stiphout-verbeek-en-nelen/I0081.php

De wat vreemde notatie hiervan lijkt te komen door de dubbele informatie in de GEDCOM, die door Gramps is gemaakt.

Het probleem van de locaties aan het einde van de zinnen, komt voor bij alle gebeurtenissen met een locatie, waarbij dus een ingevulde PLAC en ADDR tag, beide op niveau 2, zijn.

* Een adres kan in Gramps gekoppeld worden aan een persoon als de locatie van residentie-gebeurtenis (plaats-object) of als een adres (tekst). In de GEDCOM worden beide een RESI. In het eerste geval met zowel een PLAC als ADDR tag, in het tweede geval met alleen een ADDR tag. Het tweede geval is dit voorbeeld.

Dit lijkt me voldoende info voor Bob Coret om het inlezen van GEDCOM's aan te passen. Aan Gramps kan hij niets doen, aan hoe GEDCOM's worden ingelezen en gepubliceerd op GO wel. Even geduld a.j.b.

Misschien kun je het verschijnsel in de tussentijd ook bij de Gramps-helpdesk aankaarten. Zij kunnen het inlezen van 'n GEDCOM gegenereerd door MyHeritage Family Builder verbeteren. Als ze 'n beetje opschieten is het probleem nog verholpen voordat Bob eraan toe komt:-) 

De wat vreemde notatie hiervan lijkt te komen door de dubbele informatie in de GEDCOM, die door Gramps is gemaakt.

Voor adressen hoort dit. Tamura Jones heeft daar een lang verhaal over geschreven, dat je hier kan lezen:

https://www.tamurajones.net/GEDCOMADDR.xhtml

Het is een raar deel van de standaard, en Tamura adviseert ook om hem niet te volgen. Maar als er dubbele informatie is, moet het importerende programma dat wel opvangen, en dat lijkt Genealogie Online hier niet te doen.

De stukjes ADDR bij PLAC horen er volgens mij niet, en ik zie ze hier ook.

Als je wilt, kun je ook langskomen op ons eigen Engelstalige forum:

https://gramps.discourse.group/

En tot slot raad ik je aan om ook even Gramps 5.1.5 te downloaden. Die verhelpt dat ADDR bij PLAC niet, maar verbetert wel andere fouten:

https://gramps-project.org/blog/download/

Dag Koen,

Het probleem van de locaties aan het einde van de zinnen, komt voor bij alle gebeurtenissen met een locatie, waarbij dus een ingevulde PLAC en ADDR tag, beide op niveau 2, zijn.

Ik heb de oorzaak hiervan al achterhaald., en zelf een foutrapport gemaakt:

https://gramps-project.org/bugs/view.php?id=12862

Ik hoop dat de correctie mee kan in de volgende versie, maar ik weet nog niet wanneer die uitgebracht wordt.

Bedankt voor de oplossing aan de kant van Gramps! 

Ik heb je advies gevolgd om te updaten naar versie 5.1.5. Ik heb inderdaad alle plaatsen een type meegegeven, zodat ik ze makkelijker van elkaar kan onderscheiden. Dat lijkt dus de overbodige ADDR-tags te veroorzaken.

Aan de kant van Genealogie Online is het nog wel vreemd dat deze overbodige tags zonder spatie aan het einde van de zin worden toegevoegd.

Aan de kant van Genealogie Online is het nog wel vreemd dat deze overbodige tags zonder spatie aan het einde van de zin worden toegevoegd.

Dat ben ik met je eens, en ik hoop dat Bob ook een manier vindt om hiermee om te gaan, net als met die dubbele adressen. Daarbij zag ik in onze broncode zelfs een verwijzing staan naar het artikel van Tamura Jones, dat ik eerder citeerde.

Op een site als deze heb je natuurlijk nog met veel meer zaken te maken dan 1 enkel programma, zoals wij dat gebruiken, omdat ieder programma weer een eigen GEDCOM-dialect spreekt. Er staan in je voorbeeld van My Heritage ook een paar dingen waar Gramps weer van schrikt, en die Bob hoop ik gewoon negeert.

Nog even een nabrander:

Als ik op de site kijk, waar we de bugs in Gramps bijhouden, zie ik geen tekenen dat er snel een nieuwe versie komt waarin mijn reparatie terechtkomt. Hij zou daarvoor namelijk niet alleen door een andere ontwikkelaar moeten worden goedgekeurd, wat hoop ik niet zo'n probleem is, ook al heb ik iets weggehaald, wat een ander bewust toegevoegd heeft, maar hij moet ook worden opgenomen in een versie 5.1.6, als die er komt, en die lijkt er vooralsnog niet te komen. Hij staat namelijk ingepland voor 30 maart, en de hele actielijst is nog leeg. En wat wel op die lijst staat, is een versie 5.2, voor het eind van de zomer (31 juli 2023).

Je kunt deze plannen inzien op

https://gramps-project.org/bugs/roadmap_page.php

en dat betekent dus nog wat geduld, en misschien hopen dat Bob wel tijd heeft om dat ADDR-deel weg te filteren.

Omdat ik mijn Gramps zelf bouw, op Linux, ben ik al voorzien. En hoewel er ook hacks mogelijk zijn, gaan die denk ik te ver voor deze thread.

Dag Koen, als ik je goed begrijp moet GO de tag PLAC overnemen en de tags MAP, LATI, LONG, ADDR, ADR2 en CTRY negeren, als er 'n tag PLAC van de betreffende gebeurtenis is tenminste?

2 PLAC Mierlo, Noord-Brabant, Nederland
3 MAP
4 LATI N51.4436
4 LONG E5.6188
2 ADDR
3 ADR2 Mierlo
3 CTRY Nederland

Hmm, negeren van aangeleverde informatie vind ik nooit fijn. 

Een plaats is iets anders dan een adres. Ik heb nog niet gekeken wat GEDCOM 7 hier over zegt.

Wellicht kun je wel zeggen dat het adres genegeerd moet worden als het ADDR niet méér informatie geeft dan de PLAC. Dus als er bijv. in het ADDR ook een "3 ADR1 Kerkstraat 1" had gestaan, dan niet negeren, omdat het immers nuttige informatie is (naast de coördinaten).

Hallo Bob,

Omdat ik de broncode heb, weet ik dat dit ADDR bij een PLAC door een fout komt, in Gramps. Daar heeft iemand ooit bedacht dat het wel leuk is, om een ADDR te exporteren, als er in een locatie-object elementen voorkomen, zoals een straat, een plaats, een staat, en een land. En in dit geval is Mierlo bijvoorbeeld een plaats, en geen stad, waardoor dat als ADR2 geexporteerd wordt, en wordt Noord-Brabant niet als STAE geexporteerd, omdat dat alleen gebeurt voor objecten die echt het type Staat hebben, en niet als je ze als Provincie opslaat. En Nederland wordt wel weer geexporteerd, omdat het objecttype Land is, CTRY dus.

Ik ben persoonlijk van mening, dat Gramps alleen een ADDR mag exporteren, als de gebruiker dat daadwerkelijk heeft ingevoerd, en dat is hier niet het geval. Ik heb deze situatie namelijk ook in mijn eigen stamboom getest.

Er is nu alleen wel een soort van probleem, en dat is dat ik vanuit de broncode werk, en mijn eigen Gramps op Linux ook al heb aangepast. Het kan alleen nog wel maanden duren voordat deze bugfix ook in de nieuwe Windows-versie mee wordt genomen. 'Normale' gebruikers blijven dit soort Gramps-fouten dus zien, tenzij jij hier iets aan wil doen.

De dubbele export van adressen zelf, dus als de gebruiker die ook echt ingevoerd heeft, zoals hierboven bij RESI, lijkt volgens de regels te zijn. Ik vind daar ongeveer hetzelfde van als Tamura, maar ik zie geen kans om die ontdubbeling er snel door te krijgen, bij Gramps.

We blijven voor zover ik weet voorlopig nog bij GEDCOM 5.5.1.

Bedankt voor de reactie, Bob.

als ik je goed begrijp moet GO de tag PLAC overnemen en de tags MAP, LATI, LONG, ADDR, ADR2 en CTRY negeren, als er 'n tag PLAC van de betreffende gebeurtenis is tenminste?

Het gaat slechts om de tags onder 2 ADDR. Dus ADDR, ADR2 en CTRY. De tags MAP, LATI en LONG worden op dit moment goed gebruikt door Genealogie Online. Ik zie bijvoorbeeld dat de coördinaten gebruikt worden in de link naar een kaart achter de plaatsnaam. Ik heb in Gramps ook begraafplaatsen en sommige huizen van mijn voorouders ingevoerd als plaats met coördinaten. Dit werkt perfect in Genealogie Online.

De tags ADDR, ADR2 en CTRY worden nu wel meegenomen, maar niet goed verwerkt. Ze worden achter de zin geplakt, zelfs zonder spatie. Ze voegen al geen verdere informatie toe aan een locatie. De de manier van verwerking wordt de opmaak van de stamboom ook nog eens slordig gemaakt.

Koen,

De dubbele "adresgegevens" worden nu niet meer getoond (als onderdelen ook al in de plaatsaanduiding zitten):

Oud:

Nieuw:

Zie je nog voorbeelden in je publicatie waar het fout gaat?

Bedankt! Het ziet er nu een stuk beter uit. Ik heb even rondgekeken en zie geen problemen meer.

Is uw probleem opgelost / vraag beantwoord?

Wilt u dan onderaan uw bericht klikken op 'Markeren als opgelost'?

Zo nee, wilt u ons dan laten weten wat er nog misgaat?