Tips depend on what you are mapping.

• I tried fastdraw and found it worse than stargitforward add or using improve way accuracy on a big line.
• For houses I use extrude all the time, it is faster than tracing the outline and orthogonalyzing at the end
• For lakes there are tracing plugins, but it’s only worth your while if you have homogenous imagery and many things to trace.
• I typically trace 10-50 elements in a row without adding any tags, and then use the search dialog to select them and tag them all in one go. That leads to tracing objects by type instead of by area.
• Some other tools you should try if you didn’t yet: terracer, contour merge, merge overlap, replace geometry
• I use the download continuously plugin all the time after the initial download. I have it off by default (I quickly toggle it when I need some data somewhere), and I have tweaked it to download with a generous margin but only at high zooms.
• I use a trackball (that one) which I find greatly superior to mice: just as precise/fast if not better, no need for a “proper surface” of any kind, doesn’t induce RSI in my wrist, and a single AA battery lasts years.

The usual counter-argument to “wait until edits are made to allow potentialy spamy features” is that spamers will end up automatically doing an edit to unlock the features… Which would be even more damaging to OSM.

One thing I would like to see is deleting contribution-less accounts after a while (say 6 months), automatically and with a notification message. It’s not as good a spam filter, but it should avoid the arms race.

The other avenue of work, as Tordanik suggests, is to make it easyer for any contributor to flag bad accounts / contributions. Maybe the admins will need to recruit more spam-deleters/; I’m sure they’ll let us know if they get overworked.

Kudos to the JOSM devs. Keep it up :)

@kucai You can pre-load an area by moving around, and then untick “auto-load tiles” when you go offiline. I suspect that any script to do this automatically would violate Bing’s usage policy.

The tool that a_peter describes requires the “measurement” plugin. Install it by going to edit -> preferences -> plugins.

We’ll only get more spamers as osm gets more popular. We just need to keep improving the tools to fight it, such as new contributor tracking, changeset analyzers, and reverting tools. Otherwise it’ll burn through spamfighters’ energy.

I may be wrong here, but I assume the contributor base will grow faster than the spamer base. We’ve seen a recent spurt of spam, but give the community some time to react.

Obligatory xkcd quote

There are different levels of unwanted contributions in osm:

1. Outright spam like that search engine example.
2. Spam within a proper contribution, like adding a shop’s sales pitch in the note tag.
3. Grey areas, like a buisiness on the map where at most a letterbox is to be found.
4. Newbee mistakes and accidental vandalism, like deleting stuff to fit a one-time use
5. Normal errors, like bad tagging
6. Actual vandalism, like doodling on the map or puting a joke name on an actual feature
7. Edit wars on politically-disputed land

Each of those should be handled a bit differently, but the tools to handle them are probably the same (except perhaps 5 and 7).

Champagne !

Welcome back, hope you like the progress made in two years :)

Well done, one often forgets the power of the changesets manager.

Not scaring new contributors away with a “you’re doing it wrong” message is very important. Some rules of thumb I use :

• Be welcoming, thankfull, jovial.
• Dont blame; label even attrocious mistakes as “things you could improve”.
• Offer to help or explain further, and talk about alternate help sources (this link).
• Fix the badly damaged or hard to correct bits yourself.
• Explain (with wiki links if applicable) how to fix the rest (and fix it yourself after a week or two if there’s no reaction).
• Finish on a “happy mapping” good-bye note.

Concerning those particular Aldi notes, even if the text was taken from the Aldi website, there’s no reason to think that a Google map (or other copyrighted source) wa used to place the notes (unless the osm map is really bare in the area ?). If you could place those notes yourself by reading the text on the Aldi website, then those notes are fair game.

That last sentence is, in effect, independant verification. You might wonder what the advantage of such notes are if you need to redo all the detective work by yourself, but they actually provide 1) a hint of what to look for and what users are interested in 2) a feedback link to users who aren’t full contributors but will see that OSM contributors are areactive, and spread the word.

Hum, autant pour moi, j’ai du me faire avoir par le cache, le rendu par défaut n’affiche plus les stations.

Cela m’étonne que ce rendu ne gère pas le nom sur les public_transport=stop_position. Peut-être le ferait-il pour les stations, mais celle-cis ne sont pas mappées sur Paris. À voir si on veut poster un bug de style, ou rajouter l’ancien tag pour garder la compatibilité avec les vieux outils.

Sur quel rendu ? Sur le rendu par défaut ça a l’air correct.

Si problème il y a, il viens sans de ce changeset. Le seul truc qui pose peut-être problème est la suppression de railway=station, mais le reste a l’air de suivre le schema public_transport donc je n’ai pas l’impression qu’il y ai un bug.

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 :)