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.

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.

• “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.

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

Is there any relation type or tool that makes use of relation member’s order ? To me this has always been purely cosmetic, helping humans find gaps for example, but otherwise useless ?

Repository url would be useful :p

Nice howto, thanks :)

Raté mon lien vers la pépite, celui-ci est mieux. Je finirai sans doute par m’en occuper, mais n’hésitez pas à me devancer :p

Pour “faire bouger github” le mieux est d’envoyer un patch :p

Quand il manque des infos, qu’il n’y a pas de dialogue, que la note est vielle, alors oui autant fermer. Mais il faut se mettre d’accord sur les limites acceptables (lesquelles, pour ne froisser personne, seront généreuses).

Notez que pour qu’il y ai un dialogue, il est important de commenter peu de temps après l’ouverture de la note (c’est encore plus important dans le cas des anonymes). Abonnez-vous au flux rss des notes de votre région, voire gardez un oeuil sur IRC.

Pour les notes trop vagues je suis moins catégorique : j’ai récement corrigé des “il manque beaucoup de rues ici” qui trainaient sur OSB depuis 1-2 ans. Entre-temps, l’imagerie Bing est arrivée pour la zone en question, ce qui m’ a permi de faire la modif à distance. Le bug était vieux, vague, non commenté, anonyme, mais il était utile (difficile de repérer un quartier mal mappé dans une grande ville) !

En résumé, il y a pas mal de choses à faire pour améliorer le rapport signal/bruit d’OSN, mais le bruit sera toujours important, du fait de la population ciblée. De quoi mieux filter, de quoi guider les ouvreurs de notes, de la doc wiki… Affaire à suivre :)

Ce serais dommage de passer à coté de pépites de bon signal comme celle-ci :)

Ça dépend sans doute des régions, mais les notes qui permettent un interction posteur/correcteur (l’idée dórigine des notes) ne sont pas si rares que ça. On les trouve peut-être moins facilement car elles ont tendance à être corrigées plus vite, mais c’est une bonne chose.

Les notes “pense-bête” sont assez répandues et il n’y a pas de mal à ça, mais à condition d’inclure suffisament d’info pour qu’un autre contributeur puisse faire la manip à votre place au cas où.

À mon avis les notes purement personnelles (même dans un cadre “contibution OSM”) n’ont pas vraiment leur place dans la bdd. Utilisez un autre outil.

Perso, en mode Yaka, les deux fonctionalités que je voudrais seraient un filtrage par date et la possiblité d’indiquer qu’une note a besoin de plus d’info. Ça permetrais de filtrer les nombreux cas ou on ne peut rien faire sans aller sur place ou sans que le noteur réponde à la question.

How does that map (coverage of geolocation-via-cell-towers database) help you find stuff to map ? Are you adding cell towers to OSM ?

Many thanks. I tried to write an ad-hoc gpx-display plugin for Blogger a couple of years ago and gave up after much frustration.

I realistically won’t have time to look at it again for a while, but please put Blogger on your radar of interesting targets (and savour the irony of a Google platform getting OSM support before GM support).

Firstly, just looking at your numbers, I reach the different conclusion that most housenumbers are not tagged on the building way, since “Address nodes that are not on or within a building” is the most freqent case. One can slice and regroup the numbers in various ways, but that case still seems predominant.

The difference in interpretation probably come from your “where possible” wording. But an address node that isn’t on or inside a building doesn’t necessarily mean that the building wasn’t there and therefore impossible to tag directly. One popular convention is to put the address node on the letterbox, and that physical letterbox is often not on the building. Annoyingly, it seems hard to distinguish that case from the “no building way mapped” case.

Secondly, there’ll never be a one size fits all because, the real-world concept of a “housenumber” has various meanings, even before we try to convert it into OSM objects :

• Where snailmail gets delivered (aka the letterbox - a node on the building or outside somewhere)
• Where people knock on the door to visit (aka the main/back door - a node on the building shared with “entrance”=*)
• Where I live (aka the building, or just part of a building - tag the building proper)
• The whole property (including garden, depencencies, etc - an osm way enclosing the whole site)

For native English speakers, watch out for the fact that other languages (such as French) don’t necessarily include the word “house” to describe the concept of a housenumber, so the linguistic bias is different.

None of these real-world meanings are wrong. In fact, they coexist, which is usually solved in OSM by using a relation. I’ve never seen a type=address relation with letterbox/entrance/property/living_space member roles (I haven’t searched), but it would make pedantic sense. It wouldn’t make practical sense however, so instead we see a single one of the meanings adopted seemingly at random, but hopefully in accordance with local mapping conventions.

Pour répondre à la question “est-ce que je peux charger mon véhicule ici ?”, l’important n’est pas “bike/car/etc=yes/no” mais “operator=”, qui informe sur la compatibilité et l’abonnement. Le type de prise (socket:=N) ainsi que “voltage/amperage=*” peuvent aussi s’avérer utile (l’ampérage en particulier indique s’il s’agit d’une borne rapide ou non).

Il y a encore pas mal de flottement sur la manière de tagger ces bornes. Il peut être interessant de regarder des exemples sur overpass. L’ancien tag (fuel:electricity=yes) ne permet pas de donner assez de détails.

I’ll try to close all OSB in my area (Ireland), it’s not too overwhelming. If the bug cannot be armchair-fixed, I’ll just convert it to a note.

It would be great to have a one-click way to “convert” individual OSBs to notes. We didn’t want to bulk-import them, but now that OSB is disabling creation of new bugs, an easy review-one-and-import workflow would make sense.

Bien joué et bon courage :) Tu peux t’abonner au flux rss de tes erreurs, mais comme elles apparaissent comme “nouvelles” à chaque passage de la moulinette ça peut être chiant.

Ça m’a fait bizarre au début de voir des erreurs qui ne sont pas de mon fait arriver dans ma liste; il a fallut que j’ajuste ma définition de ce que contenait la liste. C’est aussi un peu chiant d’avoir des erreurs qui nécessitent une observation sur le terrain alors que je ne faisait qu’une petite correction à distance.

Actually, most GPS handsets do that, but there’s normally an option somewhere to disable the behaviour (because it can be a hinderance even outside of mapping activities).

I’d normally be surprised if the opt-out wasn’t available, but as this is Apple I’m not o sure.

That map really is amazing, there really is somthing to say about 2.5D and cartoon-like graphics for readability. The full-3D osm projects are great, but they somehow manage to be more toy-like than this. Another case of beautiful Vs usable.

I’d love to see an OSM version of that, but we are far from having enough data. OTOH, it seems that very few (if any) buildings in your example have been rendered directly from GIS data : the work is done by an artist each time. We could certainly achieve something close by using a few flexible renderable models and some artistic liberties.

For the record if somebody is reading this : the problematic changesets have been reverted, thanks Mackerski.

Welcome to OSM !

But : copying from copyrighted maps is a No-No for OSM. Even for “factual” things like the name of a street, we are required to avoid copryrighted sources, for legal reasons and because we want osm data to be freely redistributable.

The local map that you got is very probably copyrighted by the Ordinance Survey Ireland, which makes it unsuitable for OSM. When you are not sure about the licence of a data source, it is best to assume the source isn’t usable.

I’m sorry but anything that you maped and isn’t known from a proper source (such as your survey notes, holiday photos, Bing imagery, or GSGS out-of-copyright maps will need to be reverted. Please have a look through your changesets with a critical eye.

If you need help (to revert a changeset or something else), pop over #osm-ie on irc.