irc will only work when that is an established communication channel in
that country. So please, do not make that a requirement. E.g. in Belgium
the best way to contact other mappers is the mailing list. I'll understand
that this makes it more difficult for non-Belgians to fix the tagging here.

Should I contact other people when I correct my own tags ? Or when I did a
resurvey of the area and saw that it was really a restaurant and not a
restuarant ?

Why aren't we imposing the same requirements for people that just trace
from aerial images? What if such a person connect two roads while in
reality they are not connected ? Or when 2 intersecting buildings are
separated ? Does (s)he risks to have his/her changesets reverted or
eventually get blocked as well ?

I'll agree with Jochem that people that are "gardeners' (to use wikipedia
terminology -- people that try to fix existing tags) have to follow much
more rules and risk more severe punishment than "tracers". It seems like
the latter can't do anything wrong, unless it's pure vandalism.

Can anybody tell me why a surveyor or tracer is free to keep adding
restuarants without punishment, but a gardener should follow a long
procedure to fix that ?

regards

m


On Wed, Jun 11, 2014 at 6:57 PM, John Baker <rovas...@hotmail.com> wrote:

> I am fine with that. More realistic stuff would be more functional.
> To be constructive here (for a change for me) here some more thoughts.
>
> I would even break it down to levels of what you are doing.
> Here are a few example I have done before with suggested
>
> Typo (a few characters difference)
> e.g. religion=Budist to religion=buddist
> Updating 1 tag value up to 10 occurrences. Simple IRC wait 2 minute or yes.
> Updating 1 tag value up to 100 occurrences. IRC chat wait 10 minutes or 2
> yes.
> Updating 1 tag value above 100 occurrences. Mailing list chat.
>
> Changing the word/meaning of a tag to correct common usage.
> e.g. amenity=takeaway to amenity=fast_food
> Updating 1 tag value up to 10 occurrences. Simple IRC wait 10 minute or 2
> yes.
> Updating 1 tag value up to 100 occurrences. IRC chat wait 30 minutes or 3
> yes.
> Updating 1 tag value above 100 occurrences. Mailing list chat.
>
> Implying tag types
> e.g. denomination = roman_catholic and religion is null -->
> religion=christian
> etc, etc,
>
> Additionally I would say putting more meaning information into the change
> sets comments.
>
> For example a changeset comment like.
>
> "Correcting "amenity=watering place" -> "amenity=watering_place" typo."
> rather than nothing or just "typos" or "watering place" or something.
> So it is clearer to all that view the changesets what you are doing at a
> glance and reverts can be easier on the rare cases that it apply. And is a
> form of documentation.
>
> I would even be up for a separate account to doing many larger changes say.
>
> I happily write a wiki article on this if there was a desire from the
> community.
>
> > Date: Wed, 11 Jun 2014 11:47:55 -0400
> > From: andrew.guer...@uvm.edu
> > To: talk@openstreetmap.org
> > Subject: Re: [OSM-talk] Worldwide non-surveyed tag edits
>
> >
> > I've just read through http://wiki.osm.org/wiki/Mechanical_Edit_Policy
> > and this thread, and here's my thoughts on the matter.
> >
> > It is possible to improve OSM using only the data already within
> > OSM--with no external knowledge, survey, or other data sources. Typo
> > fixing and other similar activities do provide benefit.
> >
> >
> > When you make an edit using no external knowledge, you must always
> > discuss it first. In my opinion, not doing so--even for an edit that
> > turns out to be correct!--is a detriment to the community, because it is
> > both risky and antisocial.
> >
> > I don't however agree with the policy's requirement of specific forms of
> > discussion. I think that the discussion required should be proportional
> > to the change being made. For example, if you notice that three
> > instances of "amenity=restuarant" were added this week, I think an
> > appropriate form of discussion would be to hop on IRC, say you're fixing
> > them, wait until someone says "yay" or 2 minutes has passed, and do it.
> > But as the risk goes up--either lower certainty or higher impact--the
> > required discussion should too, from IRC to a quick note on a mailing
> > list to long mailing list threads with wiki documentation and detailed
> > notes about methods and tools.
> >
> >
> > Similarly, in minor cases I don't agree with the policy's requirement
> > for documentation. If someone wants to merge the 10 copies of
> > "amenity=watering place" into the 1647 copies of
> > "amenity=watering_place", I don't think there will be any negative
> > impacts on consumers. But if consumers will be affected then
> > documentation should be a requirement. I think there should be
> > guidelines for how to document, and the community should decide (in the
> > required discussion!) which steps of the guidelines should be followed
> > in a specific case.
> >
> >
> > The existing requirements for execution look good to me.
> >
> >
> > When someone doesn't follow the policy, what should be done? In my
> > opinion, everyone SHOULD follow the policy, but if they don't the
> > community should be lenient, either doing nothing or giving gentle
> > reminders that the policy exists--until the person causes a problem with
> > their edits. At that point, the community should start holding the
> > person to a higher standard and insisting they follow the policy. If
> > someone who has caused problems before continues to not follow the
> > policy, then the community should bring the issue to the DWG.
> >
> > That's my thougts,
> > --Andrew
> >
> > _______________________________________________
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
>
> _______________________________________________
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Reply via email to