OpenStreetMap

Pieren's Diary

Relation "associatedStreet" ou tag "addr:street" sur chaque adresse ?

Posted by Pieren on 14 November 2013 in French (Français).

Pour lier un numéro d’adresse avec sa rue, il existe deux modèles qui co-existent dans OSM: soit le nom de la rue est répété avec chaque adresse, qu’elle soit mise sur un noeud, un way fermé (souvent un “building”) ou une relation (par exemple une relation de type “site” ou “multipolygon”) en ajoutant le tag “addr:street” au tag “addr:housenumber”; soit on crée une relation de type “associatedStreet” et chaque élément portant un numéro (dans un noeud ou un way, plus rarement une autre relation) est ajouté dans la relation avec un role “house” et on associe la rue en ajoutant au moins un way de celle-ci avec le role “street”.

J’ai voulu voir s’il était possible de calculer l’usage de ces deux méthodes en France et de les comparer avec leur équivalent dans le monde entier uniquement avec l’outil taginfo. Les statistiques pour la France viennent du serveur taginfo.openstreetmap.fr alors que ceux pour le monde viennent du serveur taginfo.openstreetmap.org . Je ne connais pas les détails de l’installation sur osm.fr mais on peut penser que les données collectées débordent légèrement du cadre strict des frontières. On considérera cependant que les écarts que cela implique peuvent être faibles et négligés dans la petite étude suivante.

Il se trouve que l’outil taginfo construit ses statistiques d’usage différement entre tags sur éléments et “roles” sur relations. Il faut donc faire attention à bien distinguer les deux.

On commence avec taginfo France. Le tag “type=associatedStreet” s’y trouve ~48.000 fois sur des relations. Mais attention, une relation peut couvrir plusieurs adresses. Pour savoir ce que cela représente en nombre d’adresses individuelles, il faut aller sur la page comptant le nombre de roles “house”. On en décompte alors ~833.000 ce qui représente une moyenne de 17 adresses par relation, chiffre tout à fait plausible.

Pour connaitre ensuite le nombre d’adresses qui ne sont pas identifiées par une relation, il suffit de chercher le nombre d’éléments utiliisant le tag “addr:street”, soit ~760.000

Résumé du match en France : 833.000 adresses en relations “associatedStreet” contre 760.000 tagguées avec “addr:street”.

Si on applique les mêmes requêtes dans taginfo pour le monde, on obtient les résultats suivants: 2.100.000 adresses en relations “associatedStreet” contre 23.090.000 tagguées avec “addr:street”.

Conclusion :
- 40% des adresses tagguées avec la relation “associatedStreet” dans le monde le sont en France (833m/2100m).
- en France, on est à peu près à 50-50 entre les deux méthodes avec un léger avantage pour la relation.
- sur l’ensemble du monde, les relations “associatedStreet” ne représentent que 9% des adresses modélisées (2.1M/23M).

Biais : cette méthode a ses limites et ne tient pas compte de certains facteurs qui peuvent altérer les résultats. Par exemple, il arrive que certaines adresses soient tagguées avec les deux méthodes simultanément.

Discussion

Comment from Vincent de Phily on 14 November 2013 at 17:13

Stats interessantes, merci :)

Perso les premières addresses que j’ai taggées l’étaient avec addr:street car ça paraissait plus simple. Puis j’ai réalisé qu’utiliser des relations avait de nombreux avantages :

  • Prend moins de temps à créer (en tous cas avec josm/vespucci; je n’ai pas essayé iD/potlach).
  • Prend moins de temps à maintenir (pas de bitrot si la rue change de nom).
  • Évite la confusion quand une rue est représentée par plusieur chemins osm.
  • Est plus facile à utiliser algorythmiquement (je peux me tromper / ça dépend peut-être).
  • Prend probablement moins de place en bdd.

Avec un peu de chance, la communauté OSM finira par faire le même cheminement de pensée que moi :p

Comment from Pieren on 14 November 2013 at 17:41

