Dags att fräscha upp Släkttrim?

[tommypeters]

Det har ju varken hänt så mycket här på forumet eller i själva rutinen senaste året, men det finns ett antal saker som jag tycker man kunde putsa lite på, ett par som borde rättas - och sedan finns det några saker jag undrar över.

Kommer att fylla på med mina synpunkter som kommentarer i den här tråden, andra är förstås också välkomna :)

[tommypeters]

Största felet tycker jag är att RGD enbart går på (relativt) aktuella uppgifter. "Hörup, Kristianstads län" listas under "Ortnamn / Platser som ej kunnat identifieras som församlingar i GEDCOM filen" eftersom Hörup 1970 bytte från Kristianstads län till Malmöhus län. Så "Hörup, Malmöhus län" godtas antagligen - eller kanske "Hörup, Skåne län"...?

Jag vet att jag inte är ensam om att registrera platser enligt vad som gällde vid tiden för händelsen och man vill undvika alla dessa "Cry Wolf"-påpekanden för att i stället hitta de verkliga felen jag har i min forskning.

[tommypeters]

Mindre problem är ju de klagomål på namn man får, där rutinen inte känner till att t.ex. Una var ett kvinnonamn och klagar på det. Det är ju ett "Inte se skogen för bara trän"-problem, där man kan missa ett fel man har i sin data pga alla felaktiga påpekanden. Borde vara enkelt att uppdatera listan över godkända namn.

[tommypeters]

Nästa "grej" är "barn i två familjer".

*** F E L L I S T A (II) Strukturfel

Formellt fel i GEDCOM filen: Barn I14609, som finns i familj F5000, finns även i familjen F8188

Rutinen borde kolla om det är två olika typer av relationer mellan barn och föräldrar - biologisk, adoptiv, foster - och bara klaga på om det är något felaktigt, som två par av biologiska föräldrar.

[tommypeters]

Sedan "Dubbla namnförekomster":

*** V A R N I N G (III) Dubbla förekomster

Dubbla namnförekomster för individ - Id =>

Detta är en bra varning att få om man fått in namn som ett faktum och sedan ett Alternativt faktum utan att riktigt veta om det. Händer relativt ofta med Ancestry när man t.ex. får en "hint" från en Census om en familj som emigrerat till USA. Man ser att det är rätt familj och lägger till denna källa, men namnen är ofta stavade annorlunda och om man inte ser upp får man "Alternative name".

Däremot, om man själv lägger till t.ex. ett smeknamn, borde detta inte rapporteras här. Man har alltså lagt in namnet "Elisabeth Catharina" och lägger sedan till an "Also Known As" med "Betty". Jag tror detta blir annorlunda i GEDCOM-filen jämfört med alternativt namn (har jag fel så är det inte mycket som går att göra åt det hela) och då borde detta inte rapporteras.

[tommypeters]

"Dubbla giftermålsnotiser"

Dubbla giftemålsnotiser för familj - Id => F11150 => 19 APR 1896 (Jfr. I38323)

På grund av en tidigare bugg på Ancestry (hoppas och tror den är borta nu) så kunde giftermål bli dubblerade, jag har många av dessa. Jag bryr mig inte om felstavningen av giftermål, men jag undrar om man skulle kunna få lite mer hjälp? [Detta gäller även vid felrättning av flera andra saker]

Här måste jag söka upp familjeId i GEDCOM, sedan hitta personId i GEDCOM, därifrån få fram namn och födelsedatum så jag sedan kan hitta personerna och familjen i Ancestry. Är det inte möjligt för rutinen att få fram de berörda namnen och presentera dem? Det känns ju som att Släkttrim för matchning och felkontroll först behöver läsa in hela filen och bygga upp en struktur för detta, i så fall borde detta vara möjligt. Görs allt under tiden av en enda genomläsning av GEDCOM-filen går det inte, men då tycker jag att inte allt i Släkttrim heller skulle kunna funka.

[tommypeters]

På grund av dels en sammanslagning av min och min sysslings forskning, dels av att jag ändrat registreringssätt "under vägen" så är adressinfon i mitt träd inkonsistent. Nu registrerar jag in adress som "plats, socken, län" medan det tidigare ibland kunde bli "socken, plats, län". Och denna blandning kan ju som bekant varken DisByt eller dess ombud hantera bra.

Carl-Johan Gustafsson har därför skrivit ett (eller några) script som matchar texten på adressraderna mot en databas med sockennamn och då "vänder" det mesta rätt. Jag mailar min fil till honom och får resultatet tillbaka. Om det är möjligt vore det naturligtvis bra att få det som ett valbart tillägg i Släkttrim :)

[tommypeters]

Mindre problem är ju de klagomål på namn man får, där rutinen inte känner till att t.ex. Una var ett kvinnonamn och klagar på det. Det är ju ett "Inte se skogen för bara trän"-problem, där man kan missa ett fel man har i sin data pga alla felaktiga påpekanden. Borde vara enkelt att uppdatera listan över godkända namn.

Till exempel klagas det på kvinnonamnen Botil, Bothel, Botill, Bothil, Hennike, Una, Tove, Jean, Ingiar, Holmfrid, Gotthild, Kristen och Kjellög.
Mansnamn som inte passar är t.ex.: Julle, Jeppa, Orlin, Troen, Alva och Carol. [De två sistnämnda låter ju feminina...]

[tommypeters]

Värst vad det ekar här inne...

[Torgny Larsson]

Flera i produktrådet har säkert semester eller tagit ledigt från Disgen liksom berörda utvecklare. Eller värmen. Supporten upprätthåller vi hela sommaren, men antalet fadderärenden är lågt just nu.

[tommypeters]

Jo, jag förstår det :-)

[tommypeters]

Största felet tycker jag är att RGD enbart går på (relativt) aktuella uppgifter. "Hörup, Kristianstads län" listas under "Ortnamn / Platser som ej kunnat identifieras som församlingar i GEDCOM filen" eftersom Hörup 1970 bytte från Kristianstads län till Malmöhus län. Så "Hörup, Malmöhus län" godtas antagligen - eller kanske "Hörup, Skåne län"...?

Jag vet att jag inte är ensam om att registrera platser enligt vad som gällde vid tiden för händelsen och man vill undvika alla dessa "Cry Wolf"-påpekanden för att i stället hitta de verkliga felen jag har i min forskning.

Det man förstås då undrar över, vilket är viktigare, är om DisByt också har samma problem...?

[tommypeters]

...och jag har ju skrivit "RGD" på en eller ett par platser oven, jag menar ju "Släkttrim", för oavsett vad som händer med RGD så är Släkttrim det bästa verktyget jag hittat (och borde göras mer reklam för) - men ingenting är ju så bra att det inte kan förbättras :-)