Re: [OSM-dev-fr] (sans objet)
Si on juge son travail, sa méthode fournit trop de faux positifs sur l'absence d'adresses. Il suffit de voir comment il surcharge en rouge tellement de bâtiments à Paris dans n'importe quelle rue, pour se rendre compte que pour lui il faut absolument que chaque bâtiment porte un point d'adresse et que ce point doit absolument être dans le polygone du bâtiments ou sur sa limite (et encore cela ne suffit même pas, il trouve des faux-positifs même là où il y a un point d'adresses). Pour lui no devrait répéter le point d'adresses pour chaque construction, chaque barraque au fond du jardin. Dans certains lieux où une école et un temple protestant forment un ensemble de batiments modélisés par des polygones différents mais associés strictment à la même adresse (même numéo, même rue), il va mettre en rouge un des deux batiments, alors que la base d'adresses est absolument complète, tous les numéros éant correcement positionnés. Certes si on est en face du bâtiment dans la rue, ou peut se demander si c'est le 19 bis ou le 21. Mais OSM n'est pas là pour inventer des points d'adresses plus précis que la réalité. Si on veut savoir on va éventuelelment regarder les boites aux lettres mais elles peuvent parfois être regroupées sur plusieurs numéros. Ou regarder le nom sur la sonnette (qui rarement indique le numéro utilisé par son résident). En faisant les choses le mieux possible, il est clair qu'il y a un découplage total entre les bâtiments d'une part et les noeuds d'adresse d'autre part, qui même complets ne peuvent pas suffire à déterminer le numéro d'un bâtiment. Et d'ailleurs ce n'est me^me pas nécessaire puisque pour se géolocaliser en ville, on indique un numéro dans la voie et une fois sur place on n'est plus à 10 mètres près et ce qu'on cherche ce n'est plus le numéro mais le résident parmi les portes autour, qu'il va fallloir chercher par son nom, par son numéro d'étage, et parfois en pénétrant dans une propriété et traversant un hall commun pour trouver le logement dans une cour privée derrière, un bâtiment qui n'est pas directement sur la rue, alors que le même logement aura sa boite à lettre souvent groupée avec ceux du premier bâtiment traversé. Sa méthode qui aboutit à tellement de faux positifs peut aboutir certains à surcharger la base de points d'adresses totalement identiques dans leur contenu, mais à des positions multiples. Ou à tracer des polygones englobants plusieurs bâtiments (on va se retrouver à cartographier les limites exactes de propriétés privées...) Btef c'est la méthode qui est criticable bien plus que la supposée 'absence" d'adresses alors que celles-ci sont largement suffisantes (et déjà complètes). On se demande ce qu'il va vouloir faire dans les zones où il n'y a strictement aucun numéro dans les rues, mais juste des noms de secteurs. Dans certains pays on n'a même pas le choix, les numéros n'existent pas (par exemple presque partout dans les métropoles japonaises), où même les rues n'ont pas de nom ou numéro unique, les numéros d'axe pouvant se superposer car ils renseignent sur des itinéraires et non la voie...). Bref il cherche des poux là où il n'y en a pas, et est sans doute trop orienté par ce qu'il a observé chez lui, dans son pays ou sa ville, en voulant absolument calquer cela ailleurs. Le 5 avril 2013 19:33, yvecai a écrit : > Il me semble que le travail de Simon concerne surtout sur le manque > d'adresses, pas sur la présence des batiments. > > paranoia ? :) > Yves > > > ___ > dev-fr mailing list > dev-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] (sans objet)
Il me semble que le travail de Simon concerne surtout sur le manque d'adresses, pas sur la présence des batiments. paranoia ? :) Yves ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] (sans objet)
Une petite réflexion complémentaire concernant les bâtiments. Adresse ou pas ces bâtiments sont une aide plus que précieuse, je dirai même indispensable pour la plupart des carto-parties OSM grand public. Sachant que les relevés de données sont très souvent en milieu urbain et réalisés sur des supports papiers, si il n'y avait pas déjà les bâtiments sur le papier ce serait impossible de positionner précisément tout ce qui est relevé. Les routes c'est bien gentil mais sur une ligne droite entre deux carrefours pour trouver exactement où on est bon courage... Donc qu'ils arrêtent de nous gonfler à vouloir à tout prix prouver que les bâtiments tout seuls ça ne sert à rien et qu'ils réfléchissent deux secondes avant de raconter n'importe quoi avec leurs adresses ! Oui je râle parce que autant de mauvaise foi ça m'énerve, et puis bon le vendredi c'est permis. ;-) Nicolas ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] (sans objet)
Le 05/04/2013 15:24, Ab_fab a écrit : J'ai l'impression que Simon Poole ne fait pas beaucoup d'efforts pour admettre qu'il n'y a pas QUE des bâtiments du cadastre en France. Surtout il aime bien dire qu'on n'a pas beaucoup d'adresses. J'ai commenté le billet [1] qu'il a fait au sujet de sa carte mettant en evidence les adresses / bâtiments sans adresse, en indiquant que comme il ne tient pas compte des noeuds adresse à proximité des bâtiments (comme souvent avec le cadastre), il passe à côté d'une grosse quantité d'adresses non négligeable en France. Est-ce que sa réponse concernant la lourdeur de l'analyse pour accorder un "rayon d'action" de quelques mètres autour des bâtiments pour aller y chercher un noeud adresse tient vraiment la route ? en particulier si l'on utilise Postgis ? [1] http://www.openstreetmap.org/user/SimonPoole/diary/18866#comments Oui, c'est vraiment lourd, d'autant plus qu'il y a beaucoup de bâtiments. Frédéric. ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] (sans objet)
Le 5 avril 2013 15:24, Ab_fab a écrit : > J'ai l'impression que Simon Poole ne fait pas beaucoup d'efforts pour > admettre qu'il n'y a pas QUE des bâtiments du cadastre en France. > Surtout il aime bien dire qu'on n'a pas beaucoup d'adresses. Je crois que le serpent de mer des adresses est un prétexte chez lui. tenter de justifeir l'inutilité des buildings dans la base en se basant sur des données fausses, et sur un modèle des données pour les adresses qui est encore largement défaillant, et sur des outils comme Nominatim qui ne savent même pâs correctement gérer les adresses dans de nombreux cas (y compris les codes postaux que je viens d'évoquer concernant Nominatim qui a des très sérieux problèmes à leur sujet). Ne devrait justement pas avoir pour effet de bloquer la saisir des bâtiments. D'autant plus que le fait de taguer renseigner les bâtiments ne peut conduire qu'à une amélioration sensible de la qualité et la précisions des noeuds d'adresses saisis (même si pour cette saisie, on ne peut pas s'appuer sur Nominatim pour fournir une géolocalisation suffisante). Simon Poole devrait donc voir qu'on est encore dans une phase transitionnelle (à peine commencée), où pour pouvoir monter une base d'adresses fiable, il va fallori encore beaucoup de travail sur les outils et aussi sur la précision des autres données connexes comme le bâti qui va servir à renseigner la base adresses avec précision. Bref il veut placer l'oeuf avant la poule, ou l'inverse. Comme si on ne pouvait pas, et ne devait pas faire évoluer en fait en parallèle à la fois l'oeuf et la poule... et aussi la poêle antiadhésive pour faire l'omelette sans la crâmer, et le four pour faire rôtir la volaille dodue, et les couteaux et la planche à découper pour préparer les morceaux à servir dans l'assiette. Il est temps de faire comprendre que bâtiments et adresses ne sont pas modélisés de la même façon, et que ce sont plutôt les outils de consultation utilisés pour l'évaluation faire par Simon Poole qui sont défaillants, mais pas les données du bâti elles-mêmes qui servent **déjà** à justement aider à enrichir la base d'adresses avec plus de précision. Les deux types d'informations petit à petit trouvent leur cohérence et s'harmonisent, même si nos outils actuels pour les utiliser sont encore défaillants (mais ils feront d'autant moins d'erreurs que justement on aura augmenté la précision des deux types de données, ce qui permettra justement à ces outils d'évoluer pour faire moins d'erreurs). ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr