Ganska exakt en halvtimme tog den alternativa kontrollen när jag körde den ikväll.
Utskriftsvy
Ganska exakt en halvtimme tog den alternativa kontrollen när jag körde den ikväll.
Jag har testat med några GEDCOM-filer och känner behov av lite klarlägganden beträffande fellistorna jag får ut.
Fel: Ej def tidsangivelse.
Det får jag på datum där jag använt lampan för att få "omkring årtal", i och för sig ett riktigt påpekande. Använder jag inte lampan men skriver i kommentarrutan för levnadsnotisen "omkring" får jag ingen felnotis i RGD-test, och i utskrifter ser allt ändå korrekt ut. Samma händer om ett tidsintervall har angetts.
Fel: Ej korrekt kalenderdatum.
Det felet har jag fått på nästan alla i en mottagen GEDCOM-fil jag hade i en särskild flock. Går jag in och kollar levnadsnotisen ser allt rätt ut i mina ögon, men även där är lampan inblandad. Går jag in och plockar bort den blir det ingen felnotis på den posten.
Nu kommer jag inte att ändra på något förrän jag vet vad som är rätt. Det kan inte vara lätt att få till en bra RGD med alla varianter av födelse- dödsnotiser som finns.
Listorna i openRGD skall inte tolkas som "Fellistor".
De innehåller diverse kommentarer av olika typer. Det finns vissa saker som betraktas som fel men också sånt som bara är information.
Datum behandlas lite olika så jag skulle behöva lite bra exempel för att riktigt kunna svara.
Ej definitiv tidsangivelse är en typiskt sådan information. Man vet ju inte någon definitiv tidpunkt för då hade man ju skrivit in det.
Tanken med den listan är mest att man ögnar igenom den för att se om det kanske är något men skulle kunna kolla upp på nytt, kanske främst på de lite modernare tidpunkterna.
Ej korrekt kalenderdatum som du upplever som korrekta bör inte komma med i listningen. Om dom kommer från en särskild flock kan det vara så att datum är skrivet som texter.
Ett datum i GEDCOM format skall bestå av en/två siffror från 1-31, månad i engelsk trebokstavsform, t.ex. JAN följt av årtal med 4 siffror.
Sen ytterligare då dessa ungefärliga datum och datumintervaller som också skall hålla ett visst GEDCOM format.
När det gäller ej definitiva datum har vi numera tagit bort dessa ur Check-listan därför att den ibland tenderade till att bli väldigt stor.
Därför återfinns dessa nu i en egen lista som heter Note.txt.
................
Ej definitiv tidsangivelse är en typiskt sådan information. Man vet ju inte någon definitiv tidpunkt för då hade man ju skrivit in det.
Tanken med den listan är mest att man ögnar igenom den för att se om det kanske är något men skulle kunna kolla upp på nytt, kanske främst på de lite modernare tidpunkterna.
Ej korrekt kalenderdatum som du upplever som korrekta bör inte komma med i listningen. Om dom kommer från en särskild flock kan det vara så att datum är skrivet som texter.
Ett datum i GEDCOM format skall bestå av en/två siffror från 1-31, månad i engelsk trebokstavsform, t.ex. JAN följt av årtal med 4 siffror.
Sen ytterligare då dessa ungefärliga datum och datumintervaller som också skall hålla ett visst GEDCOM format.
När det gäller ej definitiva datum har vi numera tagit bort dessa ur Check-listan därför att den ibland tenderade till att bli väldigt stor.
Därför återfinns dessa nu i en egen lista som heter Note.txt.[/QUOTE]
.............
Jag har gjort en koll för att försöka utröna orsaken. Vid koll av tända lampan ser jag att "Fras" är markerat och det antar jag tolkas som text. Ändrar jag till "Exakt" slocknar lampan och det blir korrekt i GEDCOM-filen. Tyvärr har jag inte den ursprungliga GEDCOM-filen kvar för att kunna se hur den såg ut.
Det blir väl ändå att ta ett bett i det sura äpplet och ändra. Det är trots allt inte så många. Nedan klipp ur GEDCOM med ändrad och icke ändrad.
0 @I6195@ INDI
1 SEX M
1 NAME Anders /Andersson/
1 BIRT
2 DATE 14 DEC 1783
2 PLAC Hög S:a, Huggenäs (S)
1 CHR
2 DATE 24 DEC 1783
2 PLAC Huggenäs (S)
1 DEAT
2 DATE 24 DEC 1783
2 PLAC Hög S:a, Huggenäs (S)
2 CAUS "Förqvaft"
1 BURI
2 DATE 28 DEC 1783
2 PLAC Huggenäs (S)
1 FAMC @F05@
1 CHAN
2 DATE 29 FEB 2016
3 TIME 14:57:00
0 @I6198@ INDI
1 SEX F
1 NAME Lisbet /Olofsdotter/
1 BIRT
2 DATE (1745-12-05)
2 PLAC Högstorpet, Huggenäs
1 EVEN
2 TYPE Dop
2 DATE (1745-12-05)
2 PLAC Huggenäs
2 NOTE Notering i födelseboken: död och begraven
1 FAMC @F06@
1 CHAN
2 DATE 9 APR 2009
Det skulle inte vara så svårt att tolka (1745-12-05) maskinellt om alla datum i textformat hade sett ut på det sättet.
Men i praktiken visar det säg att det finns många sätt som man tycker ett datum bör se ut.
Släktforskningsprogram som får datum som inte direkt kan tolkas har ofta en nödlösning, som att kalla det "Fras" för då kan det se ut hur som helst.
openRGD vill visa att datum inte kunde tolkas genom att lägga ut det i listan.
Men det är bra om man använder det format det egna släktforskningsprogrammet använder. Då blir oftast exporten till andra medier, t.ex. GEDCOM korrekt.
Hej! Vid körning nyligen fick jag följande felmeddelande från RDG:
*** F E L L I S T A (II) Strukturfel
Formellt fel i GEDCOM filen: Barn I72206, som finns i familj F15007, finns även i familjen F14990
* * * GEDCOM filen skall inte användas innan formella felaktigheter är korrigerade.
Barnet i fråga har fosterföräldrar OCH biologiska föräldrar i Disgen 2016. Jag antar att det är det som RDG protesterar mot.
Hur ska det hanteras i RDG? Det lär ju dyka upp mera liknande i och med nya funktionerna i 2016.
/Anders
Detta är ett "nytt" fenomen som kom till i samband med Disgen 2016, att man kan ha mer än en uppsättning föräldrar.
När openRGD/Släkttrim byggdes uppfattades detta som ett fel.
Rent strukturellt kan en relation ha olika status, t.ex. biologisk, adoptiv eller foster. Detta skall då framgå i GEDCOM filen via taggen TYPE som kompletterar relationen.
Ett barn är ju alltid biologiskt, men även barn kan i vissa fall få avvikande status beroende på att men ser på familjen från föräldrarnas sida.
Jag har tyckt att Disgen gör fel när båda relationerna presenteras i GEDCOM filen och önskat att bara den föräldrarelation som vid tillfället är överst skall gå till GEDCOM filen. Egentligen på samma sätt som vid presentation i familjeöversikten.
Men det är tydligen delade meningar därom.
Den skarpt formulerade felsignalen i openRGD kom till egentligen därför att vi hittat GEDCOM filer skapade med gamla Disgen som hade dubblerade barn utan att nån kunde förklara hur det uppstått.
Oavsett bör man förvissa sig om att mottagaren av GEDCOM filen kan tolka status och behandla filen på rätt sätt. Om GEDCOM filen bara är avsedd för kontroll i openRGD kan man ignorera meddelandet om man är medveten om varför.
Flera andra släktforskningsprogram tillåter att relationer med olika status förekommer.
Den tänkta funktionen för RGD skulle baseras enbart på biologiska relationer, så där skulle då enbart det biologiska alternativet tas med.
Så i RGD skulle det bli mer problem om adoptiv/foster relationer registreras som biologiska. Detta skulle då troligen inte uppmärksammas förrän samma relation kom in från en annan släktforskare.
Tack för snabbt o bra svar! Vi håller på att "tvätta av" några Disgen-databaser för att så småningom slå samman dom till en gemensam. Om jag förstår det rätt, så bör vi undvika att få med foster- och adoptiv-relationer i GEDCOM-filer till RDG, åtminstone ännu så länge. Även om det inte är så många sådana här fall, så bör dom ju undvikas inför en sammanslagning mha RDG.
Exporten har ju ingen sådan möjlighet, utan i så fall får man väl redigera bort dom i GEDCOM-filen innan den körs i RDG??
Hur detta kommer att hanteras i RGD vet ingen ännu.
Oavsett blir det RGD som skall hantera det, släktforskaren som lämnar GEDCOM filen skall inte behöva fundera över sådant.
Det samma gäller också t.ex. levande personer, alla begränsningsfunktioner måste hanteras i RGD.
En sak till, om ni inte för egen del har någon nytta av att slå samman GEDCOM filer till en gemensam databas, blir det ur RGD synpunkt bättre om varje enskilt bidrag kommer in var för sig.
Adoption hanteras inte heller i Disbyt.
Ett adopterat barn kan ha två uppsättningar föräldrar. Detta kräver att relationerna markeras så att RGD resp. Disbyt kan agera på grundval av den markeringen.
Disbyt innehåller troligen en hel del adoptiv- och fosterrelationer på grund av att Disgen 8 tolkade alla registrerade personer som biologiska.
Efter konverteringen uppfattar då även Disgen 2016 dessa personer som biologiska.
Ni som känner igen att ni tidigare i Dg8 registrerat adoptiv/foster relationer skulle behöva registrera om detta i Disgen 2016, nu när den möjligheten finns.
Då ökar ni kvaliteten på er egen forskning och genom att skicka ett nytt bidrag till Disbyt blir även den databasen "rättad".
En förbättring i Disgen skulle vara att även ge barn, som enbart är kopplad till icke-biologisk relation, också skulle få status satt på individposten.
Om program som läser GEDCOM filen exkluderar icke-biologiska relationer går annars dessa barn vidare och blir orelaterade personer, vilket heller inte är bra kvalitet.
Jag noterade en ytterligare sak när det gäller foster- eller adoptivbarn. Hör kanske mera hemma under HTML-export, men jag upptäckte det vid tester med det här.
HTML-exporten (Disgen 2016) skapar antavla till fosterföräldrarna i stället för de biologiska! Vet just nu inte om det är slumpmässigt pga Id-nummer.
Jag sökte fram ett barn som har fosterföräldrar, gjorde Utöka söklistan med "Föräldrar". Fick då barn + två föräldrapar, alltså 5 personer. Gjorde HTML-export på dessa md mall 7. Barnet visas då under båda föräldraparen och noteras mycket riktigt som "Fosterbarn" under fosterföräldrarna, MEN antavlan för barnet visar fosterföräldrarna och deras anor - INTE de biologiska föräldrarna. Ska det vara så?
I min kommentar ovan, hänger det uppenbarligen på vilket av föräldraskapet som lades in först. Om fosterföräldrarna lagts in först, så blir det dom som kommer som antavla i HTML-exporten och om biologiska lagts in först, så blir det dom.
Skulle vara bra med litet mera kontroll på detta.
När vi införde möjligheten att registrera flera föräldrarelationer till ett barn i Disgen så valde vi att låta användaren välja vilken relation som skulle visas i alla utskrifter och exporter av barnets anor.
Den relation som visas i antavlan är alltid den relation som visas överst in listan över föräldarelationer. Genom att byta ordning där så kan alltså användaren välja om den biologiska eller någon annan föräldrarelation är den som skall visas i antavlor. Det är ju inte säkert att man alltid vill visa samma relation.
Det styr du genom att välja vilket föräldrapars om är överst i personöversiktens föräldrapanel.Citat:
Ursprungligen postat av ollfa
Jag har från en annan släktforskare fått en Gedcom som jag vill jämföra mot en egen men får inte till det. Hur gör man, kan jag få lite handledning.
Åke
Den enda dokumentation som finns ligger som ett klickbart pdf dokument på sidan.
Ett tips kan också vara att lära artikeln i Diskulogen 117.
Någon direkt dokumentation finns inte, mycket på grund av att hanteringen helt beror på det data som jämförs.
Jag föreslår att du tar kontakt med mig på telefon 08 55245912 så skall jag försöka svara på dina frågor och ge lite handledning.
Är du bara intresserad av resultatet kan jag göra matchningen åt er och meddela er resultatet.
Men var inte rädd för att testa och prova.
Tillägg: Artikeln från Diskulogen finns också tillgänglig på Dis hemsida under rubriken openRGD.
Jag skall läsa och testa först så får jag se om jag klarar det.
Om jag förstår saken rätt så ska man i princip kunna jämföra 2st backup om man lägger dem i olika databaser och gör Ged-comfil på respektive.
Bra om man råkat radera utan att tänka sig för två gånger.:rolleyes: