So who decides what is good data and what is bad data? 

And "visibility on the ground" needs nuancing. Are we to remove
underground pipelines/power lines? Or boundaries? "Visible and/or
verifiable" might be better. A rule that needs loads of exceptions, is
not a well formed rule. 

An abandoned railway route IS an abandoned railway route, even today
(i.e. that is current data). It WAS a working railway line. That is all
verifiable. 

On 2015-08-15 12:31, Serge Wroclawski wrote: 

> On Sat, Aug 15, 2015 at 5:19 AM, Volker Schmidt <vosc...@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 
> knowledge)
> 
> or
> 
> 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
> 
> _______________________________________________
> 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