@BushmanK : your last post is spot-on !

This problem is that the current policy of the osm.org website is to remove as many “barriers” before contributing so that people that only want or can dedicate a few minutes to mapping can add something to the map, even if that “something” is sub-par mapping or worse, as they didn’t read any documentation.

You can’t remove all barriers before starting to map and expect novices with little to any OSM experience to map quality map features. So it is an intentional policy to gain as many mappers as possible, while giving the burden of QA to more experienced and more available mappers.

I wonder what’s better : * Having a lot of new contributors, but consuming “experienced” mapper time to fix mistakes of contributors who can’t be bothered to read any documentation. * Trying to make newbies read the wiki before mapping, actually display errors in iD instead of hiding them to increase “mapper retention”, etc. even if that means less new contributors but a rise in data quality.

Sympa !

Neat ! Can’t wait to test it out :)

Or maybe your wiki user page if you have one.

Nice catch !

@Sanderd17 Yes it seems so

I don’t really see the point of using a placeholder in OSM diaries, but I guess there is one as you posted.

Another thing : by using a placeholder, your update won’t be pulblished on things like RSS and might go unseen by a lot of people.

Really nice shades, good job !

Thank you for both the plugin and this great manual !

I added a link in the wiki page about the plugin toward your guide.

You can contact him via the changeset comments, as you wanted him to do before modifying entities you made.

It looks like the lack of time for admins/DWG is a reccuring matter, when I was doing country-scale correction of operator/network tags on a particular bank, i got reversed without any discussion, and the DWG member totally ignored my questions.

I understand that it can be really time-consumming to deal with both admin/moderation and explanations, but I don’t think you can dissociate these 2 functions as you deal with edits “in good faith”.

If there is not enough moderators (for the wiki, blog pages, OSM db…), you should try to bring more people into the pool, to avoid letting motivated contributors feel forsaken as I have been around some of my changeset, and how XXZME felt too, seemingly.

d1g, I understand the reasoning behind your posts/comments, but please don’t insult people, even if you think they deserve it. It makes for a negative atmosphere for everyone, it does not contributes to the discussion and forces most of you readers to disregard your arguments completely even if there may be truth in them.

Good idea, sounds doable !

However watch out, some people hate automated changes, and would revert your edit, even if done perfectly. So in order to avoid having your work thrown out by such persons, maybe you could add do a map to display such nodes and allow their manual deletion, even if this means slowing the correction process.

Nice tool !

I often use achavi to view changesets, maybe you could add it next to Visualdiff ?

Your contributions are welcome, however please use a better changeset message than just “Mapping Improvements”. It allows better understanding of why you did the changes present in the changeset for other mappers, as well as yourself in the future.

Hello, nice tool ! Do you plan on releasing the source code ? I would be interested to have a look at it in order to improve my own QA tool

Thank you

@masticator The problem is that a full history of changes made in OSM is kept. Such modifications will be stored forever.

Another “limitation” of OSM is that data consumers can be out-of-date (e.g. OSMAnd) until a manual update. That means that some users will not have the event mapped on their phone, while users having downloaded the map while the event is present in OSM will keep it that way until the next update.

So in my opinion, only long or medium-term modifications should be mapped (>2 months minimum)

The API is documented here, but sadly this feature hasn’t been developped yet.

What I do is bookmark each changeset I’m interested in, and check them sometimes.

Neat !

Very good post summarizing the tagging process for subways. Thank you !

(Et oui, au moins une personne a lu jusqu’au bout :)