[OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Philippe Verdy]

L'ennui c'est que les adresses ne se limitent pas seulemetn à un
housenumber (notion liée à la propriété cadastrale, formée sur une ou
plusieurs parcelles). Elle est même insuffisante puisqu'à cette notion de
propriété vient se greffer celle de résidents/locataires (qui ont aussi une
existence fiscale, mais non cadastrale) : ils ont aussi leurs adresses
toutes aussi importantes, et quand le housenumber ne suffit plus, on doit
rentrer dans plus de détails : numéo ou nom de bâtiment, étage, numéro de
porte... (des propriétés aussi importantes du schéma addr:*).

Je crois qu'ici on est trop obnubilé par vouloir une base BANO "propre" ne
tenant qu'à établir une liste des propriétés et ignorer totalement ceux qui
les occupent (résidents/locataires).

A vouloir utiliser contact:* pour lever les ambiguités, on a détourné la
finalité de contact:* et crée de nouvelles ambiguités (ou impossibilités de
codification).

Si vous voulez absolument un housenumber unique pour faire plaisir à BANO
(j'appelle ça taguer pour le rendu, ici les rendus et analyses BANO  !) je
ne vois pas comment procéder autrement que de créer des relations
associatedHousenumber pour pouvoir y rattacher les *différents* objets
distincts qui y sont rattachés (les résidents/locataires, et dans le cas
présent les commerces).

Faut de quoi (sans relation), renseigner addr:housenumber est parfairtement
propre (et tant pis si l'analyse BANO "gueule" sur de speudo-doublons:
c'est l'analyse BANO qu'il faudra corriger si elle ne sait pas tenir compte
de la réalité.

En attendant, un simple noeud pour BANO ne décrit pas correctement
l'adresse puisqu'il n'a aucune géométrie suffisante, il a une surface nulle
et le reste n'est qu'une approximation (il n'y a rien de solide pour
rattacher ce qui voisine ce noeud à la même adresse, et on le voit bien
ici: un numéro 40 sera en fait placé à mi-chemin entre le noeud 40 et le
noeud 44, et ce n'est pourtant pas le 42 !  On a le même problème aux
angles de rues. On a aussi le problème pour rattacher une même résidence à
plusieurs numéros d'adresse (parfois sur deux rues différentes).

Bref c'est bancale, et je suis contre le fait de surcharger contact:* pour
tenter maladroitement de contourner le problème des analyses BANO. Le but
n'est pas pour nous de dégommer systématiquement tous les signalements BANO
en faisant de façon aussi "dégueu" (et aussi insuffisante, peu précise et
toujours aussi ambiguë au final).




Le 14 juin 2016 à 16:52, Tony Emery <tony.emery at yahoo.fr> a écrit :

> Si on part du principe d'écarter la notion d'adresse postale (on laisse ça
> à
> La Poste), il faut définir les enjeux de l'adresse physique pour savoir
> comment on la décrit.
>
> On a dit que, pour les adresses des commerces, on utilise les tags
> contact:xxx. Quant à la description des plaques des noms des rues et des
> numéros d'adresse mais, en soit, cela n'a pas beaucoup d'utilité.
>
> Par contre, la notion d'adresse physique pour la navigation routière, le
> déplacement des services d'urgence, le dénombrement des logements,...
>
> De fait, si une adresse dessert plusieurs bâtiments physiquement séparés,
> cela ne me semble pas incohérent d'attribuer à chaque bâtiment  (Exemple)
> <http://www.openstreetmap.org/relation/187038#map=19/44.15182/4.79818>  .
>
>
>
> -----
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Bonnes-et-moins-bonnes-visibilites-OSM-tp5875216p5875494.html
> Sent from the France mailing list archive at Nabble.com.
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160614/4e038cbe/attachment.htm>