forum Ancestrologie
Ancestrologie - Le Programme => Ancestrologie - Suggestions => Discussion démarrée par: Helene le 10 Février 2006 à 13:58:00
-
Bonjour,
Vu le dynamisme actuel et toutes les nouveautés qui ont été apportées (merci!), j'ose une suggestion :
J'aimerais beaucoup avoir pour chaque adresse une fiche, avec par exemple, une photo, possibilité d'avoir un peu d'histoire, les différentes orthographes etc...
Je sais qu'on peut avoir ca dans la fiche de chaque personne mais ce que je trouverais bien, ce serait des fiches indépendantes, plusieurs personnes ayant habité le même domicile.
Et à ce moment-là, un petit bitonio à côté des champs "lieu" des évènements individuels permettrait d'avoir accès à la liste des fiches d'adresse.
Après ce serait bien que sur la fiche adresse -et/ou dans creationweb- on puisse avoir la liste des gens qui sont nés, ont travaillé, ou sont décédés à cette adresse...
Je ne sais pas si c'est faisable, ni si ca intéresserait d'autres personnes que moi...
Bonne journée,
hélène
-
bonjour,
moi aussi, j'avais envie de savoir qui avait vécu dans certaines maisons, alors pour avoir une vue générale, je mets le nom de la maison entre parenthères après la commune.
le nom de l'habitation paraît ainsi sur tous les états ou listes et je n'y ai pour l'instant trouvé aucun inconvénient.
-
Bonjour,
Effectivement je trouve aussi que l'idée est très intéressante, :lol: :lol:
peut-être pour la prochaine version ?
Cordialement
Maryvonne
-
je mets le nom de la maison entre parenthères après la commune... .... et je n'y ai pour l'instant trouvé aucun inconvénient.
Bonjour,
Cà doit fausser toutes les stats par ville, et la liaison avec la vue satellite ne doit pas fonctionner, car les coordonnées sont retrouvées dans la table de référence par le nom de la ville (+ département je crois). A moins de créer ce nouveau lieu dans la table de référence.
Pour résoudre ce problème, il faudrait que la table de référence intègre un champ "subdivision", ce qui permettrait d'identifier et chaque lieu-dit, avec ses propres coordonnées, avec ses conséquences dans l'export gedcom.
A+
André
-
Bonjour,
En effet il faut éviter de toucher à ce qui peut avoir une influence sur les stats et autres outils externes à ancestro.
J'aurais plutôt pensé, et là philippe devra plancher ..
à un nouveau fichier de liaison interne, indexé à la fois sur les lieux et sur les individus avec pour chaque fiche de lieu la possibilité de lier plusieurs individus.
Je ne sais pas si j'ai été claire :lol: qui ne tente rien ..
cordialement
Maryvonne
-
un nouveau fichier de liaison interne, indexé à la fois sur les lieux et sur les individus avec pour chaque fiche de lieu la possibilité de lier plusieurs individus.
Le lien individu<->adresse existe déjà, il est créé par l'onglet domicile. Il suffit par une requête de retrouver les individus ayant la même adresse.
A+
André
-
Bonjour,
Merci pour le conseil, mais les requêtes dans ancestro ne me sont pas encore très familières, et le pur SQL me fait encore un peu sécher .. :oops: désolée à +
cordialement
Maryvonne
-
J'ai un peu l'esprit "d'escalier" :oops: pardonnez-moi de revenir au sujet,
l'idée était aussi d'éviter la nécessité de ressaisir l'adresse dans les fiches respectives des époux .. il m'est souvent arrivé d'en oublier .. la majorité des époux habitant ensemble, on pourrait au moins imaginer que ce détail se complète automatiquement à la première saisie (et seulement à la première, afin d'autoriser toutes les modif que la vie se charge d'imaginer)
:wink: :wink: :lol:
à bientôt
-
Bonsoir,
Mon message précédent était juste destiné à dire qu'il n'était pas nécessaire de créer une nouvelle table, puisque les informations existent déjà dans la base. Par exemple:select i.CLE_FICHE,i.NOM,i.PRENOM,a.adr_adresse,a.adr_cp,a.adr_ville
from individu i
INNER JOIN adresses_ind a ON a.adr_kle_ind=i.cle_fiche
AND a.adr_adresse='Le Tay'
AND a.adr_cp='56200'
AND a.adr_ville='La Gacilly'
order by i.NOM,i.PRENOMpermet de retrouver les personnes ayant habité à La Gacilly CP 56200, au lieu dit Le Tay. Mais comme la condition sur l'adresse est très restrictive, on peut la noter a.adr_adresse like '%Le Tay%' pour autoriser des différences dans l'emplacement des mots 'le tay' et une indifférence aux majuscules/minuscules.
Pour la fonction que vous proposez, je pense à un bouton qui ouvrirait la liste des conjoints et enfants à sélectionner pour y copier l'adresse, y compris les coordonnées de la photo.
A+
André
-
Merci pour l'extrait de SQL, :wink: :wink: il va vraiment falloir que je m'y torture la cervelle, bah la retraite ça doit bien servir à quelque chose ... :roll: :roll:
Un détail encore, si je n'abuse pas : le "lieu dit" correspond-t-il au champ 'Lieu' ou bien au champ 'Subdivision'. Dans mon coin de montagne vosgienne, il y avait autrefois : le village lui-même, puis les coteaux environnants qui portaient biensûr chacun un nom - la subdivision ? -
et sur ces coteaux des surfaces plus ou moins vastes de prés et de forêts qui elles aussi avaient un nom - le lieu ? -
et pour corser, les deux notions se mêlent dans certains documents.
L'idée du Bouton me semble excellente et correspond tout-à-fait au voeux que j'ai exprimé, merci de m'avoir si bien comprise. :D :D
Bien cordialement
Maryvonne
-
L'exemple que j'ai mis ci-dessus concerne l'onglet "Domicile", où le champ "Adresse" correspond au champ "adr_adresse" de la table des adresses.
Pour les évènements, il y a effectivement 2 champs disponibles: Lieu et Subdivision qui font l'objet d'une polémique car ils posent des problèmes de conformité à la norme gedcom lors de l'export.
A+
André
-
pardon pour mon temps de réponse.
Je crois que j'ai compris que les deux champs supplémentaires ne sont à utiliser que dans le but d'affiner des requêtes. Les éviter pour la transcription des données en GEDCOM.
(quoique lorsque j'ai démarré avec ancestro, j'avais fait un essai avec un concurrent - qui me plantait la connexion - et la récup en GEDCOM m'a perdu toutes les références aux lieux .. )
Encore une petite question :wink: à quel endroit puis-je trouver la correspondance des champs avec leurs noms respectifs à utiliser au sein du language SQL.
Merci d'avance
Bien cordialement
Maryvonne
-
Je ne connais pas de dictionnaire donnant la correspondance entre les étiquettes des champs dans la fiche, et leurs noms dans les tables. Mais les noms dans les tables sont en général suffisamment significatifs. Il y a quelques exceptions, comme le champ Lieu dont je parlais précédemment dans les évènements et dont le nom se termine par "adresse" dans les tables.
Le BOA montre les noms réels des champs.
Le problème avec Lieu et Subdivision, c'est que Lieu est exporté en gedcom avec un tag spécifique LIEU qui n'est pas connu par les autres logiciels. Les logiciels savent normalement interpréter la ligne PLAC du gedcom. Ancestro y place bien le champ Subdivision, mais en dernière position.
Définition en tête du gedcom:
1 PLAC
2 FORM Ville , Code Lieu , Département , Région , Pays, Subdivision
La norme disant que les champs doivent être dans l'ordre du plus détaillé au moins détaillé (ou l'inverse), Subdivision devrait donc être le Continent, information en général superflue.
De plus certains logiciels ne gèrent que 4 champs, et la taille de l'ensemble ne doit pas dépasser un certain nombre de caractères que les spécialistes pourront préciser s'ils le souhaitent.
Aquablue a développé la Mouliged pour mettre les choses en place quand l'export doit être utilisé par un autre logiciel, mais pour des besoins entre ancestrologues, nul besoin, les 2 champs sont bien transférés.
A+
André
-
je pense à un bouton qui ouvrirait la liste des conjoints et enfants à sélectionner pour y copier l'adresse, y compris les coordonnées de la photo.
Parfait, parfait ! Peut-être ajouter les parents dans la liste de choix ?
Et si la table est modifiée un jour, une case à cocher permettant de noter que le domicile est (a été) une propriété (au sens acquisition) familiale.
Patrick
-
Bonjour tout le monde, bonjour André,
Dans ton dernier message tu rappelles une des anomalies qui perturbe l'export d'un gedcom conforme au standard.
Même si ce n'est pas grave pour les échanges entre les Ancestrologues, cela devient plus génant pour les échanges avec ceux qui utilisent un autre soft.
La recette habituelle c'est bien sûr une pincée de Visuged, une cuillérée de BOA et quelques tours de Mouliged. Entre les mots, j'ai crû comprendre que c'était relativement simple à réaliser sans mettre à plat toute l'application. Pour mémoire cette anomalie et son traitement possible avait déjà été soulevée par Aquablue courant 2004.
Quand pouvons-nous espérer une solution propre à cette anomalie?
Qui doit opérer cette retouche?
Quelles sont les informations nécessaires au "retoucheur"?
Comment se fait la transition de la disposition actuelle vers la disposition standard?
Il faut bien commencer un jour.
-
A tes 2 premières questions, il n'y a que PCM qui peut te répondre.
La modification de l'export me semble le plus simple.
Pour PLAC je proposerai dans l'ordre:
lieu, ville, département et Pays
Pour le code postal il y a un tag POST.
Pour la région il y a STAE.
Si j'ai bien compris ce qui est écrit dans la norme (avis des spécialistes?), la longueur totale du tag PLAC ne doit pas dépasser 120 caractères. C'est la raison pour laquelle j'ai exclu la région de PLAC. De plus la notion de région est redondante (il n'y a pas 2 départements identiques), et comme le code postal, pas indispensable pour trouver le lieu.
Pour l'importation, la fiche "format des lieux" présentée lors de l'importation doit permettre de redéfinir l'ordonnancement. Il faudra y ajouter la colonne lieu et une case permettant d'identifier l'importation de gedcom à l'ancien format (avec le tag LIEU).
Comme disent souvent certains "Mais celà n'est que mon avis". Est-il partagé?
A+
André
-
André, je crois que tu mélanges les notions de Lieu (PLAC) et d'adresse (ADDR).
Les tags POST et STAE ne peuvent préciser que l'adresse, et leur gestion est d'ailleurs facultative pour les logiciels.
Le tag PLAC doit conserver le code postal et la région si on ne veut pas perdre les infos. C'est d'ailleurs ce que font les autres logiciels francophones me semble t'il. La seule modif envisageable est celle proposée par Aquablue, à savoir la fusion de Lieu et Subdivision.
L'actuelle disposition Ville , Code Lieu , Département , Région , Pays, Subdivision est certes une erreur, mais elle est partagée par d'autres et est généralement réparable à l'import quand ils demandent de préciser la nature de chaque champ.
-
Si je propose POST et STAE c'est uniquement pour éviter de créer des nouveaux tags spécifiques comme il est fait actuellement pour LIEU. D'autre part, il ne faut pas oublier cette limite de 120 caractères qui oblige à faire des choix. Entre le lieu (en général le lieu-dit) et le code postal (appelé code lieu dans ta liste), je préfère prendre le risque de perdre le code postal dans d'autres logiciels qui ne le gèrent pas.
Que je sache ce code postal n'existait pas à l'époque à laquelle vivaient nos ancêtres. C'est une notion créée par la poste pour ses propres besoins, qui n'est absolument pas nécessaire à la localisation, et de plus ne rentre pas dans la hiérarchie du plus détaillé au moins détaillé demandée par le gedcom. Si nous en avons besoin pour demander des actes en mairie, celà se fait depuis Ancestrologie où il est géré, et non depuis d'autres logiciels qui l'ignoreraient.
Quand à la région, on pourrait en dire presque la même chose. Cette notion n'est utilisée que dans des buts statistiques à l'intérieur d'ancestrologie. Est-elle utilisée par les autres logiciels?
A+
André
-
Bonsoir,
Pour restituer les choses un peu plus clairement, j'ai examiné les tables dans la configuration actuelle pour déterminer par rubrique le nombre maxi de caractères et espaces requis:
Pays: 30 max.
Région: 30 max.
Département: 30 max.
Code: 7 max.
Ville: 45 max.
La difficulté consiste à recenser l'association qui réclame le plus de caractères et espaces. Il y a ainsi une commune de 45 caractères située dans la Marne soit 50 caractères au total. La région correspondante est Champagne-Ardenne soit encore 17 caractères. Si on y ajoute le code 7 et les virgules (séparateurs) on arrive à un cumul de 79 caractères et espaces. Ceci laisserait 41 caractères disponible pour Subdivision ou Lieu desquels il faudrait retrancher les 6 caractères de la France.
Il faudrait examiner la totalité des cas, je vais voir ce que je sais faire.
-
Si je propose POST et STAE c'est uniquement pour éviter de créer des nouveaux tags spécifiques comme il est fait actuellement pour LIEU.
Si un tag n'est pas utilisé dans le bon contexte, il sera autant ignoré qu'un tag inventé. On ne gagnera donc rien au changement et on ne sera pas plus proche de la norme.
D'autre part, il ne faut pas oublier cette limite de 120 caractères qui oblige à faire des choix.
A condition que cette restriction soit respectée à la lettre à l'import. Quel logiciel pose ce problème ?
Que je sache ce code postal n'existait pas à l'époque à laquelle vivaient nos ancêtres. C'est une notion créée par la poste pour ses propres besoins, qui n'est absolument pas nécessaire à la localisation, et de plus ne rentre pas dans la hiérarchie du plus détaillé au moins détaillé demandée par le gedcom. Si nous en avons besoin pour demander des actes en mairie, celà se fait depuis Ancestrologie où il est géré, et non depuis d'autres logiciels qui l'ignoreraient.
Quand à la région, on pourrait en dire presque la même chose. Cette notion n'est utilisée que dans des buts statistiques à l'intérieur d'ancestrologie. Est-elle utilisée par les autres logiciels?
Certes, mais tu ne prends en compte que les pays français. Et les autres ? En plus, tu pars du principe que le logiciel receveur ne peut pas gérer les 6 champs. Et s'il le peut, pourquoi perdre l'info ?
Par ailleurs, on n'envoie pas toujours son gedcom à des francophones qui connaissent ces découpements, ce qui les obligera à rechercher l'info à chaque fois s'ils la veulent !
De mémoire, Hérédis, Geneweb (Geneanet)et Oxy-Gen les gèrent bien. Pour les autres, c'est à rechercher.
-
Si l'on te suit, tu es en train de dire qu'il faut tout mettre dans PLAC, en commençant par le lieu et tant pis pour la limite de 120 caractères et l'ordre préconisés par la norme puisque certains logiciels s'en moquent :?:
Mais si les "moins bons" laissent tomber les derniers champs, il reste impératif que les champs indispensables soient en premier et dans ce cas nous "français", mettons le CP et la région en dernier. Et demandons à PCM de laisser à l'utilisateur le choix de l'ordre des champs exportés, selon les structures administratives de son pays.
Que se passe-t-il si on dépasse les 120 caractères, sont-ils simplement ignorés?
André
-
Ce que je dis, c'est qu'il faut prendre en compte (au moins un peu) les autres logiciels et pas seulement crier au "respect de la norme" car la norme est l'outil, pas le but. L'objectif est bien de transmettre les données collectées entre logiciels, donc il faut regarder ce qui se fait hors Ancestro.
Il semble que les logiciels francophones aient adopté + ou - le même format, à savoir : Ville , Code Lieu , Département , Région , Pays, Subdivision
Pourquoi Subdivision a atterri en dernier ? Je l'ignore.
Faut-il le remettre en premier ? Oui si on y gagne une meilleure compatibilité avec les autres logiciels, mais c'est à vérifier au préalable. J'aimerais par exemple que quelqu'un me cite des logiciels qui ne gardent que 4 champs. En existe t'il qui en exportent plus de 6 ?
Pour la limite à 120 caractères, c'est aussi un choix. Les autres logiciels sont confrontés au même problème qu'Ancestro, quelle a été leur politique ? Appliquer strictement la norme au risque de perdre des infos, ou ne pas se limiter à 120 caractères et tout recueillir/transmettre ?
Un seul moyen de le savoir : tester.
Un choix des champs exportés (et éventuellement de leur ordre) serait effectivement une bonne solution qui laisse la décision à l'utilisateur en fonction de ses besoins.
-
Bonjour,
Après une nuit de durs labeurs (je plaisante) voici les résultats.
J'ai examiné les tables jointes en standard à Ancestrologie.
L'association Ville/Code/Département/Pays culmine à 67 espaces et caractères (Castillon (Canton d'Arthez de Béarn) dans les Pyrénées Atlantiques) avec seulement 10 cas supérieurs à 60.
Je n'ai pas fait l'exercice avec la région. Pour celle-ci le cas le plus défavorable est de 30 espaces et caractères (Géorgie Sud & Ile Sandwich Sud), 26 dans le cas de la France.
En résumant: l'association Ville/Code/Département/Région/Pays en prenant le cas le plus défavorable de 26 pour les régions de France donne un total max de 67+26 = 93 caractères et espaces auxquels il faut ajouter les 5 séparateurs soit 98.
Sauf erreur ou omission, ceci laisse 22 caractères et espaces pour Lieu ou Subdivision. C'est en définitive confortable.
Je pense que nous sommes en face d'un faux problème au moins pour les tables connues.
Il est éventuellement possible de jouer sur quelques points (ex: St au lieu de Saint) mais est-ce que le jeu en vaut la chandelle?
Si j'ai le courage j'affinerai pour la France mais ce n'est pas le seul pays repris en généalogie.
-
Peut-être faudrait-il faire un sondage pour savoir quel champ est utilisé par les "ancestrologues" pour mettre le niveau le plus détaillé des lieux où sont intervenus des évènements.
Pour ma part, j'ai toujours utilisé "Lieu", sans doûte pour sa similitude avec le "lieu-dit", mais aussi parce que dans les tables ce champ est nommé ADRESSE. Et j'ai l'impression que ceux qui ont utilisé Subdivision, c'est surtout pour pouvoir exporter cette information dans leurs gedcoms destinés à d'autres logiciels (à condition qu'ils sachent mapper les champs). Il me semble que c'est également pour celà qu'Aquablue a inclu une option dans sa Mouliged, qui met le lieu à la place de subdivision en fin de la chaîne PLAC. Mais pourquoi ne l'a-t-il pas mis au début?
Quand à Subdivision? Peut-être y mettra-t-on un jour "UE"?
Le lieu-dit est-il enregistrable dans tous les logiciels?
Pour PAF c'est très simple, tout est dans le même champ, séparé par des virgules, à la convenance de l'utilisateur et à ses pires oublis. Je ne sais pas s'il peut dépasser les 120 c. (pour les Mormons la ville suffit, ils savent où trouver le cimetière... :wink: )
22 ce n'est pas trop pour le lieu, je viens d'écrire "La Malvergne du Martinet", 24c, mais le reste n'atteint probablement pas 98c.
A+
André
-
J'ai un peu l'esprit "d'escalier" :oops: pardonnez-moi de revenir au sujet,
l'idée était aussi d'éviter la nécessité de ressaisir l'adresse dans les fiches respectives des époux .. il m'est souvent arrivé d'en oublier .. la majorité des époux habitant ensemble, on pourrait au moins imaginer que ce détail se complète automatiquement à la première saisie (et seulement à la première, afin d'autoriser toutes les modif que la vie se charge d'imaginer)
Que se serait chouette ! Vite un bouton svp.
-
Bonsoir André,
J'ai poursuivi l'exercice avec les régions en travaillant par exception.
Le cas le plus défavorable en France pour l'association: Ville/Code/Département/Région/Pays s'avère être celui de Châteauneuf-lès-Moustiers dans les Alpes-de-Haute-Provence situées dans la région Provence-Alpes-Côte d'Azur. le tout totalisant 87 caractères et espaces.
Si on y ajoute les 5 séparateurs, il reste 120-87-5 = 28 caractères et espaces pour la subdivision ou lieu.
Ton cas s'arrange mais pas forcément les autres hypothèses plus longues. Mais ce n'est pas si mal.
-
Bonsoir
Une petite info complémentaire sur la longueur des lignes du format gedcom.
Le nombre de caractères comprend le niveau, et les tags. Donc dans le cas de PLAC il faut ajouter 7 caractères plus le retour à la ligne a vos calculs L PLAC
1234567
The total length of a GEDCOM line, including leading white space, level number, cross-reference
number, tag, value, delimiters, and terminator, must not exceed 255 (wide) characters.
-
Ce que tu dis est valable pour la longueur totale de la ligne.
Mais la chaîne correspondant au tag PLAC ne doit pas dépasser 120c.
PLACE_VALUE: = {Size=1:120}
[
<TEXT> |
<TEXT>, <PLACE_VALUE>
]
The jurisdictional name of the place where the event took place. Jurisdictions are separated by commas, for example, "Cove, Cache, Utah, USA." If the actual jurisdictional names of these places have been identified, they can be shown using a PLAC.FORM structure either in the HEADER or in the event structure. (See <PLACE_HIERARCHY>.)
A+
André
-
Bonjour,
Je rentre d'une semaine de plongée en mer Rouge et je trouve vos échanges.
C'est Hérésie qui a inventé et mis Subdivision à la fin de PLAC :(
De ce fait tous les utilisateurs et programmes français sont habitués à le trouver dans cette position.
Le concepteur d'Ancestrologie qui semble avoir soigneusement étudié la concurence, a logiquement intégré cette "anomalie".
De plus un utilitaire comme GedLieu permet très simplement de réorganiser PLAC comme vous le souhaitez. Par ailleurs les "vrais" logiciels proposent normalement un "parseur" de PLAC lors de l'import.
C'est pour cela que je crois qu'il est totalement inutile de "bouger" cette zone même si en théorie elle devrait être au début.
Pour LIEU c'est tout simplement une verrue totalement inutile qui a été ajoutée posterieurement par le repreneur du logiciel qui n'a pas compris le travail du concepteur. Cette zone est totalement spécifique et en plus elle ne sert à rien.
La seule chose à faire est de la supprimer.
Une ligne GEDCOM doit faire maximum 255 caractères, je n'ai pas trouvé de logiciel qui se limite strictement aux 120 c de la norme pour PLAC. Il me semble donc inutile d'appliquer strictement cette limite.
Enfin, à mon humble avis, les éléments d'un lieu doivent permettre de le localiser facilement sur une carte moderne. Donc le code postal ou le code INSEE sont des éléments très utiles (spécialement pour les lieux qui éxistent en plusieurs exemplaires dans un même département) et je les utilise même pour les siècles passés malgré l'anachronisme.
Faut-il saisir St-Jean-d'Acre (Terre-Sainte) ou St-Jean-d'Acre (Israël) ou bien Akko (Israël) ??? Pour les croisés j'ai choisi la deuxième forme et le pays moderne malgré l'anachronisme.
-
Bonjour,
Si je te comprends bien, l'hérésie c'est d'utiliser LIEU. Et nous devrions utiliser SUBDIVISION pour y mettre le niveau le plus détaillé de l'endroit que l'on veut mémoriser.
Où je suis un peu moins d'accord avec toi, c'est lorsque tu dis que:
-la limite à 120 c n'a pas d'importance puisque les logiciels acceptent de dépasser cette limite,
-l'ordre a peu d'importance puisque les bons logiciels ont un parseur qui permet l'affectation aux différents champs, et que Gedleu permet de les réordonnancer dans le gedcom.
Si tu as eu le temps de voir les messages que tu as manqués, tu as dû voir cette discussion concernant l'intégration de Filiatus dans une dll. Il en ressortait que si l'utilisation n'était pas très fréquente, et si le logiciel n'utilisait pas d'informations d'ancestrologie non transportées par le gedcom, il n'y avait aucun intérêt à l'intégrer en dll (qui ne serait pas gratuite non plus). Le transfert par export/import gedcom est suffisant.
Il me semble que ce raisonnement logique est remis en cause si l'interfaçage nécessite le passage par un Gedlieu pour réordonnancer les champs, ou l'acquisition au travers d'un "parseur" qu'il faudra règler pour acquérir le gedcom.
Je me sert très fréquemment de KStableau (que tu ne dois pas classer dans les "vrais" logiciels d'après tes critères), parce qu'il me permet de visualiser l'arbre et les implexes tout en consultant les fiches d'ancestro, ce qu'il n'est pas possible de faire avec les arbres intégrés ou en dll. J'ai constaté qu'il visualise la chaîne PLAC dans sa forme brute, sans aucune possibilité de la modifier. Tu comprendras donc que pour ce type de logiciel, une chaîne ordonnancée et courte à de l'importance.
Je préfèrerai lire "Le Tay, La Gacilly, Morbihan, Bretagne, France" que
"La Gacilly, 56200, Morbihan, Bretagne, France, Le Tay".
Même la région n'est pas indispensable en France pour localiser le lieu. Mais elle l'est sans doûte dans d'autres pays.
Je ne sais sur quelle carte moderne tu trouves le code postal et/ou le code INSEE? Il me semble qu'ils ne sont utiles, le premier que pour le poste, le second qu'à des fins d'analyses statistiques. Il ne m'ont jamais servi à localiser un lieu. La norme présente peut-être une lacune, s'il n'y a pas d'autre moyen de les mémoriser ailleurs que dans PLAC.
Je ne connais pas non plus de villes françaises du même département, ayant le même nom complet...
Comme toi j'utilise en général le nom actuel du lieu, seul moyen de le retrouver sur une carte, quitte à mettre en notes le nom de l'époque, ou le nom français s'il s'agit d'une ville étrangère (ex: les morts pour la France 1914-1918 en Serbie).
A+
André
-
Bonsoir,
Toujours dans l'esprit de maintenir les 6 indicateurs: Subdivision/Ville/Code/Département/Région/Pays indistinctement de l'ordre, nous pouvons éventuellement envisager de remanier une chose, une Région.
En effet, la région la plus consommatrice en caractères est la "Provence-Alpes-Côte d'Azur". La suivante "Languedoc-Rousillon" consomme quant à elle 20 caractères. Il est possible d'épargner encore 6 caractères pour "Subdivision" en utilisant PACA ou une écriture approchée de ladite région.
Dans ces conditions, pour la France, dans les conditions limites, le nombre de caractères dédié à "Subdivision" deviendrait 28 (message du 14 juin 2006) + 6 = 34 caractères.
Ce point devrait pouvoir être réglé ainsi.
-
Pour la limite des 120 c j'ai dit qu'aucun logiciel que j'ai testé ne se limite à ces 120 c et que donc il ne me parait pas nécessaire de gérer cette limite surtout si on utilise Subdivision qui peut être grand.
GedLieu permet de re-organiser PLAC comme on le veut : permutation des zones mais aussi de ne prendre que certaines zones ce qui devrait te convenir pour obtenir des Lieux courts.
Pour Ïatus si on passe par un gedcom ce n'est pas difficile d'utiliser GedLieu, si une dll est créée elle attaquera la base en direct donc pas de problèmes (quoique quand on regarde la base Access qu'il utilise on est pris d'un doute violent !)
J'ai toujours dit qu'Ancestrologie devrait au moins importer ce qu'il exporte. Après quelques tests je n'utilise que ce qui est importé/exporté sans pertes. Comme ça je passe sans problèmes d'Ancestrologie à n'importe quel soft via GEDCOM et quand ça ne me convient pas j'utilise MouliGed ou autre.
Ayant environ 27 000 personnes dans ma base je te dis pas le bor..l avec KStableau mais en "visuel" je préfère voir "Le Tay, La Gacilly (56)" que "Le Tay, La Gacilly, Morbihan, Bretagne, France" et c'est l'une des fonctions de MouliGed que tu peux utiliser sur ton GEDCOM avant de l'injecter dans KStableau.
Moi je l'utilise avant d'injecter mon GEDCOM dans GeneWeb qui m'offre en un seul logiciel extremement rapide toutes les fonctions de Ïatus et de KStableau et d'autres fonctions qui n'éxistent ni dans l'un ni dans l'autre.
Et en plus mes données ne vont se promener ni chez mon FAI ni chez Geneanet et restent bien sagement sur mon PC tout en etant consultable "en ligne"
Enfin pour le code postal et le Code INSEE s'il ne figurent pas sur les cartes ils sont souvent le seul moyen de distinguer deux lieux homonymes d'un même département. Contrairement à ce que tu crois il y a(vait) énormément de communes portant le même nom dans le même département et c'est bien à l'INSEE qu'on doit leur changement de nom pour rendre ce nom "unique". Il reste des communes portant le même nom mais dans des départements (et je crois même régions) différents. Demande à Ransac comme on s'est pris la tête quand on a construit la base des communes de France.
-
Bonjour,
Juste une petite relance pour éviter que le sujet tourne en eau de boudin.
Mon avis est le suivant et c'est juste mon avis:
Très régulièrement il est rappelé que Ancestrologie n'est pas conforme en tous points au standard Gedcom et je l'avoue, la tâche ne doit pas être facile pour différentes raisons: interprétation, inadaptation dans certains cas avec la vie d'aujourd'hui, mauvaise compréhension, etc...
C'est tout de même un fil conducteur destiné aux échanges d'informations et dans ces conditions ma recommandation serait, lorsqu'il n'y a pas d'ambiguité, de respecter le standard.
Au diable si d'autres ont fait des dérogations, des erreurs ou des adaptations, dans le cas présent il faut respecter la longueur des 120c avec la possibilité comme l'explique Aquablue de faire des coupes sombres avec les outils appropriés. Il faut respecter l'ordre d'apparition des composantes (6) de "PLACE", quitte à encore utiliser les outils préconisés par Aquablue.
Il ne faut plus créer une nouvelle variante sous peine d'entendre le titulaire d'Ancestrologie dire: je ne suis pas conforme (le soft!!) et vous me demandez d'aller vers une nouvelle voie qui ne l'est pas non plus.
A cette occasion ce serait bien que Philippe s'exprime sur le sujet et sur sa volonté de faire vivre le produit dans le bon sens.
Enfin cela va sans dire mais encore mieux en l'écrivant, Ancestrologie doit être apte à réimporter ses propres exports sans restriction.
Excusez moi d'insister, il y a d'autres rectifications à entreprendre avec l'aide de Philippe, il faut donc avancer.
-
Bonjour à tous
Au diable si d'autres ont fait des dérogations, des erreurs ou des adaptations,
Désolé d'être en désaccord avec toi sur ce point !
Je ne vois en quoi le fait de respecter strictement une limite que personne ne respecte nous fera avancer ! Si tu te moques de ce que font les autres softs, quel est l'intérêt d'être conforme à la norme ?
Au risque de me répéter, la norme est là pour nous guider vers une uniformisation, pas nous imposer des règles sans intérêt. Si en fin de compte l'uniformisation s'est faite différemment de ce qu'elle préconise, c'est cette évolution qu'il faut suivre et respecter !
Encore, pour la place de Subdivision à la fin, je veux bien, mais les 120 caractères ? :roll: Si tu veux faire avancer le débat, amène des arguments. Quel logiciel as-tu rencontré qui pose ce problème ?
Pour ma part, je m'aligne sur la position d'Aquablue pour cette histoire de PLAC. Je crois qu'il est inutile de créer des problèmes là où il n'y en a pas. :evil:
-
mais les 120 caractères ?
Tout à fait d'accord.
Il est des moment ou l'usage fait loi et ou la loi s'adapte à la réalité.
Pour les 120 caractères, qui peut le + peut le moins. Un libellé trop long sera simplement tronquer --> qui veut se contenter de 120 caractères le peut.
-
Rebonjour,
Je ne fais pas une fixation sur le nombre de caractères dédiés à la définition du champ "PLACE", j'ai fortement tendance à penser qu'il n'est pas nécessaire de déroger au standard.
En effet, dans les messages précédents, j'ai expliqué que j'avais examiné avec les tables associées à Ancestrologie le nombre de caractères maxi auquel nous pouvions être confrontés dans le cas de la France.
Il s'avère que dans le pire des cas, en utilisant les 6 critères de description d'un lieu, indépendamment de l'ordre d'apparition, nous avons 28 caractères disponibles pour décrire ce qu'il convient d'appeler dans notre jargon: lieu ou subdivision. Cela me semble raisonnable mais je suis certain que quelqu'un trouvera l'exception. Pour nous rassurer, nous avons également pour les cas tordus, la possibilité d'ajouter des éléments dans la rubrique note et d'autres diront que les notes ne sont pas nécessairement exportées avec le gedcom.
Si pour faire avancer la question il est considéré qu'il est indispensable d'utiliser tout ou partie des 255 caractères maxi d'une ligne gedcom, pourquoi pas mais à la condition de faire en sorte que l'éventuelle perte d'information lors de l'import sur un autre logiciel ne se répercute pas sur les données essentielles. Je concède que la perte de la notion de région en France ne porte pas à conséquence, qu'en est-il pour un autre pays? Ce qui est certain c'est qu'une généalogie ne se limite pas à la France, pour d'autres pays la description de la région peut-être fondamentale. Les divers outils cités ne donneront pas la possibilité de faire une extraxtion de données selon un schéma pour un pays et suivant un autre pour un autre pays.
Pour ce qui est de la position du lieu plus précis par rapport au lieu le plus général, il suffit de se rapporter à ce qui est inscrit ci-dessus. S'il devait y avoir de la perte de données (données tronquées), il conviendrait de faire en sorte que les éléments perdus ne soient pas des données essentielles. A quoi bon savoir que l'événement se déroule à dans un endroit extrémement précis et détaillé si à la fin nous ne savons pas que c'est en Ecosse,en Pologne, ou au Canada.
Dans l'hypothèse d'une dérive par rapport au standard il conviendra de ne plus traiter les autres logiciels de daube ou d'autre qualificatif tout aussi exotique et il faudra accepter les questions qui ne manqueront pas de venir: j'ai perdu des données dans un export, qu'est ce qu'il faut faire? Sur ce dernier point je reste convaincu que le risque est mince mais mea culpa je n'ai examiné que le cas de la France. Est-il concevable de mettre une alarme 120c dépassés pour pouvoir se contenter de 120c?
Pour résumer, je maintiens mon point de vue sur la question du standard.
Pour ce qui est de mon expérience avec d'autres logiciels, elle est nulle. Je ne butine pas d'un logiciel à l'autre pour faire de la saisie sur l'un, des arbres sur l'autre et de l'édition sur un troisième.
Maintenant toutes ces discussions sont intéressantes mais ne présentent de l'intérêt que dans la mesure où Philippe donne un signe positif sur sa volonté à conduire ce genre de modification pour lequel il est le seul à avoir l'accès.
Je ne suis pas un vétéran du Forum, Aquablue avait déjà cité les anomalies en 2004 et elles sont toujours là. Il tombe sous le sens qu'un produit contient au neuvage des anomalies, il est une pratique normale de faire le nécessaire pour y remédier. Je pense pouvoir dire que nous sommes sortis du neuvage.
-
Bonsoir
Pour ce qui est de mon expérience avec d'autres logiciels, elle est nulle. Je ne butine pas d'un logiciel à l'autre pour faire de la saisie sur l'un, des arbres sur l'autre et de l'édition sur un troisième.
Moi, oui. Si Ancestrologie est mon logiciel principal et préféré, je recours fréquemment à l'export pour visualiser ma généalogie dans Oxy-Gen ou Geneweb, et aussi pour envoyer des données à des correspondants. C'est pour ça que l'amélioration de l'import/export ou de la gestion des sources me tient à coeur, même si comme Aquablue, je connais les "pièges" d'Ancestrologie et sait donc les éviter.
Je comprends ton désir de "coller" à la norme, mais de ton côté il faut que tu acceptes qu'en matière de gedcom, la théorie c'est bien, mais la pratique c'est mieux !
Pourquoi j'insiste pour prendre en compte ce qui se fait dans les autres logiciels ? Simple : prenons cet exemple de limitation à 120 caractères.
En théorie, Ancestro ne respecte donc pas la norme. Comme on te l'a fait remarquer, c'est aussi le cas de la plupart des autres softs. Disons pour simplifier que 80 % d'entre eux n'en tiennent pas compte et 20 % la respectent strictement : Ancestro est donc compatible avec 100 % des logiciels à l'import (dans Ancestro) mais seulement 80 % à l'export.
Maintenant, si tu respectes la limite à 120 caractères à l'export, logiquement, tu dois faire la même chose à l'import, donc soit tronquer l'excedent, soit le mettre ailleurs (mais où ?). Le problème, c'est que 80 % des autres softs exportent toujours plus de 120 caractères... Ancestro devient donc compatible avec 100 % d'entre eux à l'export mais seulement 20% à l'import !
Crois-tu toujours qu'on a gagné en compatibilité en respectant la norme ?
Ceci n'est qu'un exemple mais il montre que la norme nest pas sacro-sainte. On doit s'y référer d'accord, mais pas la suivre aveuglément. Et je ne parle même pas des cas sujets à interprétation, comme la gestion des témoins dans les actes...
-
Bonsoir,
J'ai pris bonne note des commentaires et je retiens notamment qu'en étant non conforme au standard et aussi parce que d'autres sont pour certains conformes et d'autres non conformes, nous prenons le risque de perdre des informations à l'importation sur des logiciels concurrents.
-1- Pour être bien franc, j'ignore le nombre de caractères tolérés par Ancestrologie dans le champ "PLACE" à ce jour,
-2- Je pense qu'un bon compromis, si nous allons dans le sens de la déviation par rapport au standard, serait d'attirer l'attention de l'utilisateur sur le fait qu'il dépasse la limite théorique et qu'il prend un risque de perte d'information à l'occasion d'un échange d'information. Il restera à l'utilisateur de se déterminer à sa convenance.
Il reste clair que Ancestrologie doit être capable de réimporter ses gedcom sans perte d'informations.
J'ai bien compris également que les libertés prises par chacun conduisent l'utilisateur à réorganiser, le cas échéant, l'ordre des descriptions des lieux en fonction du receveur.
Dans ces conditions, la remise en ordre est pour quand?
-
Bonsoir,
Dans la mesure où le seul risque encouru si on dépasse les 120 caractères, est que les infos contenues dans le dépassement soient perdues par les logiciels qui ne n'acceptent pas ce dépassement, je pense que ce n'est pas grave, dans la mesure où les infos importantes sont misent au début comme le demande Christian.
Pour celà il me semble logique de mettre en tête les infos essentielles à la localisation de l'évènement qui sont:
subdivision ou lieu (mais un seul des 2)
ville
département
Région (quoique pas indispensable en France, mais peut-être ailleurs)
Pays
puis les "extras"
CP
et pourquoi pas en poussant le raisonnement, si on reste dans la limite des 255c de la ligne, d'autres champs pour lesquels il n'aurait pas été nécessaire de créer des tags spécifiques, et que les logiciels équipés de "parseur" savent exploiter comme:
INSEE
Celà fait 5 champs indispensables (qu'on pourrait réduire à 4 en inversant pays et région)
J'ai l'impression que le normalisateur américain a estimé que 120c étaient suffisants, dans la mesure où les noms des états sont abrégés. Le problème ne serait-il pas dû à la forme très longue et littéraire adoptée dans ancestrologie pour les noms de départements et de régions, qui posent également des problèmes quand il faut les caser dans les états, les arbres etc... et qui font qu'on choisit souvent de ne pas les afficher... Voir le choix d'Aquablue: 56 pour Morbihan et pas de région. Adopter une forme plus compacte, serait une solution si la limite de 120c est vraiment gênante.
Bonne nuit
André
-
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.
-
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.
-
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é
-
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.
-
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?
-
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 !
-
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. :evil:
-
Faudra dire à Aquablue de le classer dans les mauvais. :lol:
Bonne nuit
André
-
Bin non puisque j'ai écrit MouliGed rien que pour lui :!: :D :D :D
-
Bonjour,
Est-ce que quelqu'un est en mesure de nous dire où nous en sommes dans la mise en ordre de "PLACE"?
-
je ne pense pas que ce soit au programme immédiat étant donné que la gêne est relativement faible ! :mrgreen:
-
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é
-
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.
-
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à?
-
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é
-
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.
-
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 ! :wink:
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.
-
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 :?: :?: :?: :?:
-
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.
-
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. :wink:
-
...bientot il faudra être sorti de polytechnique pour se servir d'ancestro. :wink:
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
-
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.
Toi tu dois être "chef" car tu es très fort pour refiler du boulot aux autres sans avoir jamais rien fait toi même :!: :D :D
Alors au lieu de réclamer tu retrousses tes manches et tu le fais toi même :!:
Il suffit de
- créer une famille qui utilise tous les champs de tous les évènements en remplissant chaque champ au maximum
- export GEDCOM
- editer ce GEDCOM avec le Bloc-Note et relever tout ce qui manque ou qui a été tronqué
- import de ce GEDCOM dans une nouvelle base vide et vérifier tout ce qui n'a pas été importé ou encore tronqué.
YAPLUKA faire un tableau avec les résultats.
-
Bonjour,
Ni chef ni polytechnicien.
La tâche que tu me proposes a déjà été faite par Lya.
Ce sont les solutions qui sont intéressantes.
-
Oooooooh! Je crois que tu as mis Aquablue dans le rouge :wink: :lol: :lol: :lol:
-
Oooooooh! Je crois que tu as mis Aquablue dans le rouge :wink: :lol: :lol: :lol:
Et quand on met du rouge dans le bleu, ça devient AquaBlueS :lol: :lol: :lol:
-
Il me semble que Aquablue est l'une des personnes connaissant le mieux les limites d' ancestrologie concernant le gedcom. Je me permets de rappeler la réponse qu'il m'a faite sur le forum de visuged en novembre 2005 concernant une anomalie que visuged détectait dans mon gedcom issu d'ancestrologie :
"C'est un très vieux BUG que l'auteur ne sait pas corriger car ce n'est pas
lui qui a écrit le code d'import/export GEDCOM."
Dans ces conditions, inutile de s'étonner que PCM ne réagisse pas aux demandes de mise au carré de l'export gedcom. Sauf personne compétente volontaire pour le faire, on risque d'en rester là pour encore longtemps.
-
Je ramène à la surface ce sujet pré-estival... non pour relancer le fruteux débat, mais pour faire un résumé des 5 pages...
- le champ 'subdivision' doit être privilégié pour le quartier / lieu-dit et autres hameau. Subdivision pourrait judicieusement être renommé "lieu-dit"
- le champ 'lieu' concerne davantage l'adresse, le nom de la maison.
- les infos visibles concernant la localisation (PLACE) d'un évènement pourraient être :
1 PLACE
2 FORM {Subdivision, Ville, Code Lieu, Département, Région, Pays, Code INSEE, Lieu (à l'import)}[/quote]
- un outil, 'parseur', pourrait permettre de laisser une certaine latitude de choix pour l'ordre apparant de ces infos
Ceci n'ayant qu'un caractère d'information...
Chacun voyant les éléments secondaires à sa porte, et Philippe étant maître à bord pour faire évoluer tout ça :wink:
NB : Philippe, ce serait bien s'il était possible de corriger la faute d'accent sur département :oops:
-
Un détail de chez détail... si une faute d'accent est un détail :oops: :wink:
Dans les fenêtres 'événement'...
NB : Philippe, ce serait bien s'il était possible de corriger la faute d'accent sur département :oops:
Dans les fenêtres 'événements associés à une union', même accent sur Dépt
:wink: