Utskriftsvy
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
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.
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
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.
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
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.Citat:
Ursprungligen postat av DanielBerglund
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... :-))
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 ...Citat:
Ursprungligen postat av tommypeters
Ett exemplar av Disgen till de som utvecklar på Disgen eller angränsande program är inget problem alls.Citat:
Ursprungligen postat av 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.Citat:
Ursprungligen postat av tommypeters
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.Citat:
Ursprungligen postat av tommypeters
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.Citat:
Ursprungligen postat av tommypeters
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.
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?Citat:
Ursprungligen postat av 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!?
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".Citat:
Ursprungligen postat av 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... :DCitat:
Ursprungligen postat av DanielBerglund
Men jag tänkte mer på "Vilken GEDCOM 5.5-standard", speciellt angående avvikelser/tillägg, som följs.
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.Citat:
Ursprungligen postat av DanielBerglund
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...
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).Citat:
Ursprungligen postat av tommypeters
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?
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...Citat:
Ursprungligen postat av Phryxe
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.Citat:
Ursprungligen postat av DanielBerglund
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.
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
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.Citat:
Ursprungligen postat av tommypeters
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..
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.
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.
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:
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.Kod:/^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;
}
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...?
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...
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...
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.
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.