handdator

Visa fullständig version : Problem med GEDCOM 5 import i Disgen



dis48723
2012-12-27, 02:50
Hej!
Jag använder den senaste versionen av Webtress, där jag har exporterat en GEDCOM-fil v5 och har problem att importera in den i senaste DISGEN (v8.2d). Bifogar filen med de felmeddelande som skapades av DISGEN i zip-format.

Skulle uppskatta om någon kunden ge förslag på hur man på enklaste sättet löser detta, utan att manuellt behöver gå in och ändra i GEDCOM-filen.

Tack på förhand.

Mvh
Cesar da Silva

tommypeters
2012-12-27, 10:48
Det var en liten ynklig logfil... :-) Min fellogg från importen av en GEDCOM från Family Tree Maker 2012 blev väl på hundra tusen rader eller så...

Orsaken är i alla fall densamma, både Webtress och FTM exporterar GEDCOM-filer med en mängd taggar som inte ingår i GEDCOM-standarden. En del kan vara relativt enkla att byta ut, manuellt eller med ett skript, en del är svårare att hitta något vettigt alternativ till i standarden.
När det gäller FTM har folk klagat på detta i fem år, utvecklingsteamet prioriterar bort det och 2013 kommer ingen ny version. Dessutom - en GEDCOM-fil som följer standarden gör det ju lättare att byta från programmet...

Inte bara för min egen, och din, skull tycker jag att DiSGen borde satsa på en kraftfull importfunktion som tar hand om dessa icke-standarder - det är *mycket* säljande. Jag har inte min loggfil tillgänglig här, men den kan skickas och den tillsammans med GEDCOM-filen är ju allt som behövs för att man ska kunna göra en sådan funktion bättre, undan för undan.

dis48723
2012-12-27, 15:32
Hej Tommy,
Jag misstänkte att det var så.
Jag tror att det skulle vara bra om DISGEN skulle vara mer förlåtande vid import av GEDCOM-filer, där man fick välja vad som skulle hända med den importerad posten som innehöll taggen som inte stöds av DISGEN.
Jag har också letat på Internet efter någon program som kan spara/konvertera GEDCOM-filer till GEDCOM version 4.0 format. På detta sätt så tror jag att det skulle underlätta importen av min GEDCOM-fil till DISGEN eftersom GEDCOM version 4.0 är mer standardiserad. Är det någon som känner till någon sådan program eller hemsida på Internet som kan utföra detta?

Med vänliga hälsningar,
Cesar da Silva

DanielBerglund
2012-12-27, 23:16
Gedcom v4 är väl samtida med Magnus Ladulås och gör nog inget bättre, särskilt som v4-importen i Disgen inte har underhållits på många år. I nästa version av Disgen tar vi bort den helt.

Problemet med din import är inte att det finns en massa icke-standard taggar, dem struntar Disgen bara i, utan problemet är att det finns två individer som refereras i filen men de verkar inte finnas definierade. Se längst ner i filen. Det klarar inte Disgen alls och då avbryts importen. Det är möjligt att detta går att ordna ändå genom att regidiera lite i gedcomfilen.

Hittills har vi sagt att vi inte försöker stödja direkta felaktigheter i gedcomfilerna. Vi får väl se om det går att hantera en del av vissa andra programs egenheter i nästa version av Disgen, men det är ganska arbetskrävande, för det finns många olika program och det finns tydligen många olika sätt att läsa fel i gedcom-standarden.

Om någon har tid över och intresse för lite utveckling, så vore det intressant att ha en "gedcom-masserare" som läser in en gedcomfil och skriver ut den, rättad. Man skulle kunna utgå från Disgens gedcomparser och förmodligen sparka igång något med FreePascal.

dis48723
2012-12-28, 00:12
Hej Daniel!
Tack för ditt snabba och utförliga svar.
Importen fixades i samband med att jag tog bort problemet som det nämndes i felrapportens sista rader, precis som du nämnde.

Mvh,
Cesar da Silva

