Auteur Sujet: GEDCOM quand tu nous tiens  (Lu 5212 fois)

plus minus reset

0 Membres et 1 Invité sur ce sujet

Hors ligne Facon

GEDCOM quand tu nous tiens
« le: 16 Décembre 2005 à 14:11:46 »
Bonjour à tous,



En examinant les tags dans "Import/Export Les TAGS de Gedcom" je me suis rendu compte TITR était devenu TITR ne pas utiliser.



A la lecture des documents établis par Aquablue et Lya, il ressort que dans la plus grande majorité des cas, le traitement des Exports par Ancestrologie se fait sous la forme TAG Desc au lieu de 1 TAG, 2 TYPE Desc.



Nous le savons depuis longtemps, il y a des TAGS intrus, des TAGS en double et des TAGS non-conformes dans leur constitution.



Est-il concevable d'étendre la recommendation "ne pas utiliser" ou équivalent aux TAGS en double tout en conservant la structure de l'export (comme pour les TAGS standards) puique la mise en conformité est un travail de grande ampleur. Il faudrait que cette indication apparaisse aussi dans l'étiquette de l'événement.



Il existe notamment: BURI Sépulture et INHU Inhumation.

Pourquoi ne pas mettre: BURI Sépulture et INHU Inhumation (utiliser BURI). J'ai pris ce TAG car la traduction de BURI (BURIal) aurait dû être Inhumation. Le changement d'étiquette d'événement ne peut se faire que plus tard pour éviter les confusions.



A partir de là, l'utilisation des TAGS intrus se réduirait progressivement et contribuerait vraisemblablement un traitement moins compliqué de la structure des exports.



En prévision de son cadeau de Pâques, serait-il concevable par André de rebaptiser automatiquement les TAGS intrus vers les TAGS standards en prenant garde aux cas où les deux types de TAGS ont été utilisés.



L'idée générale est de franchir un premier pas vers le Gedcom standard et de ne plus inciter à utiliser les TAGS qui devraient disparaître à terme.
Christian
 

Hors ligne guillaume simonnet

  • AncestroSenior
  • *****
  • Messages: 1 686
    • http://mapage.noos.fr/guillaume.simonnet/
GEDCOM quand tu nous tiens
« Réponse #1 le: 16 Décembre 2005 à 15:51:40 »
ne pas oublier que ces problemes d'etiquette gedcom peuvent etre regles grace a l'excellent logiciel mouliged concocte par notre ami aquablue aka marc  :wink:



vous pouvez telecharger cet utilitaire gratuitement sur son site 8)
l'abus de forum peut être dangereux pour votre santé...
 

Hors ligne Facon

GEDCOM quand tu nous tiens
« Réponse #2 le: 16 Décembre 2005 à 20:00:03 »
Bonsoir,

Nous n'en sommes pas au stade de réparer un simple problème d'étiquette.

Si MOULIGED, que je connais, est la panacée, il ne reste plus qu'à le greffer sur Ancestrologie pour traiter des exports.

Il faudra alors construire un DEGILUOM pour les imports.

C'est curieux comme ce sujet est tabou!!!
Christian
 

Hors ligne DDdeBerdeux

GEDCOM quand tu nous tiens
« Réponse #3 le: 16 Décembre 2005 à 23:55:39 »
Tu me donnes là des responsabilités pour les-quelles je n'ai pas la compétence. J'ai examiné les tableaux édités par Lya et Aquablue sur leurs sites, et j'en ai conclu, qu'il n'y avait guère que le remplacement de TITR par TITL qui pouvait se faire facilement, d'autant plus qu'Ancestrologie ne réimportait pas le TITR qu'il avait exporté. Les autres "étiquettes" semblent nécessiter une description complémentaire. Si on en remplace le libellé français, pour le remplacer par "ne plus utiliser", que vont dire les utilisateurs qui vont le voir dans leurs fiches?. Ce n'est pas le cas pour TITR, parce que cette étiquette a été remplacée dans la table des évènements par TITL.

Bonsoir

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Facon

