GedcomforGeneanet

[thetienne]

C'est ce que je m’étais dit au départ.
mais cela ne concerne que les lieux concernant les événements pas les personnes.
A priori toutes les informations se trouvent dans le tag place dans ce cas précis donc pourquoi se préoccuper de cette structure supplémentaire qui est optionnelle.

Bonsoir Eric,
A la réflexion je suis d'accord aussi. Je pensais cela d'un l'éventualité où Gramps corrige le comportement dans de futures versions. Mais comme Gramps met les rues dans le tag PLAC aussi (alors que normalement personne ne fait cela) c'est aussi bien. Normalement on ne doit mettre derrière PLAC que les niveaux "juridictionnels" des lieux.

Cordialement
Thierry

[patricelegoux]

Bonjour Thierry,

Mais comme Gramps met les rues dans le tag PLAC aussi (alors que normalement personne ne fait cela) c'est aussi bien.

C'est pourtant parfois très utile cette hiérarchie fine. Si personne (?) ne le fait, je les engage à essayer si leur logiciel le permet et permet d'en faire quelque chose telles que des recherches sur cette base. Ça amène parfois des découvertes sympathiques.

Normalement on ne doit mettre derrière PLAC que les niveaux "juridictionnels" des lieux.

Qui dit ça ? La norme gedcom ?

[blefebvre]

Normalement on ne doit mettre derrière PLAC que les niveaux "juridictionnels" des lieux.

Qui dit ça ? La norme gedcom ?

Oui
PLACE_HIERARCHY:= {Size=1:120}
This shows the jurisdictional entities that are named in a sequence from the lowest to the highest
jurisdiction. The jurisdictions are separated by commas, and any jurisdiction's name that is missing is
still accounted for by a comma. When a PLAC.FORM structure is included in the HEADER of a
GEDCOM transmission, it implies that all place names follow this jurisdictional format and each
jurisdiction is accounted for by a comma, whether the name is known or not. When the PLAC.FORM
is subordinate to an event, it temporarily overrides the implications made by the PLAC.FORM
structure stated in the HEADER. This usage is not common and, therefore, not encouraged. It should
only be used when a system has over-structured its place-names.

[patricelegoux]

Merci.

When the PLAC.FORM
is subordinate to an event, it temporarily overrides the implications made by the PLAC.FORM
structure stated in the HEADER. This usage is not common and, therefore, not encouraged. It should
only be used when a system has over-structured its place-names.

Bon c'est pas encouragé mais faisable, "autorisé".

Encore une peuve que cette norme devrait évoluer, ici pour encourager le support de la transmission d'un maximum d'informations et non d'un minimum.

[glopglop]

Bonjour

pour moi c'est exactement le probleme du gedcom
on ne devrait pas avoir ce genre d’ambiguïté.
tout devrait être décrit précisément et exhaustivement.

franchement vu la tournure des phrases la "meilleure solution" quand j'exporte c'est de ne pas
mettre de tag PLAC dans le header
comme ca apres je fais ce que je veux et je reste dans la norme.

Bon courage au logiciel qui doit essayer d'importer après.

Question subsidiaire:
comment faire pour distinguer deux lieux qui se trouve a deux numeros differents dans la meme rue?
quel est le "jurisdiction's name" de ces deux lieux?

[thetienne]

Mais comme Gramps met les rues dans le tag PLAC aussi (alors que normalement personne ne fait cela) c'est aussi bien.

C'est pourtant parfois très utile cette hiérarchie fine. Si personne (?) ne le fait, je les engage à essayer si leur logiciel le permet et permet d'en faire quelque chose telles que des recherches sur cette base. Ça amène parfois des découvertes sympathiques.

Bonjour Patrice et à tous,

Qu'il n'y ait pas d'ambiguïté, personnellement je trouve très bien la manière "poupées russes" de saisir les lieux chez Gramps. Néanmoins la transcription en gedcom doit s'arrêter au lieu-dit (niveau le plus bas) pour le tag PLAC. Si il y a une rue cela doit s'exporter seulement dans le champ ADDR :

Code: Selecteer alles

2 PLAC ..., x,y,z  (séparateur niveaux "juridictionnels" = virgule)
2 ADDR numéro et de nom de rue (à minima)
3 CONT etc....

Dans la base Familysearch la saisie, dans le lieu, d'une rue au format normalisé n'est pas possible
Car ce n'est pas la définition gedcom usitée (usage de fait à défaut d'être non ambiguë dans le standard 5.5.1) et cela est normalisé depuis très longtemps par familysearch (et repris en GEDCOM-X de manière similaire). Vous pouvez essayer de voir les lieux possibles dans la base normalisée de familysearch : https://www.familysearch.org/research/places/?searchTypeaheadInputText=

