[OSM-talk] Code of conduct for automated (mass-) edits

[Gert Gremmen]

Some enhancements:



The serverscript  (see below) could create a web page with the
temporary accountname as a URL, summarizing all the submitted data,
for consulting by anyone finding a questionable dataelement. 

This webpage  may contain a reverse request button.
A system should be invented for approval of such a request.
In it's best form the script would reverse automatically.

A report will be created with reversals that create problems,
such as modified elements after the batch, for manual
review........ who will do that ???


Gert Gremmen
-----------------------------------------------------

Openstreetmap.nl  (alias: cetest)


-----Oorspronkelijk bericht-----
Van: talk-bounces at openstreetmap.org
[mailto:talk-bounces at openstreetmap.org] Namens Gert Gremmen
Verzonden: Monday, September 29, 2008 10:38 AM
Aan: Philip Homburg; Talk Openstreetmap
Onderwerp: Re: [OSM-talk] Code of conduct for automated (mass-) edits

I'd suggest a special usertype for batch operations,
and combine that with a notification system
so as to enable that account for one batch.

The usertype should have the username of the uploader
with a random number attached (fe cetest0000 to cetest9999)
to distinguish between sessions.

The username should be enabled shortly before
carrying out the scripts/upload by the server.
The uploader could enable his temp account by filling in a web form
with sufficient "required fields"

I suggest:
username
bounding box for all changes
description of change
modified data (list of tags)
intention of batch operation

The form would return by email the username
to be used for this upload. The email ensures
that the uploader can be contacted.


The notification script could also create a backup of
all changes done immediately after, so as to facilitate
removal if required. May this is redundant, as 
date and time are available to select.

Normal users should have their number of changes per upload
limited to say a few hundreds a time. This could
be supported in JOSM and merkaartor by a warning system
when 90% of the maximum upload has been reached
and the user should upload. 


Some finetuning of the above may be necessary.


Gert Gremmen
-----------------------------------------------------

Openstreetmap.nl  (alias: cetest)


Gert Gremmen
-----------------------------------------------------

Openstreetmap.nl  (alias: cetest)


-----Oorspronkelijk bericht-----
Van: talk-bounces at openstreetmap.org
[mailto:talk-bounces at openstreetmap.org] Namens Philip Homburg
Verzonden: Monday, September 29, 2008 9:53 AM
Aan: Talk Openstreetmap
Onderwerp: Re: [OSM-talk] Code of conduct for automated (mass-) edits

In your letter dated Mon, 29 Sep 2008 01:08:50 +0200 you wrote:
>     as OpenStreetMap draws more and more sophisticated users, we're
>     also seeing more scripts or, as they would be called in Wikipedia,
> "bots", modifying data.
> 
> 1. Make a plan of what you want to change, and discuss in relevant
> forum (usu. mailing list). If there are many objections; drop the
> plan. If there are few objections, maybe exempt certain areas or
> objects created by certain people in order to respect their
> objections. Remember that they can easily change things back again
> if you act against their will, so don't even try to play the
> superiority card.  
> 
> I would also accompany this by the notion that if you see an
> automated edit that you believe has problems, and it has not been
> discussed or documented, it's ok to revert it.

I think there should be two technical things in place:

One thing is a structured way of rolling back edits. There should be a
way
of reporting large scale edits, and getting them removed from the
database. 

The second thing is a reporting script that reports on large scale edits
in
a timely fashing.

As far as politics go, I think that it would a good idea to just re-use
the
current structure for introducing new map features. Before you run a
script
you first propose it and only run it when enough people cast a vote in
favor
of running the script.

For example, a good way of completely destroying the JOSM/Validator's
duplicate node detection feature is to fill the database with a huge
number of
aumatically generated duplicate nodes. :-(



_______________________________________________
talk mailing list
talk at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
talk at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk