---

Jeg har lige et par spørgsmål vedr. gedcom, som sikkert står i den
officielle standard-beskrivelse, men da det man reelt støder på i den
virkelige verden ikke altid overholder standarden, vil jeg hellere høre
fra dem der har skrevet programmer der parser gedcom:

1) kan (bør) man være sikker på at INDI-records er nummereret fra 1 og
fremad

0 @I1@ INDI
....
0 @I2@ INDI
....
0 @I3@ INDI

osv.


2) det samme spørgsmål om FAM-records

0 @F1@ FAM
....
0 @F2@ FAM
.....
0 @F3@ FAM


3) er det (strengt taget) en fejl hvis et individs FAMS-records ikke er
ordnet kronologisk (gift 1., 2., 3. ...) efter vielsesdatoen?

4) samme spørgsmål om CHIL-records i en FAM-entry (1. barn, 2. barn
osv.)

5) hvad i al verden gør man hvis et individ har flere forældre
(FAMC-records) - og man f.eks. vil tegne at anetræ for en
brugerdefineret proband?

6) hvad gør man med pointer-fejl: e.g. en mand har en pointer til en
FAMS hvis HUSB-entry ikke viser tilbage til manden?

mvh tb

---

Sun, 15 Dec 2002 10:52:49 +0100 skrev Tom Brøndsted:

> Jeg har lige et par spørgsmål vedr. gedcom, som sikkert står i den
> officielle standard-beskrivelse, men da det man reelt støder på i den
> virkelige verden ikke altid overholder standarden, vil jeg hellere høre
> fra dem der har skrevet programmer der parser gedcom:

Hvis du vil lave din egen GEDCOM-parser, så
slipper du ikke for at læse og forstå standarden,
hvor svarene på de fleste af dine nedenstående spørgsmål findes.

En anden god grund til selv at læse i standarden, er at de
svar du får her jo kan være udtryk for en misforståelse.

> 1) kan (bør) man være sikker på at INDI-records er nummereret fra 1 og
> fremad

Nej (til hverken kan eller bør).

>
> 2) det samme spørgsmål om FAM-records

Ditto.

> 3) er det (strengt taget) en fejl hvis et individs FAMS-records ikke er
> ordnet kronologisk (gift 1., 2., 3. ...) efter vielsesdatoen?

Jeg har ikke set noget om det i standarden.

> 4) samme spørgsmål om CHIL-records i en FAM-entry (1. barn, 2. barn
> osv.)

Den foretrukne orden er kronologisk efter fødsel, så strengt taget ja.

> 5) hvad i al verden gør man hvis et individ har flere forældre
> (FAMC-records)

Du opretter multiple FAMC-poster for individet,
med den mest sandsynlige først.

> 6) hvad gør man med pointer-fejl: e.g. en mand har en pointer til en
> FAMS hvis HUSB-entry ikke viser tilbage til manden?

Det er en oplagt og urovækkende fejl (som findes i et udbredt
program, der endda har eksisteret i flere år!).

Den bedste måde at ordne det på er at opfordre ejeren af GEDCOM-filen
til at enten droppe sit program eller få producenten til at rette fejlen.

-Lars Lundin.
--
GEDCOMP: En omfattende og gratis database for slægtsforskere med
interesse i Danmark: http://www.lklundin.dk/gedcomp/

---

Tak for svaret.

"Lars Kr. Lundin" wrote:

>
>
> > 1) kan (bør) man være sikker på at INDI-records er nummereret fra 1 og
> > fremad
>
> Nej (til hverken kan eller bør).
>

kan numrene være 0 eller negative?

>
>
> > 5) hvad i al verden gør man hvis et individ har flere forældre
> > (FAMC-records)
>
> Du opretter multiple FAMC-poster for individet,
> med den mest sandsynlige først.

Dvs at man kan gå ud fra at den første post er den mest sandynlige?