GEDCOM quand tu nous tiens
« Réponse #4 le: 17 Décembre 2005 à 01:40:24 »
Bonsoir ou bonne nuit,

Mon propos n'est pas de donner des responsabilités à l'un ou à l'autre. Dans le cas précis de INHU et BURI, le traitement actuel est le même en termes d'export, tout comme TITL et TITR si on ne change rien après. C'est le poids des années et le résultat, dans certains cas, de mauvaises traductions. Avec cet amendement le fonctionnement n'en sera pas ni meilleur ni plus mauvais.

Ramener les informations sur BURI ne me donne pas l'impression de révolutionner Ancestrologie, c'est juste à mon avis une manière simple de limiter graduellement l'usage de TAGS illicites, dont INHU. Si et seulement si un jour il est envisagé de s'attaquer à cette difficulté il faudra bien en passer par là.

Dans un premier stade, il n'est pas question de toucher au traitement profond des exports mais juste de dissuader l'utilisateur de recourir aux TAGS intrus. C'est d'autant plus facile qu'il n'y a pas de contrainte particulière imposée à l'utilisateur.

Maintenant s'il est préférable de soigner les "défauts" de confort non-gedcom, c'est un choix de la communauté. Dans ce cas il faut dissuader la même communauté de rêver au sujet des améliorations de fond d'Ancestrologie et de ce qui est sa raison d'exister.

Gagner trois secondes pour saisir un date, cinq secondes pour entrer un nouvel individu, etc... représente quoi en terme de temps passé sur le forum pour répondre à des questions qui reviennent sans cesse sur le même thème et qui semble ne pas retenir l'attention en terme de correction. On verra plus tard.... après le confort.

C'est mon avis et c'est bien sûr contestable.
Christian
 

Hors ligne Charlet

GEDCOM quand tu nous tiens
« Réponse #5 le: 17 Décembre 2005 à 07:45:34 »
Membre de cette communauté je rejoins tout à fait cet avis
Cordialement Roger
 

Hors ligne AquaBlue

GEDCOM quand tu nous tiens
« Réponse #6 le: 17 Décembre 2005 à 12:05:31 »
Citation de: "Facon"
Si MOULIGED, que je connais, est la panacée, il ne reste plus qu'à le greffer sur Ancestrologie pour traiter des exports.

Il faudra alors construire un DEGILUOM pour les imports.

C'est curieux comme ce sujet est tabou!!!


Tout d'abord ce n'est surement pas la panacée mais tout au plus un complément.

MouliGed est écrit en VB6 alors qu'Ancestrologie l'est en DELPHI 7  :!:

Enfin MouliGed utilise le fichier GEDCOM créé par Ancestrologie mais ne le "crée" pas.

Enfin rien ne s'oppose à transformer tous tes TITR en TITL et tous tes INHU en BURI dans ton GEDCOM et de re_importer ce dedcom modifié dans Ancestrologie. (même remarque pour LIEU passé en Subdivision)



J'évite les champs ou fonctions mal exportés/importés et la totalité de mes données, soit plus de 25 000 fiches, est exportable/importable sans aucunes pertes.
 

Hors ligne DDdeBerdeux

GEDCOM quand tu nous tiens
« Réponse #7 le: 17 Décembre 2005 à 14:31:47 »
Bonjour,

Citation de: "Facon"
Dans le cas précis de INHU et BURI, le traitement actuel est le même en termes d'export, tout comme TITL et TITR si on ne change rien après.
C'est justement parce que dans le tableau de Lya, les 2 cas ne sont pas traités de manière identique que je ne pensais pas pouvoir faire la substitution simplement.

Maintenant, si les spécialistes du gedcom disent qu'il est possible de systématiquement remplacer INHU par BURI dans les évènements individuels, je peux vous proposer de le prévoir dans une prochaine mise à jour de la base, en changant le libellé de INHU en "ne plus utiliser" ou "remplacer par BURI". Et regrouper les modifications du même type.

