Do I understand this correctly? You are creating tags in the OSM database for your private tool? I hope there is some misunderstanding here, because that isn't acceptable behaviour.
Jochen On Sat, Oct 14, 2017 at 09:33:14AM +0000, Yuri Astrakhan wrote: > Date: Sat, 14 Oct 2017 09:33:14 +0000 > From: Yuri Astrakhan <yuriastrak...@gmail.com> > To: Simon Poole <si...@poole.ch>, talk@openstreetmap.org > Subject: Re: [OSM-talk] New OSM Quick-Fix service > > ** UPDATE: ** > > The service now supports "reject" button. To use it, your query must > contain " #queryId:... " comment. By default, when a user rejects > something, a tag "_autoreject=id" is created. An object can have multiple > rejected IDs. If the current query was previously rejected, user will no > longer be able to edit the object with the same query. > > Optionally, query may specify a different rejection tag with > " #rejectTag:... ", instead of using the default "_autoreject". I am > still hoping for a better default name. > > Both #rejectTag and #queryId values must consist of only the Latin > characters, digits, and underscores. > > Additionally, the tool no longer allows editing above zoom 16. > > Thanks! > > > On Sat, Oct 14, 2017 at 12:34 AM Yuri Astrakhan <yuriastrak...@gmail.com> > wrote: > > > Simon, thanks for the constructive criticism, as it allows improvements > > rather than aggravation. I propose that "rejections" are saved as a new > > tag, for example "_autoreject". In a way, this is very similar to the > > "nobot" proposal - users reject a specific bot by hand. > > > > _autoreject will store a semicolon-separated multivalue tag. A query will > > contain some "ID", e.g. "amenity-sanatorium", and that ID will be added to > > the _autoreject whenever user clicks "reject suggestion" button. > > > > Benefits: > > * use existing tools to analyse, search, and edit this tag, without > > creating anything new > > * we can use it inside the queries themselves to say "only suggest to fix > > X if the users have rejected Y", or if someone creates a bad query and most > > values are rejected, we can easily find them and clean them up > > * very easy to implement, few chances for bugs, no chances to loose > > rejection data by accident > > * other tools can also use this field to store rejections, e.g. > > mapRoulette or Omose. > > * Query authors can easily search for it to see why they showed up in the > > query result, and fix the original query > > > > The biggest problem is the tag name, any suggestions? > > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk