Il n’y a rien d’étonnant. Le schéma de tags “public_transport” est assez massivement rejeté par les non-spécialistes du transport public de par sa complexité. La coexistance avec les anciens tags n’est pas prête de s’arrêter.

Oui, je viens de vérifier et il y a effectivement un problème. Ca n’est pas les noms qui ont été supprimé mais quelqu’un qui a changé les tags “railway=station” en ““public_transport=stop_position”. Je viens de poster un message sur la liste de diffusion [email protected] pour voir ce que les autres contributeurs en pense. Amha, il n’aurait pas dû supprimer l’ancien tag. Il faut aussi que nous examinions ses autres interventions sur les autres lignes de métro ainsi que sur le RER et des lignes de bus.

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.

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.

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…

Oui, j’ai oublié de mentionner un point important : je ne traite pas les tags anonymes et les tags signés de la même façon. Cuex qui sont signés permettent un véritable échange. Pour les autres, j’ai laissé quelques remarques mais je n’ai pas encore vu de retours. Je pense que les anonymes ont plus tendance à ne pas revenir. Mais il peut y avoir des exceptions.

Hi Alex,

Thanks for the (small) clarification. And congrats for the nice rendering of OSM map data.

Je n’ai pas les mêmes stats que toi avec mes 50 notes altérés mais je partage le même constat mais pas les mêmes conclusions. Le système doit rester ouvert et le plus facile d’accès possible : il s’adresse à ceux qui veulent améliorer la carte mais qui ne veulent pas entrer dans une démarche qu’ils jugent trop lourde (créer un compte, utiliser un éditeur, même iD) soit par manque de temps, soit par manque de motivation, soit par peur de mal faire. Ce qui sort de cette intention doit être éliminé : les notes personnelles, les commentaires trop vagues ou trop généralistes (“il manque les adresses dans cette ville”). Il faut rappeler qu’il est aussi rapide de fermer une “note” que de la créer. J’ai appris à ne pas perdre de temps avec certaines “notes”. Là où je suis encore dubitatif, c’est celles qui nécessitent une visite sur place. Pourquoi pas. Mais que penser si ces “notes” restent ouvertes pendant des mois, voir plus ? Si l’endroit est peu fréquenté, certaines “notes” pourraient subsister pendant des années. Il faudrait peut-être fixer une date limite au-delà duquel on peut décider de fermer la “note”. C’est peut-être une piste à explorer. Mais en aucun cas, il ne faut ajouter des barrières artificielles à ceux qui voudraient améliorer la carte par ce biais. Mais je suis d’accord qu’il faudrait d’avantage expliquer à quoi sert l’outil (un message avant la première contribution ?). Et qu’il faudrait aussi se mettre d’accord autour d’une politique générale concernant la fermeture des “notes”, par exemple sur une page dédiée dans le wiki.

In Denmark where all addresses are imported

That’s the point. Most of the addresses in OSM are today coming from mass imports. Finally only a few people fixed the convention. And the method is finally less depending on what is the best for OSM but only what is the easiest for the import. More interresting numbers would be to see the amount of contributors adopting one way or the others.

Could you develop the “two sliders via the layers context menu” ? This is something already available in standard JOSM. So what is missing here ?

You seem to ignore the warning about ‘type=collection’ in the wiki: osm.wiki/Relation:collection

For your needs, you could use a simple relation of ‘type=site’: osm.wiki/Relation:site

Pieren

Ach, zut ! Quelqu’un a décha korriger l’erreur !

Follow the link then edit the wiki section (login first)

Je tombe sur ce message par un jeu de billard. Petit rappel : le rôle “inner” n’est pas implicite. Par défaut, c’est le rôle “outer” qui est implicite. Voir le wiki sur les relations multipolygon pour comprendre. Mais de toute façon, un bon logiciel sera capable de retrouver ses petits et de restituer le bon rôle par la géométrie.

Encore un petit effort. Avec JOSM, il est facile d’ajouter en 10mn les rues de ces villages à partir du cadastre. Importer le bâti avant les routes, c’est comme mettre la charue avant les boeufs.

Use “short_name” for the abbreviated version.

Geofabrik hat ein QA Tool fuer Adressen in “OSM Inspector”. Hier zbs:

http://tools.geofabrik.de/osmi/?view=addresses&lon=7.42160&lat=50.42116&zoom=12&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads

You completely miss the point. You suggest that finally, we don’t need the wiki documentation. “usage makes the tags”. But we have to document the tags. And to create new tags for new features, we have to find a consensus and identify possible issues/overlaps. This particular case is a good example in the way that “childcare” and “kindergarten” have different meaning in different countries. If you don’t fix this issue, the OSM data cannot be consumed/interpreted consistently excepted locally. So either we find a common tagging rule which can be used worldwide. Or we identify the differences and document them in the wiki. The “childcare” original proposal redactor failed in this. When the problem was raised during the vote, the redactor should stop the vote and clarify this point in the proposal (how it can overlap with kindergarten and how it can be solved) and then return to a new “vote” (which has to be considered as a “opinion poll” anyway) with more success. What is completely ignored on the “gender” selfcreated discussion is that many proposals fail at a first vote and many redactors are not enough motivated to improve the proposal and return to a new vote. If there is a “gender” controversy in OSM (which is possible), this “childcare” vote failure is not a good example.

I always campaigned against route relations on segments. This is the easy way fine for data consumers but not for contributors (the real ones, not the ones just talking or developing software). My alternative solution is to define the routes by junctions nodes lists. It’s still not perfect but I noticed that junction nodes are relatively more stable than any other elements in the OSM dataset. And it makes routes modeling less prominent.

geowankers, LOL @Pink Duike : of course, I knew the meaning of all these abbreviations before my post. It is just frustrating that I had to look somewhere else before I understood ‘asl’ or ‘ngo’. Probably like many, many other contributors. Tags should be self-explanatory when possible.