Sujet: gestion des adresses

[Facon]

Bonjour,

Pour poursuivre et peut-être venir à une conclusion.

Quelqu'un a dit "il faut s'adapter à la réalité", pour la France, la réalité s'établit de la façon suivante avec les informations contenues dans les tables associées à Ancestrologie.



Le champ "PLACE" dans sa configuration actuelle et indépendamment de l'ordre des éléments de description comporterait 87c + 5 séparateurs soit 92c au total, laissant 28c si le champ "PLACE" était limité à 120c.



A la seule condition de transformer la région Provence-Alpes-Côte d'Azur en PACA, la contrainte chute à 85c + 5 séparateurs soit 90c au total, libérant 30c si le champ "PLACE" reste limité à 120c.



Il serait possible d'abaisser encore cette contrainte en jouant sur deux communes:

CP 66300 Sainte Colombe de la Commanderie Pyrénées-Orientales Languedoc-Rousillon France (82c) et,

CP 66760 Angoustrine-Villeneuve des Esclades Pyrénées-Orientales Languedoc-Rousillon France (85c).



Ceci nous permettrait en combinant PACA et les modifs sur ces deux communes d'amener le nombre de caractères requis à 78c. Si on y ajoute les 5 séparateurs nous arrivons à un total de 83c libérant ainsi 37c pour le descriptif lieu ou subdivision.



Il serait bien entendu possible d'aller plus loin dans la modification des tables mais le soucis est de réduire autant que possible l'ampleur des travaux.



Alors pour moi et sans doute pour la plus grande majorité, je ne vois pas beaucoup de contraintes ni de grands risques de perdre des informations.



Par conséquent, moyennant les modifs ci-dessus vous dimensionnez le champ "PLACE" comme vous le souhaitez et disposez les descriptifs comme vous le voulez.

Je maintiens, pour les anxieux, qu'il serait judicieux d'attirer l'attention de l'utilisateur sur le dépassement des 120c même si la place disponible est plus importante. Ceci lui permettrait d'inscrire son lieu ou subdivision sous une forme plus abrégée.



Quant aux autres possiblités de ramener le CP au numéro de département, il y a lieu d'envisager tous les cas de figures du type I_xxx, ... Le gain me semble plus limité. Par contre ce que j'ignore c'est si cette dernière disposition a un impact sur l'utilisation de la fenêtre "Index des lieux".

Enfin, je ne vois pas bien la suppression de la région, aux USA la région doit correspondre à l'Etat et le pays aux USA.

[Ransac]

j'ai enfin pris le temps de lire cette discussion.

Il y a des choses interessantes, peut-être bien aussi des choses qui doivent être modifié dans le logiciel dans l'export et l'import.