>
>
> > 6) hvad gør man med pointer-fejl: e.g. en mand har en pointer til en
> > FAMS hvis HUSB-entry ikke viser tilbage til manden?
>
> Det er en oplagt og urovækkende fejl (som findes i et udbredt
> program, der endda har eksisteret i flere år!).
>
> Den bedste måde at ordne det på er at opfordre ejeren af GEDCOM-filen
> til at enten droppe sit program eller få producenten til at rette fejlen.
>

Så må jeg vist ved lejlighed skrive til Lars Lundin : Den meget store
dk20522b.ged (kan 36 MB) som gedcomp-brugerne kan hente, hvis de har "hits",
har masser af pointerfejl. Hvis man skal lave en robust parser, bliver man
nødt til at have en strategi for pointer-fejl, e.g. gå ud fra at FAMS er
korrekt og ignorere INDI-pointerne eller vice versa.

mvh tb

---

Sun, 15 Dec 2002 13:50:16 +0100 skrev Tom Brøndsted:

> kan numrene være 0 eller negative?

Læs selv i standarden hvorfor svaret er ikke er nej
(spørgsmålet giver nemlig ikke rigtigt mening).

> Dvs at man kan gå ud fra at den første post er den mest sandynlige?

Nej, jfr. mange programmers dårlige implementering.

> Så må jeg vist ved lejlighed skrive til Lars Lundin

Ha, den var god (jeg er iøvrigt ikke filens ejermand, jeg har
blot fået tilladelse til at videredistribuere filen).
Kig i filens HEAD'er, så ser du
1 SOUR BROSKEEP
2 VERS 5.2 WINDOWS

Så send hellere en email til support@brotherskeeper.dk.
Og gør opmærksom på at selvom 5.2 ikke er nyeste version,
betyder det ikke at fejlen er rettet i nyeste version.

> Hvis man skal lave en robust parser,
> bliver man nødt til at have en strategi for pointer-fejl,

Måske. Den kan i så fald være helt at ignorere de defekte
poster. Pga. den indbyggede redundans mht. GEDCOM-pointere,
så kan man godt forsøge sig med noget bedre - men det kan
du selv more dig med at regne ud.

Mvh,
-Lars Lundin.
--
GEDCOMP: En omfattende og gratis database for slægtsforskere med
interesse i Danmark: http://www.lklundin.dk/gedcomp/

---

Sun, 15 Dec 2002 14:22:01 +0100, in dk.videnskab.historie.genealogi,
"Lars Kr. Lundin" <news-gi-25@lklundin.dk> wrote:

>Sun, 15 Dec 2002 13:50:16 +0100 skrev Tom Brøndsted:
>
>> kan numrene være 0 eller negative?
>
>Læs selv i standarden hvorfor svaret er ikke er nej
>(spørgsmålet giver nemlig ikke rigtigt mening).
>
>> Dvs at man kan gå ud fra at den første post er den mest sandynlige?
>
>Nej, jfr. mange programmers dårlige implementering.
>
>> Så må jeg vist ved lejlighed skrive til Lars Lundin
>
>Ha, den var god (jeg er iøvrigt ikke filens ejermand, jeg har
>blot fået tilladelse til at videredistribuere filen).
>Kig i filens HEAD'er, så ser du
>1 SOUR BROSKEEP
>2 VERS 5.2 WINDOWS
>
>Så send hellere en email til support@brotherskeeper.dk.
>Og gør opmærksom på at selvom 5.2 ikke er nyeste version,
>betyder det ikke at fejlen er rettet i nyeste version.
>
nå hadde den filen allerede i 2000 feil med hensyn til
1 COMM

En kode som ikke var i bruk i BK5 og hvor det ble innrømmet at dette
skyltes mix og blanding av ulike forhold.

Vet ikke om det er rettet, men har vel mistanke om at det finnes
fortsatt feil i den filen som nok ikke skyldes bk5

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