Pour le LIEU passé en subdivision, c'est autre chose. C'est le programme qui définit les champs qu'il exporte. Et çà il n'y a que PCM qui peut le modifier. Mais je ne vois pas trop ce qui gène Marc, est-ce uniquement le nom porté sur la fiche? Dans ce cas il suffirait de permuter les étiquettes "Subdivision" et "Lieu" sur la fiche évènement?

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne AquaBlue

GEDCOM quand tu nous tiens
« Réponse #8 le: 17 Décembre 2005 à 19:22:51 »
LIEU n'existe pas dans GEDCOM.

Aucun autre programme n'est capable de reconnaitre ce champ.

Ce champ est totalement inutile et ne sert à rien (voir explications sur mon site).

Subdivision même s'il est mal placé, est le champ à utiliser à la place de LIEU ce qui permet de le retrouver, à la bonne place, dans Hérésie et qui permet de l'importer correctement dans les programmes équipés de "parser". Enfin un outil comme GedLieu permet de remettre ce champ dans l'ordre qu'on souhaite.



MouliGed sait mettre ce qu'il y a dans LIEU dans Subdivision si ce champ est vide sinon il le met en note préfixé de "LIEU :"
 

Hors ligne Facon

GEDCOM quand tu nous tiens
« Réponse #9 le: 18 Décembre 2005 à 01:32:50 »
Bonne nuit à tous, bonne nuit André,

Je crois en définitive m'être mal exprimé. Lorsque je parle d'une légère intervention c'est pour envisager la modification suivante:

Par exemple de regouper les informations relatives à Sépulture et Inhumation sur le seul tag légal BURI qui a lui seul regroupe bien les deux fonctions et d'autant plus qu'elles sont identiques.

Aujourd'hui l'export se fait sous la forme: 1 TAG Desc et après modification ou incitation il resterait 1 TAG Desc.

Il est clair que ce n'est pas le bon langage mais nous avons bien compris que passer au bon format d'export était compliqué et à faire au niveau PCM. Je persiste à penser qu'il ne faut pas perdre de vue cette ultime mise au point pour laquelle PCM réclamera une description précise du travail à faire.

J'ai bien conscience que ces modifications ne mettent pas Ancestrologie en conformité avec le standard Gedcom mais au moins le processus est lancé pour dissuader l'utilisateur de recourir à des tags intrus en double avec les tags légaux.

C'est notamment le cas de BENE, de INHU et de DIPL

Il y aurait lieu aussi de reprendre le libellé de certains tags qui ne sont pas en ligne avec le standard. Je pense en particulier à GRAD pour Diplome, EDUC pour Niveau d'instruction, etc....

Faut-il par ailleurs doubler VOYA avec TRIP qui sont à priori deux intrus tout en gardant à l'esprit que le format d'export futur sera d'une structure différente. Il y a aussi une confusion entre STAE et STAT.



Je reviens aussi sur TITR ne pas utiliser dans les Tags de Gedcom. C'est une alerte mais est-elle efficace car en définitive l'utilisateur ne passe pas par ce chemin pour entrer sa généalogie. Le seul rappel efficace à mes yeux se trouve au niveau des étiquettes des Evénements.



Enfin, il semblerait que CTY pour CITY soit une simple faute de frappe. Si tel est le cas pourquoi ne pas en profiter pour peaufiner la propreté?



Les documents établis par Aquablue il y a très longtemps et par Lya plus récemment sont assez clairs sur ces questions.



Alors bien sûr il est possible de recourir à des outils pour reformater les gedcoms élaborés par Ancestrologie mais ce n'est pas très élégant et pas toujours à la portée de chacun.
Christian
 

Hors ligne DDdeBerdeux

GEDCOM quand tu nous tiens
« Réponse #10 le: 18 Décembre 2005 à 10:45:56 »
Bonjour,

Citation de: "Facon"
Je reviens aussi sur TITR ne pas utiliser dans les Tags de Gedcom. C'est une alerte mais est-elle efficace car en définitive l'utilisateur ne passe pas par ce chemin pour entrer sa généalogie. Le seul rappel efficace à mes yeux se trouve au niveau des étiquettes des Evénements.
Si tu retrouves des TITR avec ce libellé dans tes gedcom, c'est sans doûte parce que tu as mis à jour ta table de référence à l'aide du fichier ref_evenements.txt qui était joint à maj_b357_b4005.exe, sans mettre à jour la table des évènements individuels de ta base par l'exécutable.