Mon billet ne s’intéressait pas aux avantages et inconvénients de chaque méthode. J’en ai déjà parlé sur la liste de diffusion talk-fr. Mais pour contre-balancer les avantages cités, je peux avancer ceci:

  • “moins de temps à créer “ : faux. Ou alors, ça doit dépendre des outils parce qu’avec JOSM, si on n’a pas le plugin cadastre-fr, c’est la galère et la méthode “relation” est plus longue car elle nécessite plus de manipulations (ne serait-ce que pour ajouter une adresse à une relation existante).
  • “moins de temps à maintenir si la rue change de nom” : c’est l’argument principal. Mais honnêtement, en 6 années d’OSM, je n’ai jamais changé le nom d’une rue. Par contre, j’ai corrigé beaucoup d’erreurs de typo, qui parfois étaient reproduites dans les adresses (quel que soit la méthode employée). Ben oui, même avec la méthode “associatedStreet”, le nom se retrouve dupliqué dans la relation avec le tag “name” (ce qui peut créer certaines incohérences, soit dit en passant, comme avec l’autre méthode).
  • “évite la confusion” : là, je comprends pas trop. Ce que je sais, c’est que la méthode relation a aussi des inconvénients : certains ajoutent plusieurs ways en “street” alors qu’un seul devrait suffire. Il y a aussi ceux qui font plusieurs relations par rue. Il y a aussi les ways de rues qui commencent à faire partie de 4,5, voir plus, relations différentes (bus, vélo, street, boundary, etc) et ça devient franchement illisible.
  • “plus facile à utiliser algorythmiquement” : euh, pas vraiment. La méthode du tag “addr:street” est directe et la plus rapide. On n’est pas obligé de faire une passe sur les éléments de type relation. On évite aussi l’écueil d’avoir des relations de relations qui ne sont gérées par aucun logiciel actuel (ça arrive si l’adresse est sur une relation multipolygon ou de type “site”).
  • “moins de place en bdd” : mouais. Il faut arrêter de tagguer chaque arbre alors ;-) Ceux qui adoptent cette méthode devraient aussi s’intéresser aux polygones “building=yes” qui font 2 mètres carrés ou 50 nodes pour un arc de cercle. C’est fréquent dans les imports du bâti cadastral mais bien peu de contributeurs font les simplifications nécessaires. Il y a là un gain beaucoup plus important de place dans la bdd. On sait aussi que cet argument est rejeté par ceux qui ne voient aucun problème à répéter à l’infini le tag “source=blablabla” sur chaque élément…

Comment from EddieJ on 14 November 2013 at 18:35

Et la plus marginale : Relation:street…

http://wiki.openstreetmap.org/wiki/FR:Relation:street

(page traduite récemment)

Comment from JBacc1 on 15 November 2013 at 10:08

Argh, sans commentaire pour la relation street… (la version anglaise serait pas une proposition, des fois ? Elle n’en a pas la forme mais est décrite comme telle, et cela pourrait être mis en avant sur la version française…).

Non, surtout merci pour ces stats. L’intégration d’Opendata sous la forme de relation est surement pour beaucoup dans ces résultats.

Et la dernière division non présentée (mais hors sujet) : 6.3% des adresses sont françaises !

Comment from Vincent de Phily on 15 November 2013 at 10:16

  • “moins de temps à créer” : C’est vrai que quand on tag tout d’un coup ça prend plus de clics pour une relation. Je penssait à un ajout petit à petit au gré des reconnaissances, qui pour addr:street impose de retaper le nom de la rue à chaque fois. Et à vespucci (je j’utilise lors de mes reconnaissances), il est beaucoup plus facile d’ajouter des membres à une relation que de sélectioner plein de ways pour les tagger ensemble. J’en conclue donc “ça dépend” :p Mais dans l’ensemble la différence n’est pas bien grande.
  • changement de nom ou typo c’est pareil non ? Et si le nom est à un seul endroit, pas de risque d’avoir en typo dans 1 des 40 endroits ou le nom est répété pour addr:street. Quant au nom de la relation, il est optionel et pas nécessairement identique au nom de la rue. Comme il sert juste à simplifier l’édition, ça m’arrive de l’abbréger (en virant “rue” par exemple) et/ou de rajouter des infos (nord/sud/etc).
  • “éviter la confusion” je pense aux “housing estates” à l’anglaise qui ont plein de way parrallèles avec une seule rangée de maisons entre. La relation permet de dire sur laquelle de ces paralleles est le numéro X.
  • Pour la facilité d’algo, je penssait au fait qu’avec addr:street il fallait ajouter une heuristique sur la distance pour trouver qui va avec qui. Moins précis mais peut-être plus rapide et plus simple. Mais bon, je n’ai rien codé donc je me trompe sans doutes.
  • Pour le “moins de place en bdd” c’est une cerise sur le gateau, pas hyper interessante en soi.
  • Avantage de la relation que j’avait oublié: on peut la créer avant de connaitre le nom de la rue, ce qui est souvent utile. Facilite la contribution d’un débutant local qui n’a qu’àn nomer la rue.

