Le 26 octobre 2017 à 11:16, marc marc <marc_marc_...@hotmail.com> a écrit :
> Bonjour, > > Christian quand tu dis que Bano agrège différentes sources d'adresse > opendata dont osm, comment a l'inverse les outils utilisent bano ? > ça, c'est à chaque outil qu'il faut poser la question... > est-ce que nominatim ou un app utilise bano ? > A ma connaissance Nominatim n'utilise pas BANO. D'autres apps l'utilisent peut être, on n'a pas de moyen simple de le savoir, tout comme l'usage de données OSM par des applis d'une façon générale. > ou cela reste une superbe base composite mais utilisée uniquement > pour l'édition manuelle d'som ? > > Pas que vu le nombre important et régulier de téléchargements des données sur bano.openstreetmap.fr J'ai du mal à imaginer que ces fichiers soient régulièrement téléchargés pour ne pas être utilisés. On les retrouve même sur des plateformes régionales, exemple: https://geobretagne.fr/geonetwork/apps/georchestra/?uuid=9ffb161b-d8d8-4ec4-bde5-a03104300df8 Je peux au moins te dire ce que moi j'en fais: - j'ai une instance du géocodeur addok qui permet d'interroger BANO: bano.addok.xyz - je l'utilise chaque mois pour compléter le géocodage de la base SIRENE, car BANO contient les infos sur les lieux-dits alors que la BAN est très incomplète de ce côté. - j'ai mis en place un "meta-géocodeur" le week-end dernier qui permet en une requête d'interroger BANO, BAN et les POI d'OSM: all.addok.xyz Le 26. 10. 17 à 10:40, Nicolas Moyroud a écrit : > > Mais ce n'était pas sur la question des sources de données que portait > > la remarque de mon message précédent, plutôt sur la façon de modéliser > > les adresses dans OSM en France : ajout du numéro comme tag du bâtiment, > > sur un noeud isolé, ou sur un noeud attaché au contour du bâtiment. > > Une recommandation qui permette de clarifier et d'homogénéiser les > > pratiques serait la bienvenue ! > > Malheureusement, il n'y a aucune harmonisation a ce sujet. > Même la page qui renseigne LES différentes méthodes utilisées > n'est pas suivie partout. En résumé : > Pour les numéros de bâtiments il y a 5 méthodes : > - mettre le tag sur le bâtiment > avantage : est géré par "tous" les outils > désavantage : ne convient pas en cas de numéro multiple sur un bâtiment, > ou d'un numéro pour plusieurs bâtiment (une école par exemple) > - mettre le tag sur l'entrée du bâtiment > avantage : permet de gérer les bâtiments multi-numéro > désavantage : non supporté par les apps genre maps.me ce > qui conduit à créer des doublons et pire à des incohérences. > - mettre le tag sur un chemin fermé représentant +- la parcelle > ou sur un multipolygone > avantage : permet de gérer le cas d'un numéro multi-bâtiments > désavantage : peu supporté niveau apps > - mettre le tag sur un nœud hors du bâtiment, parfois situé à l'endroit > de la boite aux lettre, à la connexion du chemin privé avec la voie > publique, à l'endroit de la plaque avec le numéro ou l'endroit d’où > elle est visible. > avantage : j'en ai pas trouvé :) hormis la simplicité à la création > (pas besoin de réfléchir dans lequel des cas précédent on se trouve) > désavantage : oblige les outils à faire de la devinette pour trouver > la bâtiment concerné. devinette qui a donc un taux d'erreur. > Vu qu'il n'y a aucun lien entre le nœud isolé et le bâtiment, > cela conduit comme dans le cas précédent a des doublons > > pour les rues, il y a 2 méthodes : > - mettre addr:street sur l'objet qui possède addr:housenumber > avantage : supporté par toutes les apps > désavantage : donnée dupliquée > - créer une associatedStreet qui lie les numéros d'une rue avec la rue > avantage : maintenance que je trouve plus cohérente (le marque les > numéros avec une changeset source=survey, je fais l'associatedStreet > avec source=bano ou source=extrapolation) > - désavantage : support limité dans les apps > > pour addr:city addr:postcode addr:country, 2 méthodes : > - les gérer par des zones boundary (mais faudrait améliorer leur > prise en compte par les apps) > - les ajouter sur l'objet qui possède addr:housenumber (avantage : > géré par tous les outils, désavantage : données dupliquées) > > Le détail est là > http://wiki.openstreetmap.org/wiki/FR:Adresses > https://wiki.openstreetmap.org/wiki/Key:addr > > Mais ceci dit, autant je suis d'accord qu'il serrait utile de commencer > l'import des numéros de bâtiments pour les cas simple (par exemple > lorsque bano renseigne un numéro unique sur un bâtiment) vu qu'en > l'absence de cet import, on "consomme" du temps humain pour le faire, > autant je suis aussi d'accord qu'il est plus utile de commencer par > renseigner toutes les rues d'une commune avant de traiter les numéros. > Vu la diversité de modélisation des adresses dans OSM (pas qu'en France), c'est là aussi que BANO est utile car ça remet tout ça sous une unique forme simple et un réutilisateur ayant besoin d'adresses devrait plutôt regarder de ce côté (pour la France) que de se prendre la tête avec la donnée OSM brute car il faut prendre en compte ces cas, mais aussi la hiérarchie administrative, les relations boundary=administrative, les codes postaux, etc... L'harmonisation dans OSM est, il me semble, illusoire car après de nombreuses années, aucun consensus n'arrive à se dégager. Il faut donc la faire en aval et laisser la liberté en amont, surtout qu'on a quand même des cas bien différents à traiter. Ce qui serait bien, c'est plutôt des préconisations pour tel ou tel type de cas et surtout, de mon point de vue, faire comprendre que bâtiment et adresses sont deux choses différentes dans bien des cas. On a des adresses sans bâtiments, des bâtiments sans adresses, des bâtiments à plusieurs adresses, des adresses à plusieurs bâtiments.... bref c'est vraiment du N vers N et rarement du 1 vers 1 (je dois pouvoir sortir des stats à partir du cadastre) ! Ah oui... pour les parcelles c'est pareil... N vers N avec les adresses et aussi les bâtiments ! -- Christian Quest - OpenStreetMap France
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
