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

[Philippe Verdy]

Le 14 juin 2016 à 19:01, Christian Rogel <christian.rogel at club-internet.fr>
a écrit :

> Le 14 juin 2016 à 16:15, Romain MEHUT <romain.mehut at gmail.com> a écrit :
>
> Bonjour,
>
> Le 13 juin 2016 à 20:19, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>
>
>> Je suis aussi de cet avis. Le doublon n'en est pas vraiment un: ce sont
>> des noeuds différents, proches mais taguant des objets différents ayant
>> *certaines* propriétés communes (dont le numéro de rue associé).
>>
>
> Je suis de l'avis de l'autre Christian soit "*Le principe d'OSM est de ne
> décrire un objet qu'une fois, et c'est une règle générale pas spécifique
> aux adresses.*"
>
>
>> Dans le cas présent, le doublon est en fait le noeud d'adresse "40" vide
>> de tags et PAS les deux deux des POIs distincts des deux commerces qui sont
>> au 40: en effet ce noeud vierge a toutes ses propriétés communes avec les
>> deux autres noeuds. Il ne sert à rien d'autre et n'a pas plus d'autorité
>> que les deux autres, il n'ajoute rien de mieux.
>>
>
> Vide de tag le nœud adresse ? C'est LE nœud de base pour spécifier
> justement l'adresse en question. Partant du constat qu'on ne décrit un
> objet qu'une seule fois, si tu supprimes ce nœud, il te faudrait choisir
> entre les deux POI pour y associer l'adresse... or cela n'a pas plus de
> sens.
>
>
> Malgré l’accord entre vous, je suis convaincu que vous mélangez deux
> objets différents qui ne font jamais des doublons, principalement parce que
> cela vous irrite l’œil de voir côte à côte deux nombres (esprit geek ?).
> En réalité, la création de chaque objet relève d’une logique différente
> qui doit empêcher d’appliquer la règle «  one feature, one tag ».
> Vouloir fusionner les expressions apparemment identiques de deux objets
> est, commme je l’ai dit, une variété de taggage pour le rendu.
>

Le fait est que l'adresse où Romain l'entends est réduite à sa seule
définition communale/cadastrale, du point de vue de son unique propriétaire
(une personne ou une communauté de personnes dans le cas d'une
copropriété). le schéma addr:* n'est pas réduit à seulement cela. Vouloir
éliminer les résidents/locataires est quelquechose que même
l'administration fiscale ne fait pas. Sinon il n'y aurait que les taxes
foncières, pas les taxes locatives et autres taxes communales à la charge
non du propriétaire mais du/des résident(s).

Et ce n'est d'ailleurs pas spécifiquement français, partout dans le monde
il y a des adresses partagées *en partie* par leurs occupants: si on place
le curseur de l'unicité sur le seul numéro dans une rue on oublie
totalement les résidents et dans ce cas on peut oublier une bonne partie du
schéma addr:*

De plus la pseudo-solution qui consiste à surcharger "contact:housebumber"
n'a jamais été documentée ou approuvée. On la découvre par hasard mais
c'est undétournement de la fonction qui crée une nouvelle ambiguïté. le
schéma contact:* a justement été fait pour mentionner des infos qui ne sont
pas directement liées à la position géographique de l'objet qui est annoté
de cette façon: les numéros de téléphones sont portables, comme les email,
comme les adresses de facturation; dans le commerce et les entrerprises en
général il est extrèmement courant qu'un établissement ne soit pas
contactable sur place mais dans un autre établissement, voire même dans une
autre société, même pas nécessairement dans le même pays.

Il faut revenir au schéma addr:* tel qu'il est standardisé. Si le doublon
de valeurs vous choque à cause de BANO créez un objet ad hoc pour les
housenumber, tout en étant conscient que les adresses BANO de cette façon
ne peuvent représenter de façon correcte les adresses exactes des occupants.

Ces adresses sont insuffisantes, il manque des détails: batiment, escalier
,étage, porte, nom de l'occupant réel, et la géométrie du noeud est tout
aussi insuffisante, quelle que soit la précision de placement de ce noeud
totalement virtuel qui ne correspond en rien à ce que connait le cadastre
ou la commune, sa position étant en fait dans OSM étant en fait totalement
arbitraire: l'adresse réelle c'est une surface délimitée (pas un noeud dans
cette surface et encore moins en bordure ce cette surface sur une ligne
mitoyenne avec la voirie publique, une ligne qui n'est en fait même pas
tracée dans OSM puisqu'on n'a pas inclus le découpage parcellaire, et
qu'une adresse se compose souvent de plusieurs parcelles réunies pour des
raisons historiques !)

Ajoutez à ça que la numérotation des rues peut avoir des trous très
irréguliers (notammeent dans les communes à numérotation métrique), on voit
bien qu'on ne peut rien déduire de l'adresse d'un occupant en cherchant un
noeud d'adresse proche: on a toutes les chances de se planter de numéro !
Admettons que ce numéro serve au repérage, c'est alors juste une
alternative aux coordonnées géographiques mais ça n'indique rien de précis
autour. On n'a rien pour réunir des objets proches et aucun critère fiable
pour déterminer le numéro si ce numéro n'est pas porté ou par chacun des
objets qui l'ont en partage ou s'il n'existe aucune relation pour les
réunir de façon fiable. sur ce seul critère partiel (partiel car il n'est
pas suffisant poru déterminer l'adresse complète d'un occupant)

BANO restera à jamais un gruyère qui n'occupe que des trous microscopiques,
toute la matière réelle est autour des trous et on n'a pas le couteau pour
faire les parts entre ces trous !
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160614/593e1e82/attachment.htm>