"Tom Brøndsted" <tom@brondsted.dk> skrev i en meddelelse
news:3DFC7A88.A6F2C8D8@brondsted.dk...
>
> Så må jeg vist ved lejlighed skrive til Lars Lundin : Den meget store
> dk20522b.ged (kan 36 MB) som gedcomp-brugerne kan hente, hvis de har
"hits",
> har masser af pointerfejl. Hvis man skal lave en robust parser, bliver man
> nødt til at have en strategi for pointer-fejl, e.g. gå ud fra at FAMS er
> korrekt og ignorere INDI-pointerne eller vice versa.
>
> mvh tb
>

Tænk sig at den stadig er tilgængelig i sin oprindelige version.

Jeg synes det er trist at GEDCOMP, som jeg før i tiden anså som et seriøst
tilbud, stadig er med til at videregive urigtige oplysninger.
Mit håb er dog at hver gang denne gedcom fil i sin oprindelige udformning
får et sammenfald med en anden gedcom fil, at Lars K Lundin så er så
behjælpsom overfor sine bruger at sende en ekstra vedledning med i dette
sammenfald som påpeger at den er er fyldt med mange fejl, og derfor skal
tages med stor forbehold.

Jeg vil lige citerer hvad Lars K. Lundin tidligere har skrevet om denne fil
her i nyhedgruppen.

Citat start
Dato:2001-12-25
1) pointere at jeg ikke reklamerer for at folk skal hente denne fil.
Derimod tænkes filen hentet af slægtsforskere, som via GEDCOMP har
fået oplyst at nogle helt specifikke personoplysninger er at finde i filen.
Ideen er at GEDCOMP automatisk leder een hen til oplysninger, der er
relevante for ens egen slægtsforskning.

For øvrige slægsforskere tilslutter jeg mig "Ole P. Bielefeldt"s udsagn:
Jeg mener ikke, den er værd at bruge tid på at hente og indlæse.
Citat slut



Venlig hilsen
Michael Hedeman
Nordisk Slægtsdatabase: http://www.alternativ-forum.dk/genealogi/

---

"Michael Hedeman" <genealogi@alternativ-forum.dk> skrev Mon, 16 Dec 2002
10:23:53 +0100

>> Så må jeg vist ved lejlighed skrive til Lars Lundin : Den meget store
>> dk20522b.ged (kan 36 MB) som gedcomp-brugerne kan hente, hvis de har
>"hits",
>> har masser af pointerfejl. Hvis man skal lave en robust parser, bliver man
>> nødt til at have en strategi for pointer-fejl, e.g. gå ud fra at FAMS er
>> korrekt og ignorere INDI-pointerne eller vice versa.
>>
>Tænk sig at den stadig er tilgængelig i sin oprindelige version.
>
Jeg kan ikke helt se problemet.?

Filen foreligger i den form den oprindeligt er blevet indleveret til
GedComp - og du har da iøvrigt selv påberåbt dig at være 'medejer' af
den oprindelige fil.

Lars har derimod aldrig lagt skjul på, at han anser filen for at være (i
bedste fald) tvivlsom. Og at han kun udleverer den til personer hvor der
er fundet sammenfald, og kun til disse orientering og til deres egen
fortsatte vurdering og efterforskning.


--
mvh, A:\Feldborg

http://www.haunstrup.dk/feldborg/genealogi/opslag/
http://www.haunstrup.dk/feldborg/genealogi/download/

---

Tom Brøndsted <tom@brondsted.dk> wrote in message news:<3DFC50F1.EF9950A3@brondsted.dk>...
> Jeg har lige et par spørgsmål vedr. gedcom, som sikkert står i den
> officielle standard-beskrivelse, men da det man reelt støder på i den
> virkelige verden ikke altid overholder standarden, vil jeg hellere høre
> fra dem der har skrevet programmer der parser gedcom:

