Vaste question les adresses ! Précisons le sujet, je parlerai ici de la façon de les ajouter seulement en termes de
tags, et pas de la façon de les placer géographiquement (parce que c'est un gros pavé ça aussi !
).
Je vais essayer de résumer très humblement ce que je sais, en résumé, il existe deux sortes de méthodes à ma connaissance :
- Sans relation, avec les tags addr:. Ici, c'est assez clair, on met tout sur la géométrie de chaque adresse et on répète, point. C'est la solution la plus utilisée au niveau mondial.
- Avec relations, où sont réunies les informations répétitives (comme les noms de rues), il y en a deux connues principalement :
- La relation associatedStreet, relation spécifiquement dédiée aux adresses, autrefois plébiscitée à présent parfois déconseillée et même bannie (voir Allemagne et Pologne, je sais que cette dernière les supprime au profit des tags addr: sans relation !) néanmoins toujours très privilégiée en France. En tout cas, de très vifs débats autour de cette relation pourtant encore fonctionnelle (plus de 300 000 relations encore à ce jour).
- La relation Street, plus large car elle permet d'associer tout ce qui est utile de relier à des voies, comme des trottoirs par exemple (utile pour le routage d'associer trottoir et nom de voie quand même !). Plutôt bien construite et approuvée par la communauté (bien que pas par la procédure formelle, selon la page française), elle n'est pas en revanche encore très populaire (22 000 relations environ à ce jour) et il semblerait qu'elle ne soit pas supportée par certaines applications, selon la page anglaise.
Alors que choisir ?
Toutes sont de bonnes solutions, avec leurs avantages et inconvénients.
Je dirais que pour le contributeur, on souhaite que sa donnée soit la plus utile et réutilisable possible, d'où le souci d'une certaine uniformité pour éviter de trop complexes extractions aux applications s'il y a plusieurs manières de faire.
En règle générale, je conseillerais de regarder ce qui se fait autour de soi et s'adapter.
Pour ma part, mon choix se construit ainsi :
En France, la solution
relation associatedStreet semble prévaloir et ne pose aucun problème à la plupart des applications il me semble (sans les connaître toutes, mais par exemple l'application OsmAnd gère ça sans problème).
=> En gros, c'est ce qui se fait autour de moi, ça fonctionne, c'est reconnu, donc, j'adhère !
Cependant, il n'est nullement gênant je trouve d'utiliser la solution addr: sans relation, c'est souvent plus facile pour les contributeurs débutants et rien n'empêche après qu'un contributeur plus avancé harmonise tout ça dans une relation... ou pas ! Il m'arrive parfois d'utiliser cette méthode lorsque j'ajoute un nœud par-ci par là et que je n'ai pas envie d'établir une relation.
Et au-delà, j'apprécierais d'utiliser la relation Street que je trouve plus complète si j'étais assuré qu'elle soit convenablement reconnue.
Edit : j’oubliais la question de
la différentiation entre une adresse à part entière, censée être unique et les adresses de contact.
Un exemple récurant pour illustrer : le cas d'un immeuble de ville avec commerce en rez-de-chaussée et habitations aux étages. Que faire ? Mettre un nœud avec tags addr: à l'entrée des résidents et remettre ces tags sur le POI du commerce créant par là un doublon ?
Là-dessus, une méthode semble émerger de plus en plus (surtout en France en fait d'après
Taginfo, c'est le schéma de Bremen, une proposition permettant entre autres buts d'éviter les doublons adresses en créant une préfixe contact: pour renseigner toutes les infos de
contact (l'adresse comprise) des commerces et autres établissements.
Je trouve ça très malin et je l'utilise systématiquement sur les POI
"
contact:housenumber" et "
contact:street" suffisent généralement.
Qwant Maps par exemple en prend compte sur ses fenêtres pop-ups des POI, ou encore,
CartoVrac.
Je reviendrai sur la question BANO dans un autre billet, si j'ai le courage ! Il faut que je m'y replonge
