Marc, tu te trompe sur plusieurs points. contact:* est documenté et l'était bien avant qu'on en parle ici. Il s'agit bien d'indiquer pour un POI le moyen de le contacter, pas que via son adresse. Séparer la définition de l'adresse et celle du POI est assez logique.
Les deux schémas utilisé pour modéliser les adresses sont largement utilisables, que ce soit avec les relations ou sans. On peut tout à fait relancer la discussion, mais comme les éléments de départs n'ont pas changé, je ne vois pas pourquoi on arriverait à une autre conclusion. Il ne faut pas tout mélanger. Là, le départ c'est une anomalie signalée à juste titre par osmose (si j'ai bien suivi) avec des modifications faites à moitié. Les adresses ça semble simple, mais en même temps c'est complexe, ce que j'ai découvert en bossant ces dernières années sur le sujet. Pour beaucoup de monde il y a confusion entre adresse et bâtiment (d'où cette tendance à mettre des adresses sur les polygones de bâtiments) alors que non, ça n'est pas du 1 vers 1. J'ai encore dû expliquer à un dev ce matin qui réalisait un écran de saisie d'adresse sur une borne que non, les codes postaux ne correspondent pas à une commune... qu'il y a environ 6000 codes postaux et plus de 35000 communes (CQFD). Peut être devrions nous mieux expliciter tout ça sur le wiki pour bien faire comprendre la logique des adresses, ce qu'elles sont et ne sont pas, etc. Le 5 janvier 2018 à 13:15, marc marc <marc_marc_...@hotmail.com> a écrit : > Le 04. 01. 18 à 23:53, osm.sanspourr...@spamgourmet.com a écrit : > > une personne a vire le addr:housenumber parce que trop près de la > > voirie. > > http://www.openstreetmap.org/changeset/35942339 > > le problème est plus large que cela. > ce qu'on peux lui reprocher : > ses modifs sont incohérente avec le reste de la rue. > s'il voulait migrer le nœud addr au profit du bâtiment, il fallait le > faire au complet = supprimer totalement ce nœud et remplacer le noeud > par le bâtiment dans la relation assosciatedStreet > Et idéalement faire toute la rue en une fois pour garder une micro > cohérence toute symbolique et absurde que cela soie dans ce cas. > > L'autre problème, c'est qu'en mettant le nœud quelque part en bordure de > la parcelle, on confie au hasard le lien entre une adresse et un bâtiment. > Si on veux tager le fait que c'est la parcelle qui a une adresse et non > le bâtiment, soyons cohérent de taguer la parcelle (ce qui est hors de > portée du contributeur moyen). > Mais un tag de nœud mis positionné sans règle précise, c'est la foire. > Dans ton lien, il est par exemple impossible de savoir avec certitude > l'adresse du bâtiment au sud de la rue du Muguet > https://www.openstreetmap.org/node/2045090782#map=19/48.37680/-4.57899 > peut-être > <https://www.openstreetmap.org/node/2045090782#map=19/48.37680/-4.57899%0Apeut-%C3%AAtre> > est-ce le 27 à moins que le bâtiment de gauche aie 3 adresses > et que celui du bas n'ai pas encore d'adresse renseignée. > peut-être même que c'est le 19 Route de Trénen avec une allée privée non > renseigne. bref, faut prendre une vue satellite pour essayer de deviner > l'adresse > La solution de rapprocher le nœud du bâtiment revient implicitement à > dire qu'on considère qu'il y a un lien entre l'adresse et le bâtiment > tout en étant incohérent dans le fait de ne pas tager ce lien. > > Par conséquent, il ne faut pas s'étonner que des contributeurs finissent > par ajouter les adresses sur les bâtiments lorsque ceux-ci n'ont qu'une > adresse ou sur les portes d'entrée. > Et on a le même problème avec ceux qui placent les poi à l'entrée de la > parcelle (vu hier le cas hier d'un nœud en bord de route pour désigner > la présence d'une chambre d'hôte dans un bâtiment des environs) > aucun lien avec le bâtiment ni son adresse.. donc les gens finissent > par encoder l'adresse une 3ieme fois. > certains pensent que ce problème s'évite en utilisant une xieme > spécificité franco-francaise des contact:addr documenté nulle part et > donc utilisé par aucune app. > > Perso je suis triste de voir toutes ces infos inutilisable dans une > appli simplement par manque de schéma cohérent. > J'avais proposé qu'on s'attaque l'an passé à ce dossier difficile > mais pour le moment, la seule chose sur laquelle on est d'accord, > c'est le fait qu'on n'est pas d'accord. > peut-être pourrait-on faire un pas en voyant s'il y a au moins un accord > pour ouvrir ce chantier, chacun pourrait dire les problèmes pratique > qu'il rencontre et comment sa façon de tager permet de résoudre ou pas > ces problèmes. > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > -- Christian Quest - OpenStreetMap France
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
