J’avais toujours mis les adresses de POIs dans des clés « addr:* » ayant lu sur le wiki en anglais que la proposition de regrouper pleins de clés dans « contact:* » n’avait pas pris et était minoritaire, le fait que ça soit plus simple dans iD aidant aussi.
Je m’apprêtais à ajouter les horaires d’un restaurant quand je me suis aperçu que quelqu’un avait passé les champs « addr:* » en « contact:* » avec comme description « Correction N° de rue en double ».
Ça m’a semblé bizarre puisque les numéros de rue sont définis par une relation et non par une clé uniquement.
J’ai regardé avec pewu et osmhv, et j’ai vu que le changeset était uniquement la translation de toutes les clés possibles (addr:* mais aussi website par exemple) dans « contact:* » alors qu’il me semble être découragé de faire des modifications de ce genre (forcer un style) d’après ce que j’ai lu dans le wiki.
Je suppose que la personne qui a fait ça se base sur cette page du wiki que je n’avais jamais vu avant et sur laquelle j’ai fini par tomber.
Comme je l’ai dit plus haut, j’ai un doute sur la pertinence de ce modèle car d’après ce que je comprends, il n’y a pas de numéro de rue en double du moment que les POIs ne sont pas définis comme numéros de rue dans une relation « associatedStreet » comme « house ».
Je m’interroge donc sur :
la pertinence du modèle « Schéma de Charlieu »
quoi faire par rapport au changeset qui démarré tout ça
Je découvre le « schéma de Charlieu », qui reprend en effet les pratiques qui ont cours au moins en France. Disons que ce sont les pratiques encouragées telles qu’on les trouve dans les discussions entre contributeurs.
Je suis de mon côté plutôt en opposition avec ces pratiques et ce schéma. Je trouve en effet incompréhensible de devoir ranger les mêmes informations d’adresse sous la famille de tags addr:* dan un contexte et sous la famille contact:* dans un autre. On parle d’un même et unique concept d’adresse à chaque fois. La nuance est juste que parfois un objet porte ces informations à défaut d’aucune autre (éventuellement un tag building=* s’il s’agit d’un polygone), et d’autres fois ces infos sont accolées à la description d’un POI : commerce, établissement public, usine, etc.
Quand je dis « incompréhensible » c’est en me mettant à la place d’un novice à qui on expliquerait comment renseigner une adresse. En gros, l’explication commencerait par : « Alors ça dépend… », et rien que pour ça je trouve le schéma contact:* problématique. Il est à mon sens juste source de confusion et de fragmentation.
A la place je suis favorable à :
l’usage du schéma addr:* en toutes occasions, sans exceptions
l’utilisation complémentaire d’un tag, par exemple le tag « addr » (sans sous espace de nommage) auquel on donnerait des valeurs très similaires à celles du tag entrance=*. L’adresse seule (sans POI) hériterait du tag addr=main, les autres seraient à moduler avec addr=shop, addr=parking, addr=school etc. Voici une liste des valeurs de entrance pour l’inspiration sur Taginfo
Pour revenir au cas qui motive ton message, je ne préconise pas de reverter les changesets ayant modifié tes saisies, même si je trouve discutable la manière d’opérer qui consiste à écraser tes edits en fonction d’une pratique locale, sans discussion (si j’ai bien compris).
Pour info, le schéma de Charlieu vient de @CapitaineMoustache et si je me souviens bien, il a fait un sujet sur le forum pour le présenter pour avis.
Retrouvé !
Il n’a pas eu de remarque sur sa proposition.
@vdct, je comprend bien la remarque sur la présentation a un débutant et vu comme cela j’y adhère.
Si je comprends bien ta proposition, tu proposes d’ajouter une sorte d’hiérarchisation plutôt que de modifier le nom de la clé ?
Personnellement j’ai modifié quelques (une dizaine environ) POI pour mettre contact: et c’était quand j’ajoutais les numéros de rue (en passant par pifomètre) et en retenant le schéma de la relation et en harmonisant toute la voie (le côté hybride ne me plait pas trop). Et surtout le POI ayant des informations, je ne voulais pas les perdre, mais je ne voulais pas non plus que JOSM râle en me disant qu’il y a des numéros en double.
Ce sujet mérite donc bien un peu de réflexion partagée pour confronter divers points de vue.
je veux une et une seule géométrie pour représenter mon adresse je sélectionne prioritairement les adresses avec addr=main. Cela implique qu’on ne conserve dans OSM qu’une seule entité avec addr=main pour une valeur d’adresse donnée
je veux la description d’un POI je sélectionne le POI et je récupère via ses tags addr:* ses infos d’adresse, sans avoir à me demander si ce sera dans addr:* ou contact:*
je veux toutes les entités présentes à une adresse donnée je peux les sélectionner simplement sur la foi de la valeur du tag addr:housenumber et, au chox, de la valeur de addr:street ou de l’inclusion dans une relation associatedStreet. C’est déjà en soi une complexité de devoir piocher dans les 2 ensembles (tag addr:street et relation) mais toujours moins complexe que de devoir en plus aller piocher dans des tags supplémentaires contact:*
Je trouve ça plus simple à la fois pour les contributeurs (qui renseignent toujours les mêmes tags pour stocker la même sémantique) et pour les consommateurs (qui ne vont chercher qu’à un seul endroit ce qui relève d’une thématique au lieu de devoir s’éparpiller)
Bonjour !
Tout d’abord, je rappelle que je suis la personne qui a formalisé le Schéma de Charlieu sur le wiki OSM. Je suis heureux de voir toutes ces remarques et propositions et je vais tenter d’y répondre !
@vdct La proposition d’un tag (addr=main) pour hiérarchiser le type d’adresse renseigné est très intéressante mais j’ajoute ceci :
Un tag addr=main est une classification tout à fait abstraite pour un·e novice il me semble, ça relève d’une pure modélisation et c’est pas toujours évident à aborder.
C’est sans doute le point noir : Il n’existe hélas aucune formalisation de cette pratique de hiérarchisation sur le wiki OSM.
Sur les avantages du Schéma de Charlieu :
On peut considérer que renseigner l’adresse d’un POI avec la clé contact: va vers une clarification pour le contributeur puisque ça la range avec les autres infos de contact déjà existantes et employées : contact:phone, contact:website, contact:email…etc… Tout en reprenant d’ailleurs la terminologie de addr: (housenumber, street, postcode, city).
C’est assez transparent il me semble.
Accessoirement, ça facilite la récupération des infos de contact des POI’s, toutes rassemblées sous le préfixe clé contact:.
Ça réserve les clés addr: à la cartographie des adresses en tant qu’objet à part entière, allant dans le sens du principe One feature, one OSM element et permettant une plus grande latitude quant à leur positionnement.
Pour le reste, je suis d’accord sur les avantages qu’apporterait cette hiérarchisation, en matière de contribution et de consommation des données.
En principe justement, ils le sont et c’est un problème ! Dans OSM, tout objet contenant les tags addr: peut être considéré comme adresse. Le fait qu’ils fassent partie d’une relation associatedStreet ou non n’y change rien, j’ajoute que ce type de relation encore très utilisé en France est inusité, inconnu voire déconseillé ailleurs dans le monde, ce qui rend impossible l’identification que vous proposez.
C’est notamment un des problèmes auquel le Schéma de Charlieu essaie de répondre en réservant les tags addr: à la cartographie des adresses en tant qu’éléments à part entière et en proposant d’utiliser le préfixe contact: pour renseigner les adresses des POI’s.
On peut voir la chose autrement : certes, ces informations sont regroupables sous le même concept d’adresse cependant il y a d’une part :
L’adresse en tant qu’objet géolocalisé et identifié (que le Schéma de Charlieu recommande de cartographier avec addr:). C’est celle renseignée par les communes dans les BAL par exemple, elle sert notamment au guidage.
L’adresse rattachée à un POI qui n’est finalement qu’une information attributaire, au même titre qu’un numéro de téléphone ou un site web. (que le Schéma de Charlieu recommande de cartographier avec contact:).
Les limites administratives sont abstraites pour le novice, ça ne les empêche pas de figurer dans OSM. Plus largement, les relations, quel que soit leur type, sont abstraites pour le novice, et OSM regorge de multi-polygones, d’itinéraires de transport en commun, de manoeuvres interdites, etc.
Si on faisait émerger un tag addr=main (ou équivalent), ce serait comme à chaque fois : il aurait sa page de wiki, ses explications et traductions, ses illustrations, tout autant de ressources destinées à le rendre moins voire plus abstrait du tout.
Par ailleurs le tag addr=main (ou équivalent) s’appliquerait par défaut à toutes les adresses présentes en 1 seul exemplaire dans la base, ce qui concerne sûrement 99% des adresses tagguées avec addr:housenumber aujourd’hui. Donc finalement assez peu de questions à se poser pour un novice ajoutant, par exemple, les adresses de sa rue pour commencer. Et pour une contribution plus poussée, il serait assez simple d’imaginer une analyse Osmose détectant :
soit de multiples adresses identiques ayant toutes un tag addr=main => il s’agirait d’en élire une seule et de changer la valeur du tag addr=* pour les autres
soit aucune adresse avec addr=main pour une adresse donnée, et on aurait une suggestion d’ajout de cette adresse, peut-être au milieu de commerces taggués avec addr=shop
Ce n’est pas un point noir, c’est juste qu’on en est à un stade de discussion assez initial, où rien n’est encore formalisé
Je trouve au contraire qu’on embrouille le contributeur en dispersant une même info dans plusieurs schémas de tags. On fragmente, artificiellement à mon avis, donc sans trop de bénéfice, ni pour le contributeur, ni pour le consommateur
Et c’est une très bonne illustration du problème à mon sens : on duplique les sous-tags, ce qui amène de la confusion plutôt que de la transparence à mon avis
Je ne comprends pas ce point sur la latitude de positionnement. La latitude s’appliquerait tout autant à une des adresses, celle taggué avec addr=main, non ?
J’abonde sur absolument chacun des points !
Merci pour ces éclaircissements @vdct, je suis convaincu.
Cette solution est plus simple à mettre en oeuvre, elle enrichit les données adresses sans remettre en cause les méthodes contributives et de consommation classiques.
Du coup, j’ai envie de déclasser rapidement la proposition Schéma de Charlieu et promouvoir la façon addr=main pour éviter une fragmentation galopante !
Comment se coordonner pour créer rapidement un brouillon sur le wiki OSM ?
Je peux m’en occuper éventuellement ! Immédiatement d’ailleurs.
Je ne sais pas si on en est à un tel niveau de bazar Si tu te sens la motivation pour amorcer une page, c’est super ! Et je me ferai un devoir d’y apporter mes billes
Je découvre cette discussion, et je trouve qu’elle illustre bien ledit bazar en effet
Je disais que contact:* était difficile à expliquer à un novice. Ici on a à faire à des contributeurs agguéris et c’est tout aussi difficile en fait.
Ce qui me surprend, c’est que malgré cette complexité, la communauté OSM française a quasiment sans documentation (jusqu’au Schéma de Charlieu depuis l’an dernier) et sans outil simplificateur (rien sur JOSM, iD ou ailleurs) patiemment renseigné à la main près de 37000 POI avec ces clés !
Les alertes des éditeurs y sont sans doute pour quelque chose, les gens (dont moi) ont cherché une alternative pour éviter des addr: doublons !
contact:* restera quand même utile quand l’adresse postale ou envoyer un courrier à un POU n’a aucun rapport avec l’adresse géographique, le cas typique: la boîte postale, l’adresse du siège, du service client (mais pas que)
Oui, c’est l’usage préconisé dans le wiki international. Dans ce cas les tags contact:* viennent en complément des tags addr:*, et (forcément) avec des valeurs distinctes
Le addr:* dupliqué x fois ne me satisfait pas.
C’est pourquoi contact:* m’allait bien, que les valeurs soient distinctes ou pas (elles correspondaient à la page contact du site d’un POI) elles permettaient l’unicité du addr:* comme post:housenumber et post:street le font pour les boîtes aux lettres.
Cela permettait d’éviter ce que j’ai vu assez souvent : un contributeur crée un node addr:* à l’aide Pifomètre&Co à la limite public/privé, un autre contributeur se sert du node pour y ajouter ses infos POI et le déplace à l’intérieur, puis un autre (qui n’utilise ni was: ni vacant:) supprime le node et l’addr:. J’ai même vu un addr: se déplacer dans une autre rue avec le déménagement du POI.
Mais si une autre nouvelle méthode permet de mieux y répondre, pourquoi pas
je sélectionne prioritairement les adresses avec addr=main. Cela implique qu’on ne conserve dans OSM qu’une seule entité avec addr=main pour une valeur d’adresse donnée
Si tu te sens la motivation pour amorcer une page, c’est super ! Et je me ferai un devoir d’y apporter mes billes
