forum Ancestrologie
Ancestrologie - Développement => Développement => Discussion démarrée par: Ancestrologie le 19 Janvier 2008 à 09:47:21
-
Bonjour
Voici une nouvelle beta à la meme place
Qui de 9 dedans ?
Avec André, on commencé à revoir le Gedcom
j ai donc commencé par l'Export, tous les tags Ancestro, ont maintenant une codification Gedcom CAD _XXXX
Dites nous s'il en reste, et ci cet export est correct
J ai bien parlé de l'export et non de l'IMPORT
-
Bonjour Philippe,
J'ai chargé et examiné la version que tu as mis à disposition avec les modifications relatives aux tags gedcom.
J'ai comme l'impression que tu n'as pas compris le message qui n'est jamais que la traduction libre du standard gedcom 5.5 auquel tous les logiciels de généalogie doivent ou devraient se référer. Au risque d'insister, je reprends ici un extrait du standard:
We do not encourage the use of user-defined GEDCOM tags. Applications requiring the use of non-standard tags should define them with a leading underscore so that they will not conflict with future GEDCOM standard tags. Systems that read user-defined tags must consider that they have meaning only with respect to a system contained in the HEAD.SOUR context.
Je crois que la langue mormon ou américaine proche de l'anglaise te pose quelque soucis, en tous cas cet extrait indique que la création de tag propriétaire n'est pas encouragée.
A l'examen d'un export gedcom, j'ai constaté que tu avais fait le nécessaire pour modifier les tags intrus dans le sens de leur donner une allure en ordre avec le standard: _xxxx..... Dans mon esprit la seule action vraie et efficace aurait dû être d'éliminer ces tags dans toute la mesure du possible et dans le cas présent la mesure avoisine zéro.
Il ne sert strictement à rien de créer des tags propriétaires alors qu'il est possible en respectant scrupuleusement le standard de décrire des événements particuliers ou des indications spécifiques. Procéder autrement est parfaitement irréaliste ou alors c'est le constat d'une mauvaise ou de l'absence de compréhension du standard.
Chaque tag propriétaire est une raison de ne pas être compatible avec les autres logiciels. Il est inutile de citer des noms dans ce domaine.
Je reprends une ligne de conduite indiquée dans un autre message qui disait à peu près ceci: la recherche de la conformité au gedcom est un objectif à suivre sans restriction avec pour but de pouvoir dire haut et clair que le produit Ancestrologie est conforme au standard, mais aussi d'être en position de pouvoir échanger des informations avec d'autres logiciels avec le minimum et idéalement sans perte d'information. Ancestrologie devrait être tolérant pour accepter des gedcoms s'éloignant du standard, mais il devrait être aussi et surtout en mesure de délivrer des gedcoms conformes au standard et compréhensibles par les autres dans le cadre du standard.
Les produits normalement constitués sont en mesure de comprendre en particulier EVEN + TYPE ce qui ne semble pas avoir été retenu dans ta démarche. Par l'utilisation de cette description tu peux, tu dois réduire considérablement les tags exotiques ou propriétaires, c'est le seul moyen d'être compris par les autres.
J'ai bien compris que seul l'export avait été examiné dans ce domaine, les modifications apportées font que l'import n'est plus opérationnel.
Je n'ai pas la connaissance suffisante du standard gedcom pour avoir un avis autorisé, par contre j'ai la capacité de le lire et de comprendre son contenu. C'est ce qui me confirme dans l'idée que tu fais fausse route en agissant uniquement sur l'orthographe des tags.
Je suis persuadé que tu aurais beaucoup à gagner à prendre en considération les recommandations d'Aquablue
http://www.ancestrologie.org/forum/index.php?topic=8991.msg58328#msg58328
qui en plus de son verbe parfois caustique, a l'immense avantage de bien connaître le standard gedcom. Il a toujours eu des interventions constructives dans ce domaine et j'espère fort qu'il viendra remettre une couche sur ce message.
-
We do not encourage the use of user-defined GEDCOM tags.
Normal au départ le gedcom est fait par les mormons pour les mormons et leur soft, donc sur qu ils vont pas encourager la pratique
Chaque tag propriétaire est une raison de ne pas être compatible avec les autres logiciels.
C est sur cette vérité. Mais le but du tag propriétaire est d être compatible avec le soft qui l a émis
et donc les autres soft ne l importent pas
ex : la clef fixe que j exporte, h.... n en a rien a faire
Chaque soft à ses spécificités et donc il faut pouvoir en tenir compte
-
Philippe,
Peu importe par qui a été rédigé le standard gedcom. Il est bon ou mauvais selon le portage que l'on souhaite avoir, néanmoins c'est le seul texte ayant une large reconnaissance chez les utilisateurs. Même si le contenu peut laisser quelques portes ouvertes, autant utiliser le langage gedcom pour exprimer ce qui éventuellement n'a pas été pris en compte à l'origine.
Tu as toi même inscrit à tort dans l'export gedcom que "Le format GEDCOM est "normalisé" par un groupe de travail..... Ancestrologie respecte scrupuleusement cette norme (GEDCOM 5.5.1 Standard). Les travaux en cours apportent la démonstration du contraire mais ils restent une excellente initiative si l'objet est bien de s'appuyer sur le standard. L'avenir d'Ancestrologie en dépend.
Tu parles de la clef fixe, soit, mais c'est l'idée que tu te fais.
Tu passes sous silence et cette liste n'est pas exhaustive: _FILA, _INSE, _LIEU, _REGI, _SUBD et tous les autres créés à la va vite et dans la précipitation: XLOI, XSPO, X_MU1, X_MU2, X_MU3, XHENN, XHOUP, VOYA, etc....
Pour chacun de ces tags c'est une raison d'être ignoré par les autres logiciels quand ce n'est pas aussi une raison d'être ignoré par soi même.
-
Bon alors pour faire plaisir à Facon je vais être "caustique" :
Une voix crie dans le désert.......... :evil: :evil:
Il n'y a pas pire sourd que celui qui ne veut pas entendre :!: :grin:
Et ici on ne parle que de l'export.
Normalement pour l'import il faudrait être compatible avec tous les concurents et donc comprendre et importer correctement dans Ancestro toutes les particularités spécifiques à chacun si c'est une donnée importante.
-
Une voix crie dans le désert
Aplanissez le chemin d.............
-
Aquablue a écrit
Normalement pour l'import il faudrait être compatible avec tous les concurents et donc comprendre et importer correctement dans Ancestro toutes les particularités spécifiques à chacun si c'est une donnée importante.
.
Ce qui, plutôt que de bidouiller n'importe quoi, serait une fois réalisé un bon argument de vente, et attractif pour les utilisateurs d'autres logiciels.
A+
-
Le pb c est que vous allez plus vite que la musique
j ai commencé par l'export, quand celui ci sera fini, je ferai l'import
pour les tags exotiques comme il est dit, faut aussi attendre, car il faut d abord modifier les tags qui sont deja dans les tables
Un peu de patience, j ai deja dit que j ai de dures journées, plus ce week ou je comptais avancer, ca n a pas été possible
-
En quoi genent les tags proprio ??????
Combien de personnes ouvrent un fichier gedcom pour voir ce qu il y a dedans ????
N avez vous jamais grillé un feu orange ou autre
pourtant il est bien ecrit qu il faut pas le faire sauf dans certain cas
-
Bonsoir Philippe,
Les questions sont surprenantes.
:arrow: Si tout allait bien, il ne serait pas nécessaire de plonger dans les gedcoms pour y trouver les explications aux pertes d'informations, etc...
:arrow: Si tu passes à l'orange au carrefour, tu es le seul à le savoir sauf si le gendarme est là. En informatique, le gendarme est constamment là.
Il est clair que si tu utilises une convention qui n'est pas connue des autres, la communication est impossible et ce n'est pas parce que d'autres le font également qu'il faut rester dans l'illégalité et perpétuer des erreurs.
-
Un nouvel exe à la meme place
-
Combien de personnes ouvrent un fichier gedcom pour voir ce qu il y a dedans ????
Moi
Quand visuged m'a informé d'une inversion de sexe dans un mariage, j'ai du aller dedans pour constater que pour le même couple, j'avais deux mariages, un avec les sexes corrects, l'autre avec les sexes inversés. Aucune erreur signalée dans ancestro. J'ignore encore ce qui a provoqué ce souci, probablement une fausse manipulation de ma part, mais laquelle?
-
En quoi genent les tags proprio ??????
Ils ne gênent pas si c'est pour donner des informations qui n'ont pas été prévues par la norme.
Mais c'est gênant s'il existe un moyen normalisé de présenter l'information. Pourquoi réinventer ce qui existe, si plus est c'est pour le rendre illisible pour les autres logiciels?
-
Bonjour,
Un nouvel exe à la meme place
C'est bien gentil de mettre ainsi un nouvel exe à disposition. Mais il serait plus clair de dire que tel qu'il est il est inexploitable! Avec lui les utilisateurs peuvent faire une exportation gedcom (et voir que tu as modifié des tags exportés), mais sont incapables de faire une importation correcte, ni du nouveau ni de l'ancien gedcom.
Pour ne pas bloquer toutes les autres évolutions, le chantier sur le gedcom devrait être géré comme un projet différent, ce qui n'interdit pas de profiter des autres améliorations.
En attendant, si les utilisateurs veulent tester quelque chose qui fonctionne (en principe...) de bout en bout, ils peuvent télécharger migration_base (http://andre.langlet.free.fr/ancestro/migration_base.exe) ici.
Ils y verront le travail de Bruno pour la remise en ordre des onglets de la fiche identité.
Côté importation gedcom, c'est maintenant la procédure intégrée à la base qui décode les dates. Elle présente l'avantage de savoir décoder les gedcoms dont les dates sont sous forme numérique (21 01 2008). C'est une forme qui n'est pas (plus?) normalisée, mais on en trouve encore beaucoup. Pour celà il a fallu ajouter à la table des mots clés utilisés dans les dates (donc visibles depuis le menu configuration/ mots-clefs...), les mots utilisés dans le gedcom (JAN, FEB... DEC, AFT, AND, BEF...TO). Raison pour laquelle cette mise à jour doit être faite par migration_base.exe qui met également à jour la liste REF_TOKEN_DATE.txt dans le répertoire des tables de référence.
Attention, comme les versions sont inchangées, il faut "rétrograder" la version de la base dans la BDR, et supprimer l'ancien exe avant d'exécuter migration_base sur une installation aux mêmes versions.
A+
André
-
Bonjour,
Un minimum d'infos est appréciable.
Merci DD
Philippe = un 'tit punch en moins Na :mrgreen:
(T'aurais pas des origines auvergnates ? Comme t'es un peu radin...d'infos, j'me disais...)
-
Bonjour,
Quel est donc l'intérêt de mettre en ligne un exe, qui va susciter pas mal d'émoi parmi les utilisateurs, quand ils verront les problèmes.Avoir des modifs pour des modifs n'a pas d'intérêt, un projet de modifs structuré et discuté au préalable, serait plus bénéfique.
Comme l'a dit MPl75, un minimun d'info est appréciable, mais aussi nécessaire, pour juger du contenu de l'exe, et éventuellement le télécharger.
A+
-
Bonjour,
A décharge pour Philippe
il est évident que ces exe sont a destination des testeurs (gens prévenus par nature et à leurs risques et périls Ce qui n'exclut pas un minimum d'infos) avant tout et non à tout utilisateur.
Celui-ci s'en tenant à la version définitive officielle.
-
Bonjour,
Pour comparer les gedcom j'ai lancé Winmerge et comparé 2 gedcom
un créé avec Family Tree Builder
Un avec Ancestro = Standard
Je ne suis pas expert en la matière mais les différences sautent aux yeux.
-
Bonjour,
1) Ce n'est pas si évident que cela, prévenus par nature des risques certes, mais pour le contenu à tester c'est plus un jeu de devinettes.
2) Même pour les testeurs quel intérêt de tester un exe en régression avec les derniers antérieurs.
-
c'est plus un jeu de devinettes.
C'est un peu vrai,
déja que pour savoir où se trouve le bidule, faut suivre.... ;D et être organisé.
Mais DD a tout expliqué...
j'aime bien les nouveaux onglets, vais voir le reste...@++++
Je reviens
Les onglets
Pourquoi Sa vie s'ouvre en fin de page ? et non au début comme les autres onglets ?
-
Tout d'abord rappelons que si nous adorons collectionner des données généalogiques ce n'est pas pour les garder jalousement dans un coffre-fort mais en général pour les partager avec notre famille et nos amis, et aussi pour les échanger avec d'autres collectionneurs compulsifs appelés généalogistes.
De même rappelons que le but de tout logiciel de généalogie n'est pas de faire plaisir au concepteur/programmeur mais de permettre et faciliter la saisie/organisation/visualisation/présentation/standardisation de données généalogiques par/pour l'utilisateur.
Comme aucun outil (aussi génial soit-il) ne peut répondre à tous ses besoins, un généalogiste sera probablement ammené à utiliser plusieurs programmes et utilitaires. Il devra donc inmanquablement transferer ces données d'un programme dans un autre.
Donc tout généalogiste normalement constitué veillera tout particulièrement à la capacité d'échange des logiciels qu'il utilise.
Cet échange passe obligatoirement par la seule "norme" éxistante : le fichier GEDCOM version 5.5
Il testera donc intensivement chaque outil qu'il utilise et verifiera que celui-ci exporte vers le gedcom la totalité des informations qui y sont saisies et qu'il importe au minimum la totalité de ce qu'il a exporté.
Pourquoi éviter les TAGs propriétaires dans un GEDCOM ?
Un TAG propriétaire est totalement spécifique, il est définit par le concepteur du programme qui l'utilise et n'a de sens que pour ce programme.
Les données contenues dans ce TAG seront donc totalement inutilisables par les autres programmes et seront donc perdues lors d'un échange. Un généalogiste "normal" évitera donc d'utiliser les fonctions utilisant ses TAGs.
Si le but d'un fichier GEDCOM est de permettre et faciliter l'échange de données, il paraît donc évident que ces TAGs propriétaires ne servent à rien si leur contenu est perdu lors de l'échange. Dans certain cas ils peuvent même empecher l'échange en "plantant" le programme recepteur (c'était le cas d'Ancestrologie avec son TAG de plus de 15 caractères).
Il parait donc logique d'éviter leur emploi et de privilegier soit l'usage d'une synthaxe GEDCOM valide soit de traiter la singularité à l'intérieur du programme.
Par exemple il semble tout à fait inutile d'exporter l'ordre des événements.
Cet ordre devrait être "prè-organisé" de manière logique (suivant leur déroulement naturel au cours de la vie) à l'intérieur d'Ancestrologie.
Cette "pré-organisation" pouvant être modifiée par clic droit, il suffit d'exporter/importer les événement en respectant leur ordre (à l'import l'ordre du GEDCOM)
Pour les GEDCOM provenant d'autres programmes il serait possible de les trier selon la "pré-organisation" (Celle-ci devant être suffisante dans 95% des cas puisque nous n'utilisons en général que peu d'événements NBDS)
Après bien des péripéties l'événement "Divers" (EVEN) est bien devenu un événement "ouvert" permettant la saisie de tout événement non standard.
Alors pourquoi continuer à utiliser COMU, XHENN, XHOUP, XSPO, XLOI, XMU1, XMU2 et XMU3 (et le changement X_MU1, X_MU2 ... dans la 773 prouve, une fois de plus, que soit le programmeur ne fait pas l'effort de lire, soit il ne sait pas lire, soit il n'en a rien à foutre, soit c'est un âne !)
LIEU
Ce champ est un phantasme du programmeur car il ne sert strictement à rien puisqu'il fait double emploi avec le Subdivision.
Il faut donc transférer le contenu de ce champ dans Subdivision (si celui-ci n'est pas vide mettre le contenu dans la note de l'événement) et
SUPPRIMER DEFINITIVEMENT LIEU. (prévoir la même chose à l'import pour garder la compatibilité avec les "vieux" GEDCOM)
Dans les fenêtres des événements le label "Subdivision" (ou Subdiv. pour les unions) pourrait être remplacé par "Lieu-dit"
Filiation (FILA)
La filiation c'est le lien unissant un enfant à son père et/ou à sa mère.
Ce lien est donc bien caractérisé par la "NAISSANCE" de l'individu et la liste déroulante devrait se situer à la place du "Description" de l'événement naissance (possible puisque fait pour profession).
Et donc s'importer/exporter d'une manière tout à fait standard dans le TYPE de BIRT.
TYPE D'UNION (TYPU)
Même son libellé est clair !
Cette boîte déroulante devrait être à la place du champ description de l'événement union (MARR)
Toute création d'une union en plus de l'entrée dans la table union devrait provoquer OBLIGATOIREMENT la création SIMULTANÉE d'un événement union (MARR) avec le TYPE (Descript.) positionné sur (Inconnu).
L'import/export serait donc sans problème, toute union ayant un couple MARR/TYPE caractérisant le "type d'union".
INSEE
Le GEDCOM ne peut contenir qu'un seul code dans PLAC.
Il faudrait donc demander à l'utilisateur quel code il souhaite exporter/importer : Postal ou INSEE.
On pourrait même placer ce choix dans le FORM du HEADER ce qui donnerait
2 FORM Ville , Code Postal , Département , Région , Pays, Subdivision
ou
2 FORM Ville , Code Insee , Département , Région , Pays, Subdivision
Il ne semble pas difficile de retrouver à l'import le deuxième code à partir du couple : Ville + premier Code
Je dis tout cela depuis 2003 soit bientôt 5 ans et j'en ai ras le bol de répeter toujours les même choses !
Je pense avoir tout dit donc je ne m'exprimerai plus sur ce point.
-
Moralité
Il n'y a de pire sourd, que celui qui, en plus ne veut pas lire ! :smile:
A+
-
INSEE
Le GEDCOM ne peut contenir qu'un seul code dans PLAC.
Il faudrait donc demander à l'utilisateur quel code il souhaite exporter/importer : Postal ou INSEE.
On pourrait même placer ce choix dans le FORM du HEADER ce qui donnerait
2 FORM Ville , Code Postal , Département , Région , Pays, Subdivision
ou
2 FORM Ville , Code Insee , Département , Région , Pays, Subdivision
Il ne semble pas difficile de retrouver à l'import le deuxième code à partir du couple : Ville + premier Code
Bien dit en ce qui concerne les codes j'ai déja enfoncé plsieurs fois le clou sur ce probléme récurant sans solution il me semble.
-
Et tu n'es pas le seul. Voir entre autres ici : http://www.ancestrologie.org/forum/index.php?topic=8609.msg56058#msg56058
-
De toute façon, les mormons ont abandonné le Gedcom pour le XML
Le gedcom est mort vive le xml
-
Le gedcom est mort vive le xml
Qui génère du xml aujourd'hui? Qui sait le relire?
Qui a essayé de mettre en place le projet de version 6 dont on n'entend plus parler depuis des années?
Et ça ne changera rien si chacun y va de son interprétation et ses extensions personnelles.
-
Bonjour,
De toute façon, les mormons ont abandonné le Gedcom pour le XML
Le gedcom est mort vive le xml
Non, les mormons estiment que pour leur objectif de baptiser tous les hommes ayant existé avant Le Dernier Jour, la norme telle qu'elle est en v5.5 leur suffit, et que l'argent dépensé pour moderniser cette norme ne leur servirait à rien. Les versions 5.5.1 et XML en sont restées à l'état de projet.
De toute façon, la différence est dans la forme. Même dans un language à balises, au lieu des niveaux du gedcom, il faut bien des étiquettes pour que tout le monde puisse appeler un chat un chat. (Je ne sais si l'exemple est bon, faudrait être bigleux pour confondre un chat avec une vache :roll:).
A+
André
-
Bonjour,
Philippe, en tant que Concepteur, rien ne t'empêche de développer un autre projet en XML, pour un aspect commercial de le faire savoir, pour battre sur le fil les concurrents d'Ancestrologie que sont here... et généat...De toute façon, balise ou niveau encore faudra t-il que les étiquettes soient communes aux différents logiciels.
Pour nous utilisateurs d'Ancestro quel est l'intêret, puisque l'on ne pourra échanger avec personne.
-
Maintenant qu'on a bien rigolé, le Concepteur peut-il nous faire savoir si c'est si compliqué que ça de modifier ces tags?
-
le Concepteur peut-il nous faire savoir si c'est si compliqué que ça de modifier ces tags
Compliqué : pas tant que ca
c est en cours d'etude et de réalisation
donc un peu de temps
-
Bonjour Philippe,
Hier matin j'ai chargé le nouvel outil de migration que tu avais mis à disposition à l'adresse habituelle pour les versions bêta.
J'ai essayé cette version en procédant à un Export selon l'usage Ancestro et un autre suivant le principe Standard. J'ai fait un Import sans grande conviction puisque ce secteur n'a pas encore été révisé.
Avant de faire cet Import, mon attention a été attiré par la taille du fichier Export *.ged. Pour le coup, j'ai ouvert le fichier et j'ai constaté qu'il ne contenait plus que 111 lignes alors le même Export faisait d'habitude près de 1350 lignes.
Les débuts de modifications entreprises ne sont pas convaincantes et il est dangereux de mettre ce type de bêta entre toutes les mains. Je pense que tu as retiré à juste titre cette version du téléchargement.
Les gourous du gedcom se sont déjà exprimés. Vu de chez moi, les maîtres mots doivent être:
:arrow: Tendre vers et utiliser au mieux le Standard Gedcom 5.5 qui n'est pas encore mort,
mais
:arrow: Préserver dans tous les cas les données des utilisateurs saisies ou disposées dans Ancestrologie
et
:arrow: Permettre l'échange d'informations avec les autres logiciels aussi bien à l'Export qu'à l'Import.
et aussi
:arrow: Etre tolérant pour récupérer au mieux les gedcoms des autres logiciels même si ces derniers ne sont pas conformes au Standard Gedcom 5.5
-
Toujours pour rigoler
c est en cours d'etude et de réalisation
En fait, c'est l'étude qui est longue :grin: :grin: :grin:
Rajouté: je suis entièrement d'accord avec les 4 points cités au dessus, qui de plus relèvent de la plus élémentaire logique.
A+
-
Encore bonjour Philippe,
Mon opinion est que la remise en ordre du traitement du gedcom sera une opération longue et compliquée mais le mouvement semble être lancé. C'est une bonne nouvelle.
En raison de la lourdeur et de la complexité de cette tâche, il me semblerait indispensable de traiter cette affaire de façon particulière en dehors des mises à jour destinées à corriger des anomalies. Tu devrais pouvoir créer un projet bis dans le but d'éviter de lancer dans la nature des versions susceptibles d'occasionner des soucis chez les utilisateurs.
-
Tu devrais pouvoir créer un projet bis
Sur, et de toutes façon, je ne pourrais pas mener de front les autres modifs, donc y aura que le gedcom pour le moment
d'abord l'export (c est le plus simple), ce qui veut dire que pendant ce temps la l'import ne marchera pllus
puis quand export ok : l import
Je ne mettrai pas les betas publiques, seuls quelques personnes y auront acces, ce afin de limiter les plantages
-
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é
-
Apparemment, tu nous laisse sans voix, mais avant d'aller plus loin dans l'analyse, je suis d'accord pour que TYPU disparaisse!!
A+
-
tu nous laisse sans voix,
Pas besoin, je ne me présente pas aux prochaines élections :mrgreen:
André
-
on s'en sort bien, ça te laissera plus de temps pour le 5.5 :grin: :grin: :grin:
A+
-
felicitations à André pour cette analyse.
-
Bonjour,
Ce qui serait bien , c'est que la photo repérée dans Ancestrologie comme photo d'identité soit exportée dans le fichier gedcom de manière à ce qu'elle soit prise aussi dans les autres logiciels comme la photo principale. Et s'il n'y a pas de photo d'identité déclarée, que la déclaration de la photo principale reste vide ou renvoie à une image vide générique qui pourrait être d'office dans Ancestrologie.
En effet quand on importe le gedcom réalisé avec Ancestrologie, dans un autre logiciel, ce qui est superbe, c'est de retrouver les liens vers les photos et documents, mais ce qui est contrariant, c'est de retrouver n'importe quelle photo ou scan de document en lieu et place de la photo d'identité sur la fiche ou les arbres créés.
Je ne sais pas si c'est possible, mais cela faciliterait les transferts dans certains petits logiciels spécialisés gratuits.
Cordialement
Patrick
-
Bonjour,
Pour la photo d'identité çà me semble difficile car je ne connais pas de norme qui permette d'identifier la photo désignée comme "identité". Chaque logiciel a l'air d'utiliser sa propre convention.
A moins que vous en connaissiez une reconnue par la majorité?
A+
André
-
Bonjour,
il semble que ce soit toujours le même image qui soit prise en considération dans différents logiciels mais je ne sais pas comment ils la reconnaissent.
Je n'y connais pas grand chose mais en regardant le gedcom et les images reprises par les logiciels, il semblerait que ce soit la première indiquée par le tag :
1 OBJE
2 FILE "nom de l'image"
Peut-être est-il possible lors de l'écriture du gedcom de placer en premiàre image l'image repérée identité ou une image blanche située dans un répertoire d'ancestrologie en cas d'absence d'identité ?
C'est ce que je fais pour remplacer les photos d'identité quand il n'y en a pas dans d'autres logiciels. Mais c'est un travail de longue haleine car à chaque changement dans ma base ancestrologie et donc nouvel export gedcom et réimport dans un autre logiciel, il faut remodifier les images dans la plupart des fiches individuelles.
-
Bonjour
J'avais demandé au créateur d'OXY-GEN http://www.oxy-gen-soft.net/ (http://www.oxy-gen-soft.net/) de prendre en compte non pas la premiere image mais la photo l'identité la différence est le TAG XIDEN qui est à 1
1 OBJE
2 FILE D:\_GENEA_VRAC\Ancestrologie\Images\SIMONE_G.JPG
2 XTYPE P
2 XIDEN 1
2 XMODE 0
A priori VISUGED lui aussi prend la bonne image (sauf si on décide d'avoir le nouveau GEDCOM standard (v773))
Bonne journée
-
Bonjour,
J'ai oublié une louche à verser dans le seau d'hier.
Autre tag spécifique à Ancestrologie: la clé fixe qui permet la liaison avec Qui sont-ils.
Tout d'abord un rappel: ce code est à l'origine attribué par Ancestrologie avec pour valeur la cle_fiche (ou NIP, n° attribué séquentiellement à chaque individu lors de sa création dans la base, permettant son identification en interne).
La conséquence de ce mode d'attribution, c'est que s'il est unique dans une base, on attribue les mêmes numéros dans des bases différentes.
Conséquence de cette conséquence, lors de l'importation d'un gedcom provenant d'une base dans une autre base, on a toutes les chances de créer des numéros en double. Pour palier à celà un trigger de la base change se code et en attribue un encore libre.
En conclusion, on peut se poser la question de l'intérêt de transmettre par gedcom un code qui a de bonnes chances d'être modifié, perdant de ce fait son rôle de lien avec DST.
Avant de penser à l'exporter, il faut d'abord mettre en place une méthode permettant de lui attribuer une valeur UNIQUE, au moins vu depuis le logiciel QST installé sur le poste. Et pour celà je pense que ce code devrait être attribué QST.
Quand ce problème sera résolu, il pourra être envisagé d'exporter ce code en exploitant le tag REFN prévu par la norme
0 @<XREF:INDI>@ INDI
1 REFN <<valeur clé fixe>>
2 TYPE QST
En conclusion que reste-t-il comme tags spécifiques:
_ORDR, _ACTE et _IDEN.
A+
André
-
En réponse à Bob,
J'ai bien précisé hier que l'export "standard" avait été fait selon la version 5.5.1 de la norme, et que je n'avais depuis vu qu'un seul logiciel qui "comprenait" ce projet de norme. Raison pour laquelle je pense être obligé de revenir à la méthode plus répétitive de la version 5.5, on répète toutes les propriétés de l'objet à chaque exportation, alors que la version 5.5.1 autorisait une exportation unique, pointée ensuite par chaque "utilisateur". Je n'en reviens pas cependant à la méthode Ancestrologie où les médias n'étaient exportés qu'avec l'individu, en perdant le lien à sa déclaration comme acte lié à l'événement ou comme lié à des sources.
Rare tag spécifique restant, XIDEN doit être transformé en _IDEN pour bien être identifié comme tag spécifique à l'importation.
Les autres tags de l'objet définissant son format devraient être supprimés en utilisant le tag standard FORM dont la valeur est l'extension du nom du fichier.
XMODE était la valeur du MULTI_IMAGE_RTF
valeur 0 pour les images (qu'Ancestrologie stocke en interne, réduites à 1024 points sur la plus grande dimention, au format jpg), donc pour les FORM jpg, bmp, etc...
valeur 2 pour les fichiers sons (FORM= wav, mp3 etc...)
valeur 3 pour les fichiers vidéo (FORM= avi, mpeg, etc...)
valeur 1 pour tous les autres.
Quand à XTYPE, si quelqu'un peut m'expliquer à quoi il sert?
A+
André
-
C'est en effet l'image marquée
2 XIDEN 1
qui est l'image identité.
N'est-il donc pas possible de la faire s'inscrire en premier dans la liste d'images du gedcom ou la référence à une image fictive en cas d'absence de la ligne en question. (pas d'identité)
Comme cela la majorité des logiciels prendraient en charge la bonne image ou une image blanche pour la remplacer dans les arbres ou sur les fiches.
-
C'est souvent l'inverse qui est fait par les logiciels qui n'attendent qu'un enregistrement. La valeur suivante écrasant la précédente, c'est la dernière valeur qui est retenue. A l'intérieur d'un groupe de médias exportés, _IDEN en début ou en fin est simple à obtenir, il suffit de classer les médias dans l'ordre de MP_IDENTITE ou dans son ordre inverse avant d'exporter.
Mais celà ne garantira pas l'importation comme identité par un autre logiciel, car Ancestrologie permet de déclarer comme identité n'importe quelle image qui est rattachée à l'individu, que ce soit directement à l'individu, par l'intermédiaire d'un événement individuel ou familial ou par les sources. L'exportation de l'ensemble des images se faisant en plusieurs groupes pour un même individu, il n'est pas sûr que l'image identité soit la première ou la dernière de toutes les images liées à l'individu.
Le mieux est peut-être de mettre la photo d'identité en tête de groupe. Comme c'est souvent une photo directement liée à l'individu et que ce groupe est exporté en premier, la photo d'identité a de bonnes chances d'être la première exportée pour l'individu. Mais il n'y a là rien d'absolu.
Quand à ajouter une page blanche,.. je pense que ce n'est pas à Ancestrologie de créer des anomalies pour satisfaire d'autres logiciels.
A+
André
-
Ce n'est pas une page blanche, mais juste une image blanche qui se met à la place de la photo d'identité évitant ainsi de se retrouver avec une représentation mini du premier acte venu dans un arbre ou une fiche.
Mais si Ancestrologie pouvait classer en interne les images identité en premier, ce serait peut-être déjà efficace.
N'oublions pas que l'argement en faveur d'Ancestrologie c'est que l'on a un logiciel au moins comparable à ses concurrents commerciaux déjà cités.
Le fait de pouvoir utiliser le gedcom dans un logiciel gratuit de création de site comme oxy*** est un plus car je n'en connais pas de meilleur pour créer des pages internet complètes.
Cordialement
Patrick