tommypeters
2012-12-28, 17:32
Gedcom v4 är väl samtida med Magnus Ladulås och gör nog inget bättre, särskilt som v4-importen i Disgen inte har underhållits på många år. I nästa version av Disgen tar vi bort den helt.

Problemet med din import är inte att det finns en massa icke-standard taggar, dem struntar Disgen bara i, utan problemet är att det finns två individer som refereras i filen men de verkar inte finnas definierade. Se längst ner i filen. Det klarar inte Disgen alls och då avbryts importen. Det är möjligt att detta går att ordna ändå genom att regidiera lite i gedcomfilen.

Hittills har vi sagt att vi inte försöker stödja direkta felaktigheter i gedcomfilerna. Vi får väl se om det går att hantera en del av vissa andra programs egenheter i nästa version av Disgen, men det är ganska arbetskrävande, för det finns många olika program och det finns tydligen många olika sätt att läsa fel i gedcom-standarden.

Om någon har tid över och intresse för lite utveckling, så vore det intressant att ha en "gedcom-masserare" som läser in en gedcomfil och skriver ut den, rättad. Man skulle kunna utgå från Disgens gedcomparser och förmodligen sparka igång något med FreePascal.

Intresse och kunskap, inklusive i Pascal, finns. Kanske svårare med tiden. Om jag fick ett ex av DiSGen för besväret skulle det kanske gå lättare att hitta tiden, utan en GEDCOM-masserare blir det ju ändå inget köp för mig. Ska programmet göras som ett fristående program kan jag ju göra det i C# eller VB.Net, har alla Microsofts program via MSDN-prenumeration.

Finns det för övrigt något standardmässigt sätt att länka till foton i en GEDCOM-fil?