La majorité des logiciels comprennent pour ce qu'elle est la structure ADDRess gedcom. C'est à dire l'adresse postale (ADDR+n lignes CONT) pouvant être optionnellement complétées par des champs POST/CITY/CTRY. Ce n'est pas un lieu (place) au sens gedcom.

L'information est en effet utile mais une adresse (normalement complète) ne s'échange que via le tag ADDR avec les autres logiciels de généalogie et je l'utilise souvent. La plupart des autres logiciels ont des fenêtres dédiées (séparées des lieux) pour la saisie des adresses (postales) et je les utilisent. Je recommande néanmoins de ne mettre qu'une seule ligne en adresse car beaucoup de logiciels de généalogie ne reconnaissent qu'une ligne d'adresse.

Pouvoir saisir une adresse est courant dans tous les logiciels de généalogie. Mettre une adresse dans le tag PLAC revient à l'amalgamer à une subdivision cela ne permet d'échanges gedcom "sereins". La manière de saisir dans les dernières versions de Gramps n'est en soit pas un problème; Le problème c'est la manière d'exporter.

Comme le souligne Eric, cela peut créer des ambiguïtés de syntaxe/compréhension dans certains cas (notamment si on utilise les virgules pour indiquer plusieurs numéros de rue).

Cordialement
Thierry

[studersundgau]

Allons bon !
maintenant ce sont mes descriptions qui disparaissent une fois sur deux.
par exemple :
https://www.geneanet.org/media/public/mariage-1593-28123011
à comparer avec
https://gw.geneanet.org/studersundgau_w?lang=fr&pz=catherine&nz=studer&p=jodocus+senior&n=behra

Je préfère utiliser la description plutôt que la note car elle saute plus facilement aux yeux.

merci de votre patience !

[studersundgau]

cela concerne surtout les événements "naissance " "mariage" et "décès" apparemment.

[glopglop]

Bonsoir

je n'arrive pas a comprendre le probleme
quelle decription disparait?

[studersundgau]

Regardez sur la photo : j'ai marqué "date manquante, acte déchiré", et cela n'apparaît pas sur la fiche

J'ai eu la même chose pour "décédé chez son fils", par exemple....

[glopglop]

oui mais je ne comprends pas le rapport entre votre lien et la photo.

il serait plus clair d'avoir une capture ecran de l'eenement dans gramps et le morceau de gedcom correspondant

[thetienne]

Je préfère utiliser la description plutôt que la note car elle saute plus facilement aux yeux.

Bonjour,
Vous parlez
- d'une note d'évènement qui se traduit en gedcom derrière un tag NOTE
- d'un attribut "description" d'événement qui ne se traduit pas en gedcom
- du typage d'un événement (nommé description dans gramps) qui se traduit par un tag TYPE
- du attribut "description" d'une référence événement qui ne se traduit pas gedcom
de quel champ parlez vous ?
Ce qui s'exporte c'est :

Code: Selecteer alles

1 <tag de l'événement>
2 TYPE La description de l'évènement --> Onglet général, champ description
2 DATE ...
2 PLAC ...
3 NOTE @Nxxxxx@ --> Note sur l'évènement

Normalement le champ description c'est pour catégoriser des variantes d'un même évènement (mariage civil, mariage religieux, résidence principale, résidence secondaire, ...) pas une information (date manquante, acte déchiré, ...). Cela s'affiche comme cela sur Geneanet :

Code: Selecteer alles

date :	nom evt - lieu de l'évènement
        La description (type) de l'évènement (dans la note geneweb)
        Note sur 'l'évènement (dans la note geneweb)

Cordialement
Thierry

[glopglop]

Bonjour Thierry

Merci pour l 'éclaircissement.
quand j'ai dis que je n’étais pas "graphique"
En fait tout vient de la gestion de geneanet dans les import gedcom

pour les événements classique il ne font pas apparaître le type qui vient de la description car cela doit rentre dans des type prédéfinis.
pour les événements "customs" par contre comme il n existe pas de type prédéfinis la description est importante.

Daons comme cela a ete dit pour les evenements classique il faut rentrer les informations dans une note et pas dans la desciption qui elle doit être "normalisée".

Un exemple de ce contournement est le rôle dans les événements.
dans le gedcom le type est forcement witness et on met le role dans une note.
Geneanet remet tout ça en ordre a l'import.

C'est vraiment tout le problème de la norme gedcom. Cela devrait être un format universel d’échange ou l exporteur et l importeur ne devrait pas devoir s'arranger. Or ce n'est pas du tout le cas.

