[OSM-talk] stop deleting abandoned railroads

Serge Wroclawski emacsen at gmail.com
Sat Aug 15 10:31:14 UTC 2015

On Sat, Aug 15, 2015 at 5:19 AM, Volker Schmidt <voschix at gmail.com> wrote:

> I would like to argue for a general
> do-not-remove-if-you-do-not-have-the-original-mapper's-ok-beforehand policy
> for these and similar cases.
Then you are (whether or not you intend it) arguing in favor of
dis-empowering users.

Our project's policy thusfar has been in contrast to other projects in that
each and every one of us is empowered to make changes to anything we see.

We certainly have policies in regards to quality control- if someone makes
a bad edit, we revert it, but we are always in favor of the empowerment of
our users to fix problems, rather than saying that they can't, or need to
ask permission beforehand.

Let's be very clear on the issue in this case- it's regarding a very subtle
line of objects which are in one of two states:

1. Visible on the ground but difficult to detect (ie require specialized


2. No longer visible at all.

The problem that we have in some parts of the world is a lack of data, but
in other parts, we have an abundance of bad imports, and a general
timidness around the removal of data that we can't find the owner of, which
leaves us with data that *we know is bad*, but where the individual mappers
do not feel empowered to act on because of this exact attitude of needing
to contact and work with the importer.

This leaves our project with a problem of lots of data and no one feeling
empowered to remove it.

If we continue to go down that road, we will be left in an untenable
situation of living in the data equivalent of a hoarder's house.

I'm very much in favor of mapper to mapper collaboration. In fact I am the
person who mentored the GSoC project to add changeset discussions, but I do
not believe we want to change the project's culture into one where no one
feels empowered to edit the map without first asking permission.

- Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20150815/249e1eb4/attachment.html>

More information about the talk mailing list