Finns det något dokument som beskriver exakt den (subset/superset av) GEDCOM 5.5-standarden som DiSGen hanterar? ("Vi följer GEDCOM 5.5-standarden duger inte som svar... :-))

tommypeters
2012-12-31, 17:12
Efter lite funderande så behöver ju "GEDCOM-masseraren" vara en integrerad del av DiSGEN (försteg till importen) för att hjälpa till med försäljningen - annars går den ju att använda innan import till vilket program som helst...

Phryxe
2012-12-31, 19:54
Efter lite funderande så behöver ju "GEDCOM-masseraren" vara en integrerad del av DiSGEN (försteg till importen) för att hjälpa till med försäljningen - annars går den ju att använda innan import till vilket program som helst...
Det har talats om att nästa/kommande versioner av Disgen ska tillåta plugins. Har inte sett någon plan för ett API och vad man ska kunna komma åt. Det är väl lite tidigt än ...

DanielBerglund
2013-01-02, 02:15
Intresse och kunskap, inklusive i Pascal, finns. Kanske svårare med tiden. Om jag fick ett ex av DiSGen för besväret skulle det kanske gå lättare att hitta tiden, utan en GEDCOM-masserare blir det ju ändå inget köp för mig. Ska programmet göras som ett fristående program kan jag ju göra det i C# eller VB.Net, har alla Microsofts program via MSDN-prenumeration.

Ett exemplar av Disgen till de som utvecklar på Disgen eller angränsande program är inget problem alls.

Finns det för övrigt något standardmässigt sätt att länka till foton i en GEDCOM-fil?

Nej, det är väl alltid lokala filsystemspather som följer med och därmed blir det problem på ett eller annat vis. Enda sättet är nog att placera alla foton i samma katalog som gedcomfilen och inte skicka med några pather alls.

Finns det något dokument som beskriver exakt den (subset/superset av) GEDCOM 5.5-standarden som DiSGen hanterar? ("Vi följer GEDCOM 5.5-standarden duger inte som svar... :-))

Det är källkoden som gäller här. Den är ganska lättläst men omfattande. 6k rader för importen. Exporten är dock bara 1,4k rader.

Efter lite funderande så behöver ju "GEDCOM-masseraren" vara en integrerad del av DiSGEN (försteg till importen) för att hjälpa till med försäljningen - annars går den ju att använda innan import till vilket program som helst...

Nja, vi kan nog ha fristående generalla program för specialuppgifter. Vi är ju inte "föreningen Disgen" så om det går att använda till andra program är det ingen nackdel. Disgen blir i sin tur ganska klumpigt om allt ska integreras där.

Däremot är det nog så att en gedcom->gedcom transformering inte kan lösa alla problem, utan en del begrepp behöver man skriva in direkt i Disgens databas. Det är ett argument för integrering av i alla fall vissa delar.

DanielBerglund
2013-01-02, 02:16
Det har talats om att nästa/kommande versioner av Disgen ska tillåta plugins. Har inte sett någon plan för ett API och vad man ska kunna komma åt. Det är väl lite tidigt än ...
Det är inte särskilt genomtänkt än, nej. Inte alls faktiskt. Någon som vill ta i uppgiften och spåna fram något med viss substans?

Phryxe
2013-01-02, 10:56
Detta blir lite off topic ... Nya databasstrukturen i SQLite är väl inte satt än. Kommer databasen att vara krypterad på något sätt så att man måste gå via Disgens API för att accessa informationen eller kan man öppna den okrypterad i valfritt program?

Har tyvärr ingen erfarenhet av att skapa API, men vi kan väl börja klottra ner i wikin funderingar på funktioner som kan behövas!?

tommypeters
2013-01-03, 00:01
Nej, det är väl alltid lokala filsystemspather som följer med och därmed blir det problem på ett eller annat vis. Enda sättet är nog att placera alla foton i samma katalog som gedcomfilen och inte skicka med några pather alls.
Ska man kunna importera "extrainformation" måste man naturligtvis ställa krav på hur exporten från "det andra programmet" ska göras. T.ex. måste bilderna ligga i samma katalog som GEDCOM-filen, eller i en underkatalog direkt under som t.ex. heter "Photos".

Det är källkoden som gäller här. Den är ganska lättläst men omfattande. 6k rader för importen. Exporten är dock bara 1,4k rader.
Jag har kommit in som konsult i system (OK, mycket större) där "källkoden är dokumentationen" och också "lättförstådd". När vi sedan frågat dem om någon programdel och varför den gör som den gör så brukar de inte ha en aning... :D
Men jag tänkte mer på "Vilken GEDCOM 5.5-standard", speciellt angående avvikelser/tillägg, som följs.

Nja, vi kan nog ha fristående generalla program för specialuppgifter. Vi är ju inte "föreningen Disgen" så om det går att använda till andra program är det ingen nackdel. Disgen blir i sin tur ganska klumpigt om allt ska integreras där.
Däremot är det nog så att en gedcom->gedcom transformering inte kan lösa alla problem, utan en del begrepp behöver man skriva in direkt i Disgens databas. Det är ett argument för integrering av i alla fall vissa delar.
Förutom att rätta upp några felaktigheter från andra programs GEDCOM-->Standard GEDCOM så är ju huvudarbetet att göra en transformering från "Utökad GEDCOM" till "Utökad DiSGEN-GEDCOM". Dessa utökningar ska enbart vara sådant som sparar mycket arbete för användaren vid byte av program, som t.ex. att inte tappa länkarna till alla foton man har.

Man borde börja med att definiera detta "Utökade DiSGEN-GEDCOM-format" och då också tänka på om det finns finesser i DiSGEN som inte går att exportera via standard GEDCOM så bör dessa med i formatet. Om man sedan ska implementera valbar export från DiSGEN (Standard 5.5/Utökad) kan man bestämma senare, men man ska kunna importera dessa utökningar. Och "masseraren" ska kunna översätta från olika andra programs GEDCOM till detta utökade formatet. Som jag har fattat det kan i alla fall rätt många ickestandard-varianter som olika program producerar översättas till korrekt GEDCOM 5.5, det blir bara lite omständligare än programmens egna varianter, så detta utökade format behöver inte bli så omfattande.

Bra vore ju om man delvis kunde styra detta via en konfigurationsfil. Man kunde t.ex. definiera olika varianter på PHOTO-taggar och hur filnamnen skrivs, kommer det sedan ett nytt sätt det skriva i ett annat program behöver man bara lägga till den varianten i konigurationfilen. Programmet testar sedan allt som inte är standard GEDCOM 5.5 mot alla undantag i konfigurationsfilen, en körning kommer att ta ett tag men man ska ju inte köra det en gång i timmen...

DanielBerglund
2013-01-03, 00:57
Jag har kommit in som konsult i system (OK, mycket större) där "källkoden är dokumentationen" och också "lättförstådd". När vi sedan frågat dem om någon programdel och varför den gör som den gör så brukar de inte ha en aning... :D
Men jag tänkte mer på "Vilken GEDCOM 5.5-standard", speciellt angående avvikelser/tillägg, som följs.

Det finns såvitt jag vet bara en enda officiell 5.5-standard, men vad gäller avvikelser, ofullständigheter och tillägg i Disgen får man läsa källkoden. Mängden implementerade privata taggar är i alla fall liten (8 tror jag) och används inte; de är avstängda i de versioner av Disgen som gått ut till allmänheten. Annars finns det t ex en tagg för faddrar. Det är nog ganska otestad mark. Sedan finns det åtskilliga taggar i gedcom som inte stöds i Disgen (tänk på allt det här 'temple ready'-stoffet).

En konfigurationsfil låter bra men jag tror det är tekniskt svårt att "beskriva" avvikelser från gedcomstandarden i en konfigfil. Jag har aldrig kommit till skott, men hade jag gjort den här hanteringen i Disgen hade jag försökt definiera enskilda avvikelser eller tillägg först, på papper, och sedan gjort en lista över alla som ska stödjas. Sedan hade jag skrivit importkod i Disgen och låtit varje "väldefinierad avvikelse" eller tillägg ha sin kodsekvens. Själva användargränssnittet skulle sedan ha varit listor med kryssrutor där användaren väljer vilket program man vill importera från, vilket Disgen skulle mappa på en eller flera "väldefinierade avvikelser", eller så skulle man (avacerat) kunna välja ut enskilda avvikelser direkt.

Vi skulle ju kunna försöka använda wikin för att lista avvikelser eller tillägg och definiera hur de ska hanteras i Disgen och se hur långt vi kommer?

DanielBerglund
2013-01-03, 01:27
Detta blir lite off topic ... Nya databasstrukturen i SQLite är väl inte satt än. Kommer databasen att vara krypterad på något sätt så att man måste gå via Disgens API för att accessa informationen eller kan man öppna den okrypterad i valfritt program?

Har tyvärr ingen erfarenhet av att skapa API, men vi kan väl börja klottra ner i wikin funderingar på funktioner som kan behövas!?

Lite off-topic ja, tror jag skapar en ny tråd. Men wikin är rätt ställe för att skriva ner sådant klotter. Seriöst klotter, som jag sade någon gång...

tommypeters
2013-01-04, 11:41
Det finns såvitt jag vet bara en enda officiell 5.5-standard, men vad gäller avvikelser, ofullständigheter och tillägg i Disgen får man läsa källkoden. Mängden implementerade privata taggar är i alla fall liten (8 tror jag) och används inte; de är avstängda i de versioner av Disgen som gått ut till allmänheten. Annars finns det t ex en tagg för faddrar. Det är nog ganska otestad mark. Sedan finns det åtskilliga taggar i gedcom som inte stöds i Disgen (tänk på allt det här 'temple ready'-stoffet).

En konfigurationsfil låter bra men jag tror det är tekniskt svårt att "beskriva" avvikelser från gedcomstandarden i en konfigfil. Jag har aldrig kommit till skott, men hade jag gjort den här hanteringen i Disgen hade jag försökt definiera enskilda avvikelser eller tillägg först, på papper, och sedan gjort en lista över alla som ska stödjas. Sedan hade jag skrivit importkod i Disgen och låtit varje "väldefinierad avvikelse" eller tillägg ha sin kodsekvens. Själva användargränssnittet skulle sedan ha varit listor med kryssrutor där användaren väljer vilket program man vill importera från, vilket Disgen skulle mappa på en eller flera "väldefinierade avvikelser", eller så skulle man (avacerat) kunna välja ut enskilda avvikelser direkt.

Vi skulle ju kunna försöka använda wikin för att lista avvikelser eller tillägg och definiera hur de ska hanteras i Disgen och se hur långt vi kommer?
Jovistt finns det bara en oficiell GEDCOM-standard, därför skrev jag det inom citationstecken. En del program kan exportera till ett par-tre 5.5-varianter, i huvudsak tillägg för att få med media som foton och stories - alltså länkar till externt material. I mitt träd har jag t.ex 6855 foton (porträtt, AD-källor, vapensköldar, platsbilder från internet) och 1319 stories, det är inget jag vare sig vill vara utan eller länka till manuellt.

Jag tänkte mig att körningen av "masseraren" skulle vara extremt enkel - rentavt simpel - för användaren. Kanske inte ens ett GUI, på sin höjd in- och utfilsnamn anges.

Tanken är helt enkelt såhär:
Man går igenom filen som ska masseras och när man hittar något som inte DiSGEN kommer att känna igen kollar man om man kan identifiera vad taggen + datat är för något. Antingen hårdkodat i programmet eller via en mönsterbeskrivning i en konfigurationsfil (jag har inte tänkt att användaren själv ska behöva ändra i konfigurationsfilen, det skulle föreningen göra och skicka uppdateringar som ett alternativ till programuppdateringar). Känner man igen taggen (t.ex _PHOTO) så översätter man den till "DiSGEN utökat format" och fortsätter sedan i filen tills nästa mysko tag hittas. Man tar varje okänd tag för sig, bryr sig inte om från vilket program det kommer, man vill inte komma in i någon modal körning i programmet.

Christer
2013-01-05, 21:05
Hittade idag ett verktyg för validering av GEDCOM-filer om någon är tänd på att testa. Se http://chronoplexsoftware.com/gedcomvalidator/index.htm

DanielBerglund
2013-01-05, 23:22
Man tar varje okänd tag för sig, bryr sig inte om från vilket program det kommer, man vill inte komma in i någon modal körning i programmet.
Jag tror man måste ta hänsyn till vilket program det är i en hel del fall, t ex om ett visst program genererar i och för sig väldefinierad gedcom men på ett sådant sätt att den inte följer standard. Bara för att hitta på ett exempel: anta att programmet X har växlat betydelsen av IMMI och EMIG men gör i övrigt helt rätt. I ett sådant fall kan inte en masserare veta att IMMI och EMIG ska växlas tillbaka om den inte också vet att filen kommer från just programmet X.

Ett annat fall där jag kan tänka mig att det behövs ett enkelt GUI är där användaren måste ges möjlighet att välja hur konverteringen ska ske. T ex har MinSläkt s.k. konfidentiella noteringar som kan exporteras med den privata taggen _CONF_NOTE. Disgen, däremot, har inte något officiellt begrepp som innebär att en notis är konfidentiell. Tydligen var notistypen "extra text" tänkt så från början men det har inte upprätthållits i praktiken. Här bör man alltså låta användaren av masseraren välja vad som ska ske, dvs välja på några rimliga lösningar som masseraren implementerar.

En sak till som vore bra är om man kan ändra egendefinierade notistyper under konverteringen. Man kanske inte vill använda de som finns i den inkommande gedcomfilen utan vill byta ut dem mot andra.

Nåja, sådana här saker måste inte vara med från början. Det är nog bättre att börja så enkelt som möjligt och se hur långt det räcker i praktiken. Med lite tur räcker det långt nog..

tommypeters
2013-01-06, 00:45
OK, jag tänkte inte på att programmen skulle vara så klantiga som ditt exempel med IMMI/EMIG. Precis när vi fixat det i programmet så rättar de det... :rolleyes:
Jag tänkte mer på att ta hand om tillägg som var icke-standard, då hade väl mitt tänk fungerat.

Som jag skrev är ju tid en bristvara, så jag tänkte göra det så enkelt som möjligt så att en första version skulle bli färdig någon gång. Samt om man inte skulle hinna slutföra det så skulle det vara enklare för någon annan att fortsätta eller vi skulle fortsätta parallellt med varsin del.

DanielBerglund
2013-01-06, 23:20
Håller med om att det är bättre att börja enkelt och bygga om och till med tiden, än att vara överambitiös från början och inte komma i något mål alls.

DanielBerglund
2013-01-09, 00:12
Här är en närliggande tanke. Jag tittade just på en gedcomfil som kommer från Legacy 7.5. Den passar Disgen mycket bättre om man kör den genom följande gawkskript:


/^1 _UID/ { next; }
/^2 GIVN/ { next; }
/^2 SURN/ { next; }
/^3 PAGE/ { x = $0; next; }
/^4 CONC/ { if (x != "") { printf("%s%s\n", x, substr($0, 8)); x = ""; next; }}

{ if (x != "") { printf("%s\n", x); x = ""; }
print $0;
}

Nu kan man ju inte be folk köra gawk, men vi skulle kunna försöka bygga upp en samling kodsnuttar i något annat passande språk (php) och lägga upp dem på webben med ett enkelt gränssnitt där man i princip bara tankar upp sin fil och får tillbaka den masserade filen. Alltså, istället för att göra ett (iofs enkelt) program gör man ett antal programfragment och gör dem körbara från ett gemensamt "skal" på webben.

tommypeters
2013-01-10, 15:28
Jo, det är ju en möjlighet. Men innan jag börjar med något sådant skulle jag vilja veta om DiSGEN överhuvud taget kan ta in den informationen som finns i min GEDCOM-fil, om den blir "masserad", eller om programmet t.ex. inte har någon möjlighet att importera foton ens om man ser till att inga sökvägar för filer finns i GEDCOM-filen etc.
Och dokumentationen över detta är alltså källkoden...?

DanielBerglund
2013-01-11, 01:43
Ja, det finns i alla fall ingen annat skrivet. Sedan går ju trial-and-error i Disgen men det bästa är att försöka kontrollera vad som faktiskt händer bakom kulisserna.

Jag ser (i källkoden) att man hanterar multimediarecords (OBJE), tydligen genom att ta första bilden (definierad som att FORM är någon känd bildtyp, t ex jpg) och sätta den som porträtt och övriga bilder som vanliga bilder. Sedan får man själv kopiera filen till DgPic. Filnamnet förutsätts tydligen vara utan sökväg. Så det finns förutsättningar...

tommypeters
2013-01-14, 01:15
Ja, då är det ju idé att försöka, sedan får jag ta "baby steps" och försöka få fram så mycket tid jag kan...

tommypeters
2013-01-16, 21:48
Går det enkelt att "nollställa" DiSGEN? Nu har jag ju en läsversion med min GEDCOM-fil, för att kunna testa en ny inläsning av en masserad GEDCOM och se hur resultatet blivit så behöver jag ju tömma databasen.

DanielBerglund
2013-01-16, 23:00
Med demoversionen är det nog enklast att först 1) ta bort datamappen med Utforskaren, 2) Låta Disgen skapa en ny top datamapp, 3) Ta en kopia av denna.

När du ska "nollställa" plockar du bort din nedskräpade datamapp och ersätter med en kopia av den kopia du tog ovan. Behåll namnet på datamappen så hittar Disgen till den nästa gång den startar.

Med den riktiga versionen av Disgen gör man nog en variant av det ovanstående men då kan man enkelt skapa nya datamappar och (rätt enkelt) växla mellan dem.