Comment from Pieren on 15 November 2013 at 11:07

Aie:

changement de nom ou typo c’est pareil non ? Et si le nom est à un seul endroit, pas de risque d’avoir en typo dans 1 des 40 endroits ou le nom est répété pour addr:street. Quant au nom de la relation, il est optionel et pas nécessairement identique au nom de la rue. Comme il sert juste à simplifier l’édition, ça m’arrive de l’abbréger (en virant “rue” par exemple) et/ou de rajouter des infos (nord/sud/etc).

C’est terrible si le nom est différent ! Des outils de controle qualité pourraient considérer que c’est une erreur. Le nom devrait être 100% identique sinon c’est la porte ouverte à toutes les interprétations.
Sinon, un changement de nom n’est pas identique à une correction de typo. Le premier ne se fait que si ça change dans le monde réel. Le deuxième corrige une erreur et ne change plus par la suite.

Comment from Larry0ua on 15 November 2013 at 11:16

If you are using associatedStreet with Josm, try RelToolbox plugin - well, it is great for multipolygons and border stuff, but will significantly decrease clicks number when adding new relation or adding house to existing one. Also it has internal validations like street way with wrong name was included to the relation, incorrect roles and some others.

Comment from Vincent de Phily on 15 November 2013 at 14:08

Le name=* d’une relation associatedstreet est optionel. Il n’a pas d’interêt pour les outils de controle qualité ou autres puisque c’est le name=* du membre street qui compte (on appelle ça une bdd normalisée :p). La seule utilité du name sur la relation, c’est d’aider un humain à choisir la bonne relation dans la liste. Et quand il y a plein de relations dans un même coin pour une même rue, c’est bien pratique d’avoir des name différents pour chacun (par exemple “Rue Tartampion Nord-est”). Mandater que le name de la relation et celui du membre soient égaux est une fausse bonne idée.

Pour la différence typo/changement, on est d’accord sur la différence sémantique. Mais la manipulation à faire dans OSM (et probablement sa fréquence) est la même.

Pour l’algo, le wiki mentione (oui, je sais que c’est à prendre avec des pincettes) “more easy and less error-prone to evaluate” ainsi que “much slower to parse”. Les deux sont à considérer.

Comment from Pieren on 15 November 2013 at 14:28

La seule utilité du name sur la relation, c’est d’aider un humain à choisir la bonne relation dans la liste.

C’est le plus important, non ? Comme on n’est pas des machines, c’est les données qui s’adaptent aux humains et pas l’inverse. C’est pourquoi le tag name est finalement aussi souvent ajouté par les contributeurs, sinon on se retrouve, comme dans JOSM, avec des listes de relations dont on sait pas qui fait quoi. C’est donc une option quasi obligatoire pour les humains mais optionnel pour les machines. Différiencer le tag name n’apporte que de la confusion et n’est pas un conseil à suivre ni à donner.

Comment from Vincent de Phily on 15 November 2013 at 17:50

Bizarre, on est d’accord sur le principe de base (celui que tu as cité) mais pas sur la conclusion. Peut-être qu’on n’utilise pas les relations de la même manière ? As-tu déja eu besoin d’utiliser plusieur relations pour une même rue ?

  • S’il n’y a qu’une seule relation par rue alors oui, je ne vois pas de raison d’avoir un name différent. Avoir un name identique aide.
  • S’il y a plusieur relations (utile quand une “rue” est composée de plein de segments non alignés), alors voir 10 “Rue Machin” dans la liste des relations ne m’avance pas à grand-chose. En tant qu’humain, il est préférable de voir “Rue Machin Nord”, “Rue Machin Ouest 1”, “Rue Machin Ouest 2”, etc.

Au passage, quand le name de la relation est identique à celui de la rue, j’aimerais bien ne pas avoir à perdre de temps (et de ressources) en ajoutant un name. Si l’éditeur affichait le name de la rue membre quand la relation elle-même n’a pas de membre, on n’aurais pas besoin d’ajouter un name à la relation dans la pluspart des cas.

Log in to leave a comment