Voici ma position (qui n'engage que moi).

Tout d'abord concernant le problème "lieu" et "subdivision", c'est subdivision qui à sa place dans "PLAC". Comme le fait remarquer André dans un de ses messages, "Lieu" est lié à une table de champs nommé "ADRESSE", j'y place donc le nom de la maison ou le nom de la rue. Dans Subdivision, j'y mets le lieu-dit ou le quartier.



Concernant l'ordre dans lequel cela doit être placé dans le gedcom, il serait en effet mieux que "subdivision" soit au début.

Cependant, il ne faut pas oublier que lors de l'export, une ligne "FORM" est créée dans "PLAC". Cette ligne contient l'ordre dans lequel seront trouvé les différentes informations concernant le lieu. Je suppose que les autres logiciels utilisent également cette ligne pour trouver les correspondances.

Son format actuel est le suivant :

1   PLAC

2   FORM   Ville , Code Lieu , Département , Région , Pays, Subdivision

Cette ligne est limitée à 120 caractères



Concernant les limites en caractères des champs :

Première chose, nous utilisons dans ancestrologie les mêmes tables de references pour les adresses et pour les places. Elles doivent donc être compatibles avec les deux.

PLAC est limité à 120 caractères. Il n'y a pas de limite dans le nombre d'informations, mais la plupart des logiciels en gèrent 6.

Dans la structure de l'adresse "ADDR", il y a des lignes différentes pour chacune des informations, les lignes qui nous interessent sont limitées à 60 caractères.



Donc, inutile de se brider dans les tables de réferences et acceptons 60 caractères pour les villes, pays, subdivision (ce n'est pas le cas actuellement, c'est moins!)



Pour la construction de PLAC, une étude des tables montrent que nous n'arrivont pas à la limite des 120 caractères en l'absence du champ subdivision.

Si par malheur, cela viendrait à le dépasser avec subdivision, cela ne devrait concerner que peu de cas qui, si le logiciel d'importation se limite à 120 caractères, pourait être modifier dans le GEDCOM.



Possibilités pour réduire la taille de la ligne :

- remplacer département par son code

- remplacer région par son code, mais là on les connait moins !





En bref, laissons les champs et les normes telles quelles sont actuellement car même si elles ne sont pas absolument rigoureuses comparées au GEDCOM standard, elles ne posent pas de problème actuellement.

Si PCM décidait de se lancer dans des modifications, se pourrait être de mettre par défaut subdivision en premier et peut-être de donner le choix

à l'utilisateur des champs et de leur position lors de l'export (voire de donner la possibilité d'ajouter le 7e champ "lieu" dans PLAC).



Cela ne dispense pas cependant de revenir à la première suggestion qui était de donner la possibilité de choisir dans une table "domicile" les domiciles des individus, ce qui éviterait de tout retaper à chaque fois et permettrait de savoir qui sont les individus ayant habités à une adresse donnée.

[DDdeBerdeux]

Quant aux autres possiblités de ramener le CP au numéro de département, il y a lieu d'envisager tous les cas de figures du type I_xxx, ...

Bonjour,

Ce n'est pas ce que j'ai proposé. Le CP existe comme information séparée, et je ne propose que de le mettre en queue de peloton pour qu'il puisse être éventuellement récupéré par des logiciels qui l'utilisent (éventuellement, pareil pour le code INSEE).

Le code département français existe déjà dans la table de référence REF_DEPARTEMENT sous la forme de 2 caractères. Il faudrait peut-être ajouter les noms abrégés des régions à REF_REGION. Mais celà ne sera utile que si la limite de 120c pose effectivement un problème, et prévoir le choix nom complet/nom abrégé de ces champs, à l'affichage comme à l'exportation.

Mais la première condition...

A+

André

[Ransac]

Quant aux autres possiblités de ramener le CP au numéro de département, il y a lieu d'envisager tous les cas de figures du type I_xxx, ...

Les CP de type I_xxxxx sont des villes qui n'existent plus car elles ont fusionnées ou elles ont été ratachées à une autre, ou elles ont disparues...



Le I_xxxxx signifie que la commune de rattachement est celle ayant le numéro INSEE xxxxx



Doit-on changer cette dénomination ?

Doit-on demander le changement des tables de références de façon à pouvoir retrouver cette information tout en laisser le CP vide ?



Toujours est-il que cette dénomination cause un pronlème dans la DLL "arbres" car l'extraction du code du département se fait sur les 2 premiers caractères du CP !

Ceci dit, ce n'est pas correct d'afficher les 2 premiers caractères du CP pour le département, car il y a de nombreuses villes limitrophes aux départements, qui pour des raisons de commodités ont un CP codant sur l'autre département !

Il serait grandement préférable de prendre les infos directement dans la table de référence des départements, mais j'ai cru comprendre que ce n'était pas facilement faisable.

[Facon]

Bonjour,

André, je ne faisais pas allusion à ta proposition mais à celle d'Aquablue lorsqu'il disait je préfère voir ..... plutôt que.....

Dans sa suggestion, il indique le numéro du département (entre parenthèses) à la suite du nom de la commune et je me posais la question de savoir comment cette indication arrivait là.

Tu as entièrement raison sur l'existence des n° des départements français.

Ma crainte allait dans le sens de ce qui a été soulevé par Ransac, à savoir l'extraction des deux premiers chiffres du CP.

La question subsidiaire est de savoir ensuite comment est créé dans son exemple La Gacilly (56): est-ce une modif de la table des villes ou le collage (la concaténation) de deux infos.

Personnellement je trouve que le gain est mince entre La Gacilly (56) et La Gacilly,56200 :15c au lieu de 16c



Une autre question que je me pose, c'est celle de l'utilisation des données à l'import. Est-il préférable d'avoir le CP, le code INSEE, les deux? Si les données de base sont tronquées, qu'est ce qui est le plus utile pour retrouver un affichage complet et clair?

Je n'ai pas l'expérience mais j'imagine que les autres softs ont aussi leurs tables et CP et INSEE devraient être le même pour tout le monde.

Question stupide, pour la France lorsque nous avons donné CP mais surtout INSEE tout est dit hormis la subdivision. Si ces infos sont présentes, faut-il communiquer la commune?

Sans aller aussi loin, puisque INSEE (en France) donne tout, ne faut-il pas tronquer volontairement le nom de la commune à 25 ou 30c quitte à ajouter les 6+1 d'INSEE?

[Ransac]

Question stupide, pour la France lorsque nous avons donné CP mais surtout INSEE tout est dit hormis la subdivision. Si ces infos sont présentes, faut-il communiquer la commune?

Sans aller aussi loin, puisque INSEE (en France) donne tout, ne faut-il pas tronquer volontairement le nom de la commune à 25 ou 30c quitte à ajouter les 6+1 d'INSEE?

en théorie, tu as raison (pour INSEE, pas le CP pour lequel plusieurs communes partagent le même CP!)



Le problème est que si je te dit 33013 tu seras bien incapble de me donner le nom de la ville et ce sera le cas de la majorité des programmes de généalogie et en particulier ceux développé par les anglo-saxons.

En effet, très peu de programme de généalogie ont inclus une table complète permettant de faire la correspondance entre le numéro INSEE et la commune.



De plus certaines communes ont changé de nom, tu as pu ajouter des lieux  dans ta liste, je serai très surpris que tu y ais donné le numéro INSEE des lieux ajoutés !

[Lya]

Pour ma part, je trouve que vous vous cassez bien la tête à partir du moment où personne n'a rapporté avoir des problèmes avec cette limite à 120c...  



Est-il bien utile d'avoir le code INSEE en plus du CP ? Non seulement c'est très franco-français, mais ça fait un peu doublon. Il me semblait qu'il y avait une option dans Ancestro pour inverser CP et code INSEE ?

Le CP existe comme information séparée, et je ne propose que de le mettre en queue de peloton pour qu'il puisse être éventuellement récupéré par des logiciels qui l'utilisent (éventuellement, pareil pour le code INSEE).

Attention, tous les logiciels ne disposent pas de "parseurs" à l'import ! C'est le cas de Geneweb notamment. Je viens de vérifier, et effectivement, le champ Subdivision à la fin pose problème dans l'affichage des patronymes par lieux, puisque un lieu-dit se retrouve au même rang qu'un pays. Mettre les CP à la fin ne feraient qu'embrouiller les choses pour ce genre de logiciels puisqu'ils créeraient autant de "pays" que de CP.  

[DDdeBerdeux]

Faudra dire à Aquablue de le classer dans les mauvais.

Bonne nuit

André

[AquaBlue]

Bin non puisque j'ai écrit MouliGed rien que pour lui        

[Facon]

Bonjour,



Est-ce que quelqu'un est en mesure de nous dire où nous en sommes dans la mise en ordre de "PLACE"?

[Ransac]

je ne pense pas que ce soit au programme immédiat étant donné que la gêne est relativement faible !  

[DDdeBerdeux]

Bonjour,

Pour déplacer un gros tas de terre, on prend une pelle.

Quand on a un gros problème qui nous paraît insurmontable, on le décompose en petits que l'on sait résoudre.

Si on trouve que déplacer la pelle ne vaut pas la peine, on ne déplacera pas le tas de terre... :?

A+

André

[Facon]

Bonjour,

Je croyais encore naïvement que la légion était capable de déplacer les montagnes. Nous voilà arrivés à des petits tas de sable et ça ne marche plus.

Merci tout de même à Philippe d'avoir eu le courage de nous envoyer son lieutenant pour  nous communiquer sa réponse.

[Bruno T.]

Bonjour,

Si j'ai bien suivi toutes vos réflexions, la synthèse pourrait être:



- mettre par défaut subdivision en premier

- peut-être un parseur pour donner le choix à l'utilisateur des champs et de leur position lors de l'export, voire de donner la possibilité d'ajouter le 7e champ "lieu" dans PLAC



ce qui pourrait donner (dans une des formes possibles en fonction d'un parseur éventuel):

1 PLAC

2 FORM Subdivision, Ville , Code Lieu , Département , Région , Pays  

et encore

1 PLAC

2 FORM Lieu, Subdivision, Ville , Code Lieu , Département , Région , Pays

est-ce bien celà?

[DDdeBerdeux]

Bonsoir,

J'ai cru comprendre qu'entre Lieu et Subdivision, l'un des deux est de trop. Il est vrai qu'un parseur en exportation permettrait de satisfaire tout le monde, s'il permet non seulement d'ordonnancer les champs, mais aussi d'en supprimer. Il faudrait dans ce cas, ajouter Lieu au parseur d'importation. Le tag LIEU pourra ainsi être supprimé de l'exportation, mais il faudra garder la possibilité de l'importer à cause des anciens gedcom.

A+

André

[Facon]

Bonsoir,

Du fond de ma campagne ou du bord de mer, j'ai aussi cru comprendre que Lieu n'avait rien à faire dans "PLACE". Aquablue a déjà beaucoup commenté que Lieuuuuuuuuuuuuuuuu n'avait rien à faire ici (2004).

Par contre comme souligné par André, il faut assumer le passé et se préserver le champ Lieu pour ne pas compromettre les informations saisies sur ce point. Si je comprends bien, c'est intra Ancestrologie et pourrait alors se situer vers la fin de "PLACE".

Si on veut s'aligner sur le standard gedcom, Subdivision (je verrais d'ailleurs plutôt Lieu-dit, c'est plus causant) aurait sa place au début de la définition de "PLACE". Les avis sont partagés sur la question, faut-il le mettre au début juste pour être en conformité avec le standard ou à la fin pour s'aligner sur la disposition retenue par d'autres softs. A la limite, c'est indifférent, l'essentiel est de faire en sorte que l'information essentielle soit préservée à l'occasion d'un échange d'informations.

Comme chacun y a mis du sien dans le non-respect du standard, l'usage d'un parseur s'avère pratiquement indispensable. Dans ces conditions ce point peut se traiter via cette solution.

Faut-il un parseur à l'exportation ou à l'importation? A l'exportation, il faut connaître l'organisation du receveur, en pratique c'est le cas de Geneanet. A l'importation ceci me parait plus évident puisque l'émetteur n'a pas forcément connaissance des possibilités du receveur.

La question du nombre de caractères n'a pas été soulevée, je ne vois pas, en définitive, d'opposition à excéder 120c mais je maintiens qu'il serait bien d'avoir un radar pour signaler le dépassement.

La septième indication dans le champ "PLACE" pourrait être le code INSEE même si c'est franco-français. C'est malgré tout l'information complète de la ville ou de la commune en question. C'est certainement plus pratique pour les softs qui disposent d'une table VILLE_INSEE de mettre en clair le libellé de la commune (en France).

C'est aussi évident, mais il faut faire en sorte qu'un export Ancestrologie puisse être reimporté sur Ancestrologie sans perte.



En définitive, la version une que tu proposes est conforme au standard, la seconde permet d'assumer le passé. Je pense que nous ne pouvons pas omettre le passé.

Compte tenu de ce qui précède, j'opterais pour quelque chose du type:



1 PLACE

2 FORM {Subdivision (ou Lieu-dit), Ville, Code Lieu, Département, Région, Pays, Code INSEE, Lieu (à l'import)}



Cela fait huit indications dont une intra Ancestrologie et une option pour le Code INSEE.



C'est juste mon avis mais ce serait bien d'en finir sur ce point.

[Lya]

Bonsoir à tous,

Subdivision (je verrais d'ailleurs plutôt Lieu-dit, c'est plus causant)

En théorie, tous les niveaux d'un lieu sont des subdivisions !  

Les noms utilisés dans Ancestro sont basées sur le découpement administratif français, mais ce n'est pas "standard" ni universel. Le dernier niveau (plus précis que ville dans le cas français) peut donc rassembler Lieu-dit, Hameau, Quartier, Paroisse, etc...



Pour assumer le passé ancestrologique, faut-il fusionner les 2 champs Lieu et Subdivision en un seul ou les garder tels quels mais mieux les exporter ? Il serait peut-être utile de demander l'avis des utilisateurs sur ce point. Ce sont ceux qui ont utilisé ces 2 champs en même temps les 1ers concernés. :?



La fusion ramènerait le découpement à un total de 6 niveaux dont 1 numérique, ce qui pour ma part me semble suffisant.



Par contre, si on garde le 7e niveau, ce fameux "parseur" serait souhaitable car il est fort probable qu'au moins l'un des 7 (mais le premier, le dernier ?) ne sera pas géré à l'import dans nombre de logiciels.



Un parseur pourrait aussi permettre de choisir la fonction du 7e champ : on n'a pas forcément besoin de 2 niveaux après ville, mais on peut vouloir un sous-département (ou canton) avant la ville, suivant les pays étudiés.

[AquaBlue]

AMHA il est urgent de ne rien faire  



Il y a plein de choses qui ne marchent pas  dans Ancestrologie. Pourquoi changer ce qui ne pose pas vraiment de problème        

[Facon]

Bonsoir,

C'est le quart de nuit qui intervient.

Il est clair qu'avec des messages tels que ceux-là, PCM joue sur du velours pour envoyer promener (pour être correct) les demandes de modifications.

S'il y a plein de choses qui ne marchent pas dans Ancestrologie, ce serait déjà une en moins.

Par ailleurs faire un sondage auprès des utilisateurs ne présente pas à mon avis un grand intérêt, la volonté générale est que cela marche. Et l'utilisateur lambda n'a pas à se soucier de tous ces détails. Le produit est sensé, selon ce qui est écrit, être conforme au dernier standard gedcom 5.5.



Si tout ceci devait être abandonné, je pense que par respect vis à vis des utilisateurs présents ou à venir, il serait souhaitable de faire les mises en garde qui s'imposent pour indiquer que des fonctionnalités ne sont pas opérationnelles en indiquant, le cas échéant, les solutions de repli.



Ainsi l'utilisation des sources est à éviter, il est préférable de porter les indications dans les notes. Etc...



Dans un autre message, Aquablue a indiqué qu'il connaissait les défauts d'Ancestrologie et qu'il faisait le nécessaire pour ne pas perdre d'information. Ce serait intéressant de faire profiter tout le monde.



A l'image de ce qui a été fait pour Win 98, la clé, la mise à jour...., il me semblerait judicieux de créer un post-it ou une annonce à cet usage. Au moins l'information ne serait pas dispersée, disséminée, diluée dans le forum qui est inaccessible ou difficilement compréhensible pour un nouveau venu.

[Claude Baudin]

Je suis d'accord avec Aquablue il est trés urgent de ne rien faire, car au tarif ou c'est parti bientot il faudra être sorti de polytechnique pour se servir d'ancestro.

[Bruno T.]

...bientot il faudra être sorti de polytechnique pour se servir d'ancestro.

Bonjour,

Mon idée, pour éviter d'être un polytechnicien, mettre un outil permettant d'ordonner les champs à la demande, du style de ce qui existe à l'import, et pour rester convivial de l'accompagner d'un choix d'agencements préétablis correspondants aux logiciels destinataires les plus usités.

Il ne faut pas oublier non plus que le gedcom contient une ligne décrivant l'organisation de ce Tag, que peuvent mettre à profit les logiciels (Ancestrologie compris) lors de l'import