[OSM-talk] New OSM Quick-Fix service

Jochen Topf jochen at remote.org
Sat Oct 14 12:57:48 UTC 2017


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 <yuriastrakhan at gmail.com>
> To: Simon Poole <simon at poole.ch>, talk at 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 <yuriastrakhan at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


-- 
Jochen Topf  jochen at remote.org  https://www.jochentopf.com/  +49-351-31778688



More information about the talk mailing list