Tests de Visuged Ces tests ont été publiés dans le groupe usenet fr.comp.applications.genealogie. Ce fichier est en UTF-8, les discussions différentes sont séparés par un trait épais (━), les messages d'une même discussion par un trait fin (─). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Groupes de discussion : fr.comp.applications.genealogie De : Patrick Texier Date : Wed, 07 May 2008 10:54:22 +0200 Date/heure locale : Mer 7 mai 2008 10:54 Objet : Test de Visuged 8.24.0 Bonjour, J'avais pourtant dit que cela me fatiguait de tester des programmes gratuits non libres Windows [1]. Je viens de fusionner mon gedcom personnel et mon gedcom noblesse, j'avais trop de liens entre les deux et c'est toujours une mauvaise idée de séparer. On va donc lui fournir 57447 personnes. Premier test : import direct du gedcom en UTF-8. Visuged me demande comment découper les lieux et laisse passer le jeu de caractères. Une demi-heure après (Visual Basic + Access c'est lent), on vérifie le fichier trace et il indique qu'il n'a pas reconnu le jeu de caractères et a considéré que c'était de l'ANSI. On efface tout et on recommence en convertissant le gedcom : on décoche la case pour créer une base à partir du gedcom : pres de 70 Mo pour 11,5 Mo de gedcom, c'est du gaspillage. Voyons voir le fichier trace : > 27 L7951 [2 DATE (jeune)...] 2 DATE (jeune) - L'année est absente ou non > numérique : "(jeune)", la date n'est pas prise en compte. (err.213) Date phrase n'est pas reconnu, dommage. >228 L372907 [2 DATE 23 SEP 6...] 2 DATE 23 SEP 63 B.C. - L'année est > absente ou non numérique : "B.C.", la date n'est pas prise en compte. (err.213) Il faudra aussi se passer des généalogies antiques. > 75 L77239 [1 NAME Claudett...] L'individu Émilie /Chauchoin/ a plusieurs noms, > seul le premier est pris en compte. (err.129) Elle est pourtant plus connue comme Claudette Colbert. >266 L628882 [1 CHIL @I31733@...] L'enfant n°31733 est cité dans deux unions différentes >n°12879 et n°12878. Seule la première est conservée sachant > qu'il peut s'agir d'une adoption. (err.124) >267 L628888 [1 CHIL @I31733@...] L'enfant n°31733 est cité dans deux [...] Effectivement c'est Bernadotte devenu Charles XIV de Suède et il faut effectivement prendre, au pire, la première. Allons voir la fiche (impossible de la coller, il faut retaper) : > de Suède > Charles XIV > né le 26 janvier 1763 > décédé le 8 mars 1944 > fils de de Suède Charles XIII > et de d'Oldenbourg Hélène > marié le 17 avril 1798 avec Désirée Clary. Perdu : il a pris la mauvaise filiation, l'adoptive. La trace laisse penser qu'il utilise CHIL dans FAM pour créer les liens alors qu'il faudrait prendre le premier FAMC dans INDI. Au passage, les noms avant les prénoms c'est franchement atroce surtout avec ce « de de ». Pour avoir les titres de noblesse, il faut aller dans " Affichage >> Evénements et attributs " et on s'aperçoit que l'on a perdu les dates : c'est attribut et valeur. On fait un dernier test d'arbre et on s'aperçoit les noms un peu longs débordent dans tous les sens. Voici un programme tout à fait inutilisable pour la noblesse. Un tour rapide chez les roturiers permet de s'apercevoir que : - il semble que le programme attaque toute l'ascendance (limitée à trente générations) sans rien demander. - c'est le dernier métier (souvent retraité, rentier...) qui est mis dans une case métier. On a la liste sans dates dans les attributs. - spécialité française : si on a pas de naissance ou de décès, il ne va pas chercher les baptêmes et inhumations. - le test des vivants se fait sur la date de naissance. Il me semble que l'épouse d'une personne née en 1958 a de grandes chances d'être encore de ce monde. - avec 11500 noms, l'interface est atroce : cliquer sur la lettre chercher dans plusieurs centaines de noms dans une liste déroulante. - je suis passé rapidement sur les éditions : vu que l'import est défaillant, le résultat est limité et il lance des traitements lourds quand on sélectionne une grosse ascendance. Je ne vois donc pas l'intêret de ce programme qui ne permet pas de visualiser correctement même les informations de base d'un gedcom. On voit bien la différence avec un programme libre comme GenJ, intéressant pour cette fonction de visualisation de gedcoms. -- Patrick Texier vim:syntax=mail:ai:ts=4:et:tw=72 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Visuged 8.40.0 : Anarchy In The Gedcom Patrick Texier 19-03-2009, 11:33 J'avais déjà testé la version 8.24.0 : Je viens de réessayer la version 8.40.0 en important des Gedcoms d'ascendance provenant de LifeLines et dont la structure a été vérifiée. VisuGed est toujours allergique à l'UFT-8 qu'il lit comme de l'ANSEL. Par rapport à la version 8.24.0, les professions et titres de noblesse sont lus intégralement avec les dates et sources, sans que l'auteur ne l'indique dans la liste des modifications. Le reste est un massacre : - il y a un « fantôme » dans le gedcom : 0 @I8@ INDI 1 NAME /indéf./ 1 SEX M 1 CHAN 2 DATE 19 MAR 2009 Aucun enregistrement n'appelle cette clé I8 - les personnes sans noms se voient attribuer un ? - les numéros internes sont modifiés bizarrement (+1) - tous les tags _ sont perdus ; - tous les ASSO sont perdus ; - tous les baptêmes BAPT sont perdus, seul CHR est exporté. - tous les tags ont d'affreux TYPE ajoutés : 1 BIRT 2 TYPE Naissance - les lieux de dépôt sont perdus : 0 @S301@ SOUR 1 TITL Publication de mariage 1 REPO @X2@ L'enregistrement 0 @X2@ REPO n'est plus dans le fichier. - les sources sont tronquées : 1 AUTH Lamy-Denoor, Patrici Pour la norme Gedcom, la longueur est 248 et non 20. - elles ont toutes des tags à vide 1 REPO 2 CALN 3 MEDI. C'est intéressant pour un site Web. Repassons ces gedcoms (sic) Visuged dans un programme de vérification : - Line 22: error unkwown tag [INDI;NPFX] 1 NAME Henri/d'Orléans/ 1 SEX M 1 NPFX prince Effectivement NPFX c'est en niveau 2 sous NAME. - Line 6487: error unkwown tag [INDI;SOUR;TYPE] Line 6488: error unkwown tag [INDI;SOUR;SOUR] Je suis impressionné : voici le premier programme qui source des sources. Voyons voir : 0 @I4847@ INDI 1 NAME Mathurin/Lardeau/ 1 SEX M 1 SOUR 2 TYPE 2 SOUR @S24@ 1 SOUR 2 TYPE 2 SOUR @S581@ Gedcom original : 0 @I4846@ INDI 1 NAME Mathurin/Lardeau/ 1 SEX M 1 SOUR @S23@ 1 SOUR @S580@ En conclusion, Visuged est un programme qui reste toujours aussi mauvais, pire qu'Hérédis. -- Patrick Texier ──────────────────────────────────────────────────────────────────────────────── Patrick Texier 19-03-2009, 14:25 Le Thu, 19 Mar 2009 11:33:16 +0100, Patrick Texier a écrit : > Le reste est un massacre : Un petit complément : - J'aime la gestion des tags avec une valeur Y sans date ni lieu (pour repérer les personnes vivantes et les couples non mariés quand on n'a pas les tags) : 1 DEAT Y devient : 1 DEAT 2 TYPE Décès 1 MARR Y devient le désopilant : 1 EVEN 2 TYPE Evénement - Je me demande de quoi le programme se mèle en ajoutant un NCHI avec le nombre d'enfants pour tous les couples. N'ayant importé que des gedcoms d'ascendance sans collatéraux - je rappele qu'Access c'est lent, je préfère tester 3000 personnes plutot que 77000 -, c'est totalement faux. -- Patrick Texier ──────────────────────────────────────────────────────────────────────────────── Patrick Texier 19-03-2009, 15:21 Le Thu, 19 Mar 2009 11:33:16 +0100, Patrick Texier a écrit : > - tous les ASSO sont perdus ; En fait l'auteur de Visuged n'a jamais du lire la norme Gedcom mais se baser sur les horreurs de la production française. En lecture d'un gedcom Hérédis, il ne trouve qu'une erreur : une date en calendrier hébreu qu'il ne sait pas traiter. Personnellement, j'en trouve 52 dans la démo Duchamp V9 (sans tester ni les cardinalités, ni les valeurs). - Un ASSO (sic) Hérédis est réécrit dans le Gedcom. 1 DEAT 2 TYPE Décès 2 DATE 15 FEB 1878 2 ASSO @I98@ 3 TYPE INDI 3 RELA Witness 3 NOTE son épouse - Concernant le découpage du nom : 2 GIVN Catherine Emilie 2 SURN Coligny 2 NSFX épouse DUCHAMP 2 NICK Khaly est réécrit : 2 NICK Khaly 1 NSFX épouse DUCHAMP 1 NICK Khaly - Les sources Hérédis sont parfaitement (sic) réécrites, le CALN à vide est d'ailleurs exporté par Hérédis : 0 @S274@ SOUR 1 TITL Registre des décès 1 ABBR 0010 - Décès Marie-L. Durouchet - 1894 1 REPO AD Ardèche 2 CALN 4E 2805/8 3 MEDI Transcription - C'est sans doute un oubli, mais on perd les adresses ADDR dans l'export. -- Patrick Texier vim:syntax=mail:ai:ts=4:et:tw=72