Jeg har fået meget respons på WinGed programmet. Fra udlandet kan jeg
se at der findes mange standarder/programmer rundt omkring. Det eneste
sikre synes at være at hver ny record starter med 0 @xx.....xx@ YYY ,
og hvad der så ligger i recorden er så mere usikkert. Hver Tag (Name
osv) man vil bruge skal søges i den enkelte record, og den den kan
ligge et vilkårligt sted.


Bo

www.boekelund.dk

---

bo wrote:

> Tom Brøndsted <tom@brondsted.dk> wrote in message news:<3DFC50F1.EF9950A3@brondsted.dk>...
> > Jeg har lige et par spørgsmål vedr. gedcom, som sikkert står i den
> > officielle standard-beskrivelse, men da det man reelt støder på i den
> > virkelige verden ikke altid overholder standarden, vil jeg hellere høre
> > fra dem der har skrevet programmer der parser gedcom:
>
> Jeg har fået meget respons på WinGed programmet. Fra udlandet kan jeg
> se at der findes mange standarder/programmer rundt omkring. Det eneste
> sikre synes at være at hver ny record starter med 0 @xx.....xx@ YYY ,
> og hvad der så ligger i recorden er så mere usikkert. Hver Tag (Name
> osv) man vil bruge skal søges i den enkelte record, og den den kan
> ligge et vilkårligt sted.
>
>

Jeg har siden 1996 brugt et program wfam32/cfam32 som jeg selv har lavet (linux, windows ...).
Det laver udskrifter i rtf i det "format" du kan se (i html) på

http://www.brondsted.dk/brochmann/

Nu er tiden kommet til at give det en tur over knæet, så jeg kan være bekendt at give det til
andre.

I det her tilfælde er det umuligt at forstå "alt": jeg parser: 0 @I[id]@ INDI, 0 @F[id]@ FAM
og 0 @S[id]@ SOUR - hvor [id] er en nummerisk værdi (lige nu >0 - men det er åbenbart
forkert!). Resten ser jeg bort fra.

mvh tb

---

Sun, 15 Dec 2002 16:47:54 +0100 skrev Tom Brøndsted:

> Nu er tiden kommet til at give det en tur over knæet, så jeg kan være
> bekendt at give det til andre.

Det synes jeg er en prisværdig ide.

> I det her tilfælde er det umuligt at forstå "alt": jeg parser: 0 @I[id]@
> INDI, 0 @F[id]@ FAM og 0 @S[id]@ SOUR - hvor [id] er en nummerisk værdi
> (lige nu >0 - men det er åbenbart forkert!). Resten ser jeg bort fra.

Du gør dig selv en bjørnetjeneste, hvis du frigiver et
GEDCOM-program, baseret på løse gæt og formodninger.

Så nu siger jeg det lige een gang til:
Læs og forstå selv GEDCOM-standarden inden du går videre.

Så undgår du f.eks. fejlen med ikke at kunne klare linjer som:
0 @Dette_er_OK@ INDI
og
0 @Dette_er_ogsaa_OK@ INDI

Slut herfra om det.

Mvh,
Lars Lundin.
--
GEDCOMP: En omfattende og gratis database for slægtsforskere med
interesse i Danmark: http://www.lklundin.dk/gedcomp/

---

"Lars Kr. Lundin" wrote:

> Sun, 15 Dec 2002 16:47:54 +0100 skrev Tom Brøndsted:
>
> > Nu er tiden kommet til at give det en tur over knæet, så jeg kan være
> > bekendt at give det til andre.
>
> Det synes jeg er en prisværdig ide.
>
> > I det her tilfælde er det umuligt at forstå "alt": jeg parser: 0 @I[id]@
> > INDI, 0 @F[id]@ FAM og 0 @S[id]@ SOUR - hvor [id] er en nummerisk værdi
> > (lige nu >0 - men det er åbenbart forkert!). Resten ser jeg bort fra.
>
> Du gør dig selv en bjørnetjeneste, hvis du frigiver et
> GEDCOM-program, baseret på løse gæt og formodninger.
>
> Så nu siger jeg det lige een gang til:
> Læs og forstå selv GEDCOM-standarden inden du går videre.
>
> Så undgår du f.eks. fejlen med ikke at kunne klare linjer som:
> 0 @Dette_er_OK@ INDI
> og
> 0 @Dette_er_ogsaa_OK@ INDI
>
> Slut herfra om det.
>
> Mvh,
> Lars Lundin.