C'est comme si deux habitants de regions de France devait s'arranger au préalable pour pouvoir discuter entre eux en français.

[thetienne]

Bonjour Eric,

En fait tout vient de la gestion de geneanet dans les import gedcom
pour les événements classique il ne font pas apparaître le type qui vient de la description car cela doit rentre dans des type prédéfinis.
pour les événements "customs" par contre comme il n existe pas de type prédéfinis la description est importante.

Oui et non,
Geneanet ne fait qu'essayer de s'adapter au fait que geneweb a une structure de base de données "pauvre" par rapport à d'autres logiciels de généalogie (qui ont plus de champs). En fonction de la compréhension du champ "non geneweb" il adapte ce qu'il fait (mise en note, ignorer le champ, etc... ) vis à vis du logiciel ayant généré le gedcom.

Le traitement de Geneanet commence par tester le champ SOUR du header gedcom (nom du logiciel) en fonction du contenu il effectue + ou - de traitements et met + ou - de choses dans les notes geneweb.
Par exemple si le header est "1 SOUR GeneWeb" il n'y a pas de traitement.

Le traitement que j'expliquais dans mon précédent post est celui pour Gramps "seul" et la majorité des autres logiciels. Néanmoins GeneanetForGeneanet modifie le tag source :

Code: Selecteer alles

0 HEAD
1 SOUR Gramps + GedcomforGeneanet
2 VERS GrampsAIO64-5.1.3-2-2.0.10
2 NAME Gramps + Gedcomforgeneanet

Je viens de vérifier, le traitement Geneanet est différent par rapport à Gramps. Pour GedcomforGeneanet le champ description (tag TYPE) n'est pas affiché dans ce cas. ((je ne sais pourquoi)
Dans la note Geneweb (cas gramps) au lieu de

La description de l'évènement
Nom du lieu à la date de l événement : lieu (place)
note sur l'événement

il y a

Adresse: Adresse+lieu (ADDR)
Nom du lieu à la date de l'événement : lieu (place)
note sur l'événement

Je ne sais pas pourquoi il y a une telle différence de comportement (on constate aussi un comportement différent pour l'adresse en trop dans Gramps) mais il me semblerait qu'il vaudrait mieux que le header généré par Gedcomforgenanet soit :

Code: Selecteer alles

0 HEAD
1 SOUR Gramps
2 VERS GrampsAIO64-5.1.3-GedcomforGeneanet 2-2.0.10
2 NAME Gramps

Cela éviterait que Geneanet ne change la transformation par rapport à Gramps en fonction de ce que les utilisateurs font. Mais il y a peut être une raison

C'est vraiment tout le problème de la norme gedcom. Cela devrait être un format universel d’échange ou l exporteur et l importeur ne devrait pas devoir s'arranger. Or ce n'est pas du tout le cas.
C'est comme si deux habitants de regions de France devait s'arranger au préalable pour pouvoir discuter entre eux en français.

C'est plutôt un problème de "requirements" sur l'import lorsque le nombre de champs est différents. La seule chose que l'on peut reprocher à la norme gedcom c'est qu'elle est très pauvre en "exigences" dans ce cas.
C'est plutôt un problème de discussion entre deux habitants qui ont la même langue mais un des deux à un vocabulaire réduit. La langue n'est pas vraiment en cause. Par contre le "traducteur" (généanet) peut être en cause dans certains cas.

Thierry

[forhanp]

Bonjour,

C'est vraiment tout le problème de la norme gedcom. Cela devrait être un format universel d’échange ou l exporteur et l importeur ne devrait pas devoir s'arranger. Or ce n'est pas du tout le cas.

Objection votre honneur, le souci en revient aux logiciels d'export (il me semble que Thierry a indiqué certains champs qui ne sont pas exportés) et aux logiciels d'imports (le choix de transformer un type d'évènement en autre chose est spécifique à l'import et pas à la structure même du GEDCOM).
Le type est géré au cas par cas sur les logiciels, plutôt que globalement.
Voir ce sujet ou JLM indique clairement qu'il y a une moulinette spécifique pour Ancestris après que je lui ai fait faire cette même moulinette un an plus tôt sur Ancestrologie.
https://www.geneanet.org/forum/viewtopic.php?f=11&t=608188

Je sais que le GEDCOM n'est pas parfait et souffre d'incohérences, d'ambiguïtés, de manques et de redondances coupables, mais il ne faut pas en faire l'alpha et l'oméga de tous les problèmes de conversion.

Vous auriez même pu faire un export Geneweb (le format est ouvert et libre) pour voir à quel point il faut tordre le contenu de Gramps pour le faire rentrer dans le moule attendu.

Cordialement,