Bonjour,
Voilà un sujet qui fait courir les doigts sur les claviers.
Si je puis y ajouter ma goutte d'eau (certains diront un seau).
Entièrement d'accord sur la première condition de cette remise à jour qui est que l'intégralité des informations des utilisateurs doivent être sauvegardées.
Celà amène tout de suite une conséquence: Ancestrologie doit pouvoir importer les anciens gedcom qu'il a émis, même s'ils utilisaient des tags illégaux.
L'intérêt des utilisateurs peut se résumer ainsi:
Ils veulent que l'importation dans Ancestrologie d'un gedcom généré par Ancestrologie permette de transférer toutes leurs informations (c-a-d sans pertes, même pour des informations spécifiques à Ancestrologie).
Ils veulent que le gedcom exporté respecte au mieux la norme gedcom 5.5 afin que son importation dans un logiciel respectant ce standard ne fasse perdre aucune des informations normalisées.
Ils veulent qu'Ancestrologie puisse récupérer au minimum les informations émisent par d'autres logiciels dans la forme normalisée. Ce serait un plus non négligeable, pour eux comme pour Philippe, qu'Ancestrologie puisse accepter des informations venant de logiciels ne respectant pas parfaitement la norme.
Sur les principes rappelés par Aquablue, concernant la mise en conformité de l'exportation, je ne pense pas qu'il y ait beaucoup de divergences. Je n'en ai personnellement que sur quelques détails ou sur des solutions proposées. En particulier sur des solutions qui feraient perdre des informations à des utilisateurs ayant utilisé des tags erronés. Sans oublier que ces tags ont souvent été ajoutés à la suite de la demande des utilisateurs...
Pour les événements créés avec des tags spécifiques, je pense que la solution est effectivement de les transformer en événements divers exportés en:
1 EVEN
2 TYPE Descrition de l'événement
Pour celà je pense utiliser la solution déjà existante dans Ancestrologie qui consiste à mettre en Titre le libellé long du type actuel de l'événement. Lors de l'exportation ce Titre est placé devant ce qui existe dans le champ "Description", séparé par un caractère "espace insécable" (#160) qui ne choque pas sur les systèmes ne différentiant pas le titre de la description. A l'importation, Ancestrologie sépare le Titre de la Description en reconnaissant ce caractère.
Seul problème, la longueur totale exportée ne devrait pas dépasser 90 caractères. Mais j'ai cru comprendre que celà est très théorique, la plupart des logiciels ignorant cette limite. Il faudra peut-être adapter Ancestrologie pour qu'il ne tronque pas la description à l'importation.
Pour le LIEU, la mise à jour en base b4.052 en septembre 2006, a ajouté une procédure utilisée par le logiciel (menu Lieux/ Mise à jour des coordonnées géographiques/ Avec transfert subdivision) pour effectuer le transfert du contenu de LIEU dans SUBDIVISION, quand ce dernier était vide. Mais il n'est pas certain que tous les utilisateurs aient fait ce transfert. De plus le champ LIEU restant disponible, on a pu continuer de l'utiliser. On ne peut donc purement et simplement décider de l'ignorer.
Pour le choix entre CP et INSEE à inclure dans PLAC, il peut être proposé lors de l'exportation. Il faudra également modifier le parseur d'importation pour qu'il offre le même choix. Pour aider l'utilisateur à faire ce choix à l'importation, il faudra que la ligne précisant ce format dans l'en-tête du gedcom soit affichée.
Mais contrairement à ce qui a été écrit dans ce fil, le couple "Ville + premier code" ne permet pas de toujours retrouver automatiquement le code manquant.
A un couple Ville + INSEE, regardez bien dans la table de référence des villes, vous y constaterez qu'il peut correspondre plusieurs codes postaux. Si au couple Ville + CP correspond en France un seul code INSEE, je n'ai pas la certitude qu'il en est de même dans tous les pays.
Il faut donc continuer à exporter le code exclu de PLAC.
La norme gedcom a prévu un champ NOTE multilignes subordonné à PLAC, non utilisé par Ancestrologie. La solution que je propose est d'y mettre les "exclus" sous la forme:
1 EVEN
2 PLAC <<stucture plac>>
3 NOTE LIEU mon lieu préféré
4 CONT CodeExclu valeur
CodeExclu pouvant être INSEE ou Code Postal.
Cette forme ne devrait pas être trop difficile à décoder par Ancestrologie lors de l'importation, et ne choquerait pas lors de l'importation dans un autre logiciel (qui de plus y retrouverait des informations utiles).
FILA; la solution proposée par Aquablue ne me semble pas satisfaisante (dans le TYPE de BIRT):
- la description (exportée aussi dans TYPE) peut déjà exister, même si utilisée à tort,
- Si la date et l'endroit de naissance sont ignorés faudra-t-il créer l'événement pour y mettre cette information?
- Dans le cas d'un enfant adopté, la naissance ne correspond pas à l'entrée dans la famille.
La norme prévoit 2 tags subordonnés à FAMC (famille dont l'individu est enfant):
PEDI <PEDIGREE_LINKAGE_TYPE>
mais seules les valeurs [ adopted | birth | foster | sealing ] y sont acceptées, dommage..
NOTE champ multiligne
Pourquoi ne pas y mettre la valeur de notre champ FILIATION selon la même technique que pour INSEE et LIEU ci-dessus?
TYPU; si ce champ disparaissait de mon écran j'en serai très satisfait. Je n'ai jamais compris à quoi il sert ni comment le remplir. Il n'apporte aucun renseignement puisqu'il y a redondance avec les événements saisis pour l'union, en particulier si on se sert de la description.
Si c'est pour indiquer qu'il y a eu un mariage mais qu'on en ignore le lieu et la date, il est préférable de créer un événement MARR vide. Il est exporté avec "?" comme prévu par la norme pour être importé.
Si les individus se sont mariés, ont divorsé, puis ce sont remis à vivre ensembles (j'en connais), que faut-il mettre?
Ne pourrait-on traiter en automatique selon les cas:
TYPU=Mariés, créer un événement MARR s'il n'existe pas
TYPU=PACS, créer un événement MARR s'il n'existe pas, et mettre PACS en description
TYPU=Concubinage, Union libre, Relation extra-conjugale ou Séparés, créer un événement Divers avec le TYPU en description.
Et enfin, nous débarasser définitivement de ce TYPU.
Quand à la création OBLIGATOIRE de MARR pour une union, je ne suis pas d'accord sur ce point avec Aquablue. Il a fait en son temps l'objet d'une discussion avec Lya.
Je n'ai pas trouvé dans la norme quoi que ce soit qui permette de donner à MARR un autre sens que celui d'un événement familial. "Un événement légal, coutumié de création d'une famille, unissant un homme et une femme comme mari et femme".
La confusion vient peut-être de l'utilisation du mot "Union" dans Ancestrologie, à la place du "Famille" utilisé dans la norme.
Concernant l'ordre des événements, il est actuellement défini dans Ancestrologie par ordre de priorité des valeurs:
Ordre, Année, Mois, jour, type.
On voit donc que par défaut c'est la date qui permet d'ordonner les événements. En absence de valeur dans les 4 premiers champs, le type permet de classer BIRT en tête. L'utilisateur a aussi la possibilité de forcer un ordre, si aucun des autres n'est satisfaisant, en donnant une valeur au champ Ordre.
L'exportation doit respecter cet ordre. Mais comme dans certains cas le champ "Ordre" est indispensable pour qu'Ancestrologie sache ordonner les événements, il doit être transmis dans le gedcom, avec un tag spécifique à Ancestrologie. Je ne vois pas d'inconvénients à utiliser le _ORDR proposé par Philippe.
Il en est de même pour les étiquettes suivantes pour lesquelles je n'ai pas trouvé d'équivalence dans la norme:
_ACTE qui permet de déclarer que l'acte d'un événement a été trouvé,
_IDEN qui permet d'identifier la photo qui paraîtra en identité de l'individu
Pour l'exportation des médias, leur exportation sous la forme prévue dans la version 5.5.1 (forme utilisée dernièrement pour l'exportation standard) semble inconnue de la majorité des logiciels. Il semble donc opportun d'en revenir à la version 5.5. Lors de l'importation, c'est l'adresse physique du fichier qui doit servir à identifier le média pour reconstituer la médiathèque.
Les anciens tags XTYPE et XMODE devrait pouvoir être remplacés en utilisant correctement le FORM normalisé.
Reste le problème des domiciles. Il me semble indispensable d'utiliser RESI, au lieu de ADDR dans un sens illégal.
Les domiciles pourraient alors être récupérés par les autres logiciels dans la liste des événements et attributs. PLAC est nécessaire dans ce cas, mais seul il ne permet pas d'exporter certains champs utilisés pour les domiciles. Ce que permettrait la structure ADDR (utilisée alors légalement), et conjointement à PLAC (ce qui ne me semble pas interdit dans la norme, et actuellement fait dans l'export standard).
Voilà, j'ai été long, mais il me semble indispensable d'être exhaustif pour qu'un document serve de ligne conductrice à la mise à jour de l'export/import gedcom d'Ancestrologie.
Ce qui n'interdit pas de faire des commentaires, demandes ou apports d'éclaircissements que vous le jugerez utile.
A+
André
Accueil
Aide
Rechercher
Identifiez-vous
Inscrivez-vous