Si tu avais passé sur ta base l'exécutable de mise à jour maj_b357_b4005.exe ou >b4005 (qui n'a pas été officialisée sur le site), tu aurais modifié la table de référence des évènements en changant le libellé long "ne plus utiliser" du tag TITR et en le rendant inaccessible lors de la sélection d'un nouvel évènement, et remplacé dans la table des évènements individuels, les TITR par des TITL. Tu n'aurais donc plus de TITR dans ton export.

Cà ne peut pas être dû à une importation, puisque Ancestrologie n'importe pas les TITR.

Ce qui serait possible, c'est à partir de la liste de Marc (à moins qu'il préfère Aquablue), inclure dans une mise à jour globale de la base (maj_b357_b4xxx.exe) et dans une maj ne concernant que ces tags (maj_tag_eve.exe), un script faisant ces mises à jour de tags comme celà a été fait pour TITR/TITL.

Ce script ne pourrait concerner que des évènements, se trouvant dans la table des évènements comme BENE/BLES, DIPL/GRAD, INHU/BURI, éventuellement les Xxxx/_xxx (à tester compatibilité du _ avec ancestrologie, et devrait s'accompagner de la création des nouveaux tags dans la table de référence, à moins que l'on préfère attendre la révision globale pour qu'ils soient remplacés par EVEN/TYPE comme le suggère Marc).

Les anciens tags resteraient dans la table de référence pour permettre l'importation d'un ancien gedcom. maj_tag_eve.exe permettrait de remettre en conformité la base après une telle importation.

Mais cette maj ne peut concerner (à part la création dans la table de référence de CITY par exemple) certains tags gérés directement par le programme lors des imports/exports (CTY/CITY, XORD/_ORD, STAT/STAE, INSEE/_INS).

Seriez-vous d'accord sur cette proposition?

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Facon

GEDCOM quand tu nous tiens
« Réponse #11 le: 18 Décembre 2005 à 11:37:12 »
Bonjour, Bonjour André

Sur la première partie, pas de problème pour moi et d'ailleurs j'utilise relativement peu le gedcom car lorsque je procède à une communication de données j'utilise la base. Mon correspondant dispose d'Ancestrologie.

La base a bien été màj avec l'outil b3.57_b4.010 et en tous cas, je suis d'accord avec les explications.



Sur la seconde partie, ma suggestion ne porte que sur les tags ayant le même profil d'export. Je n'ai donc pas intégré les Xxxx ou X_xxx. Au risque de me répéter, la proposition n'est pas de créer une nouvelle situation illégale mais de tirer le parti des cas anormaux d'aujourd'hui pour assainir la situation.



Enfin, dans la mesure où les interventions restent sur le module hors Ancestrologie, il reste aussi des libellés en français de tags légèrement ou sensiblement décalés par rapport à ceux en anglais du standard gedcom. Dans la mesure où ceci n'apporte pas de confusion, ce serait bien aussi d'y passer. Le travail de Marc est une bonne base de référence.



En définitive, si les interventions sont légères, si elles n'engendrent pas de difficulté pour l'utilisateur en termes d'import ou d'export et si elles ne sont pas de nature à amener de nouveaux bugs irrascibles, je suis d'accord pour supporter la proposition qui exclut le traitement des tags devant, un jour, être exportés selon la structure 1 EVEN; 2 TYPE xxxx Desc.
Christian
 

Hors ligne DDdeBerdeux

GEDCOM quand tu nous tiens
« Réponse #12 le: 18 Décembre 2005 à 16:23:29 »
Pour donner suite à ce sujet, je propose http://www.ybruant.magic.fr/phpBB2a/viewtopic.php?p=35029#35029 sur le forum développement, un script de mise à jour.

Si les spécialistes (ou moins) du gedcom pouvaient y donner leur avis.

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)