Bonjour Jean-Jacques,
Désolé pour le temps de réponse mais sur-occupé cette semaine...
Comme vous, je constatais une extrême lenteur de GT2025.
Cette lenteur initiale s'est très nettement améliorée bien que des problèmes persistes (à propos de mon champ SOURCE...toujours sans réponse).
Je pensais avoir répondu en ayant indiqué le contournement de mettre un autre tag que SOUR/_SOUR dans mon 1er post (puis après import remettre source). Depuis j'ai poursuivi mon analyse.
A la réflexion, je pense que Geneatique n'est pas conçu pour traiter correctement des rubriques multi texte. Pour Geneatique une rubrique texte est forcement à un élément exporté en 1 TAG <info>; Ce qui se comprend car si il y a des tags niveau 2 je ne vois pas comment il pourrait faire pour le distinction avec un événement où il n'y aurait pas de date/lieu/note saisi. Néanmoins il est possible de créer plusieurs éléments dans une telle structure "multi texte" comme tu l'as fais, ce qui provoque les dysfonctionnement constatés.
L'import a de plus évolué pour mieux traiter l'import HEREDIS des sources (palliatif). Cela pour les transformer en événement en décodant les tags gedcom de la syntaxe 5.5 (ce qui existait déja avant mais a été complété). Geneatique n'étant toujours pas compatible des sources structurées (soit au niveau individu soit famille soit événement).
J'ai signalé cette problématique de champ texte multi-champ texte dans le forum beta testeur comme anomalie (mais ne pas s'attendre à une correction rapide). Dans les versions actuelles il faut donc :
- proscrire le multi champ texte dans la structure d'une généalogie
- dédier le type de rubrique "texte"
à un seul champ info (comme indiqué dans l'aide; cf Les différents types de rubrique ) sans saisir de tag de niveau 2.
- si besoin privilégier les évènements avec info. pour les sources générales (ce qui permet de saisir une note en plus)
D1 - dans la réalisation de l'export GEDCOM, quelle différence entre SOURCE et NOTE intégrées aux personnes ou dans des sections indépendantes ?
La 1er est l'ancienne manière issue des 1eres spécifications gedcom (la structure est au niveau 1). Elle ne permet le codage que d'une forme simple de source (descriptif +transcription + médias + note + qualité) et pas le partage (note ou source) car la structure est au niveau de chaque individu ou famille.
-> Il y a effectivement un problème particulier pour importer une telle structure dans G2025 (autre anomalie). Ce qui provoque la perte de champs additionnels. (pas de solution autre que de changer le tag)
La 2nd manière est la forme la plus récente en 5.5/5.5.1 qui permet à la fois le partage de notes ou de sources entre plusieurs individus/familles (dans cette forme les structures sont déclarées comme structure de niveau 0 et les individus / familles les "pointent" dessus par leur numéro). Généralement les notes et sources se trouvent déclarées en fin de fichier dans ce cas. Sachant qu'en gedom 7.0 le tag NOTE a été remplacé par SNOTE (Shared Note) et la source "simple" (1er manière) a été supprimée.
D2 - dans le mode opératoire des TAGs à vérifier, pour RELATION, chez moi c'est un TAG normalisé niveau 1 : "RELATION" et non propriétaire "_REL....normal ?
RELATION n'est pas un tag normalisé par la spécification gedcom; c'est simplement le nom de la rubrique mis en tag lorsque la rubrique "evenement relation" à été créée pour pallier à l'absence de traitement par Geneatique des relations entre individus (tag ASSO de la spécification au niveau 1). Geneatique, en import, créer des évènements relation à partir des tags ASSO.
Dans les dernières versions (je ne me souviens plus laquelle) cette rubrique propriétaire à pris le tag _REL (tag propriétaire) ce qui est normal.
--> Tag à changer dans la structure
Mais on s'éloigne du sujet initial du post, qui est la lenteur. L'export/import gedcom permettant peut être d'atténuer le problème. ==> Pour la prochaine fois, il serait mieux de créer un post spécifique.
Cordialement
Thierry