Tak for svadaen! En pointer er altså en unik streng. Ikke synderlig smart
(hash-table, hukommelse, ...). Jeg lægger mit program ud i kode + eksekverbare
for nogle udvalgte OS'er. Det bliver efter reglen: 1) you get what you pay
for, 2) you pay nothing.

/tb

---

> Så nu siger jeg det lige een gang til:
> Læs og forstå selv GEDCOM-standarden inden du går videre.

Og når man så tror at man har forstået det hele , udgiver selveste LDS PAF
5.2 , der ved export danner en file med en fatal-fejl i første linie, der
gør at filen ikke kan læses
( Er meldt til LDS )

Bo

---

On Sun, 15 Dec 2002 22:32:51 +0100, "Bo" <bo@dadlnet.dk> wrote:

>Og når man så tror at man har forstået det hele , udgiver selveste LDS PAF
>5.2 , der ved export danner en file med en fatal-fejl i første linie, der
>gør at filen ikke kan læses
>( Er meldt til LDS )

De bruker UTX-8 (eller hva nå standarden heter) som er en
Unicode-standard. Hvis du leser dette som ANSI-tekst skjærer det hele
seg.. Første byte er da '0' om jeg ikke husker helt feil. Dette er en
av sjekkene man alltid skal ha i programmet og er ingen feil fra LDS
sin side. Det står helt tydelig i standarden at Unicode er foretrukket
standard

---

On Sun, 15 Dec 2002 17:03:31 +0100, "Lars Kr. Lundin"
<news-gi-25@lklundin.dk> wrote:

>Så undgår du f.eks. fejlen med ikke at kunne klare linjer som:
>0 @Dette_er_OK@ INDI
> og
>0 @Dette_er_ogsaa_OK@ INDI

Derimot er det feil med

0 @Dette_er_OK@ INDI
og
0 @Dette_er_OK@ INDI

Hver tekst mellom to '@' skal kun forekomme en gang på 0-nivå. Alle
andre ganger skal det forekomme på 1-nivå eller høyere.

---

Alf Christophersen wrote:

>
>
> Derimot er det feil med
>
> 0 @Dette_er_OK@ INDI
> og
> 0 @Dette_er_OK@ INDI
>
> Hver tekst mellom to '@' skal kun forekomme en gang på 0-nivå. Alle
> andre ganger skal det forekomme på 1-nivå eller høyere.

Jeg har lavet et program der checker for pointerfejl i gedcom. Det
bliver snarest lagt ud i "BETA" (linux, win32-systemer, Sun Solaris).
Det læser den famøse dk20522c.ged (fra gedcomp) på knap 40 MB med ca.
1/4 mill. individer på 20 sekunder og retter alle typer pointerfejl. BK
bruger efter sigende flere dage til indlæsning af denne fil! Semantiske
tvivlsomheder (gift før en prædefineret alder, usorterede børn og
ægteskaber og meget mere) detekteres og skrives i logfil på under et
sekund. Programmet anvender en optimeret hashtabel: En traditionel
streng-hashkey er ikke særlig god når strengene i virkeligheden er
nummeriske størrelser (sig hvad I vil: pointer-strenge er altid
nummeriske størrelse i de gedcom-filer jeg har set: "1", "2" osv.).
Derfor er min tabel optimeret til begge tilfælde: "nummeriske strenge"
og "rigtige strenge".

Men jeg kan i øjeblikket kun klare 8 bit karaktersæt. Fint for mig .
Jeg kan heller ikke klare flere sæt forældre. Nr 2 og fremefter bliver
ignoreret.

/tb

---

