Problem med GEDCOM 5 import i Disgen

[tommypeters]

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]

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]

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]

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]

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!?

[DanielBerglund]

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...

[DanielBerglund]

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.

[tommypeters]

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...
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]

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...
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?

[tommypeters]

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]

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]

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]

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...
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.