Mon, 30 Dec 2002 01:08:50 +0100, in dk.videnskab.historie.genealogi, Tom
Brøndsted <tom@brondsted.dk> wrote:

>
>
>Alf Christophersen wrote:
>
>>
>>
>> Derimot er det feil med
>>
>> 0 @Dette_er_OK@ INDI
>> og
>> 0 @Dette_er_OK@ INDI
>>
>> Hver tekst mellom to '@' skal kun forekomme en gang på 0-nivå. Alle
>> andre ganger skal det forekomme på 1-nivå eller høyere.
>
>Jeg har lavet et program der checker for pointerfejl i gedcom. Det
>bliver snarest lagt ud i "BETA" (linux, win32-systemer, Sun Solaris).
>Det læser den famøse dk20522c.ged (fra gedcomp) på knap 40 MB med ca.
>1/4 mill. individer på 20 sekunder og retter alle typer pointerfejl. BK
>bruger efter sigende flere dage til indlæsning af denne fil! Semantiske
>tvivlsomheder (gift før en prædefineret alder, usorterede børn og
>ægteskaber og meget mere) detekteres og skrives i logfil på under et
>sekund. Programmet anvender en optimeret hashtabel: En traditionel
>streng-hashkey er ikke særlig god når strengene i virkeligheden er
>nummeriske størrelser (sig hvad I vil: pointer-strenge er altid
>nummeriske størrelse i de gedcom-filer jeg har set: "1", "2" osv.).
>Derfor er min tabel optimeret til begge tilfælde: "nummeriske strenge"
>og "rigtige strenge".

nå har ikke jeg lest dk5022c, kun dk5022b (ca 36 MB) som i sin tid hadde
en rekke feil, men å bruke flere dager på å lese den filen var det ikke.
:=)))
den siste verjonen har jeg ikke funnet for å teste, så der kan jeg ikke
utaalle meg
Men det kommer jo meget an på hvilken maskinressurser man har :=)))

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

On Sun, 15 Dec 2002 10:52:49 +0100, Tom Brøndsted <tom@brondsted.dk>
wrote:

>1) kan (bør) man være sikker på at INDI-records er nummereret fra 1 og
>fremad
>
>0 @I1@ INDI
>...
>0 @I2@ INDI
>...
>0 @I3@ INDI

Nei. Mange bruker intern lagringsid som tag. Det er enklest. F.eks.
Disgen eksporterer til og med flokknr, på formen flknr_id, f.eks.
1_2032 som er fil 1og id 2032. Og der er det ingen forskjell mellom
individ og ekteskap, Det kan altså stå

0 @1_2093@ INDI
....
0 @1_2094@ FAM
......
0 @1_2095@ INDI

Legg også merke til at standarden sier intet om at individer skal
komme først og senere familien og sist kilder. Det kan tas i den
rekkefølge som føles naturlig i databasen

>2) det samme spørgsmål om FAM-records
>
>0 @F1@ FAM
>...
>0 @F2@ FAM

Se ovenfor

>3) er det (strengt taget) en fejl hvis et individs FAMS-records ikke er
>ordnet kronologisk (gift 1., 2., 3. ...) efter vielsesdatoen?

Nei

>
>4) samme spørgsmål om CHIL-records i en FAM-entry (1. barn, 2. barn
>osv.)
Nei
>
>5) hvad i al verden gør man hvis et individ har flere forældre
>(FAMC-records) - og man f.eks. vil tegne at anetræ for en
>brugerdefineret proband?

Da er det en feil. Det skal bare være en FAMC-rekord. Hvis man
registrerer adoptivforeldre skal disse angis med annen form for lenk
(RELA om jeg ikke husker feil)

>
>6) hvad gør man med pointer-fejl: e.g. en mand har en pointer til en
>FAMS hvis HUSB-entry ikke viser tilbage til manden?

Tja. Dropper kanskje? Er jo en sak for en sjekkrutine før man
eksporterer.