Vandalism in London

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Vandalism in London

Antje (OpenStreetMap)
Suddenly I came back to the map just to find that my new bus relations are damaged by some vandal. I’m not rebuilding it. I give up.
_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

Dave F.
I sympathise Antje, I'm frustrated by vandals in my area (who really
should know better, given the length of time they've been active).

Post the links for your edits so we can have a look.

Cheers
Dave F.

On 04/10/2014 01:22, Antje (OpenStreetMap) wrote:
> Suddenly I came back to the map just to find that my new bus relations are damaged by some vandal. I’m not rebuilding it. I give up.
> _______________________________________________
> Talk-GB mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-gb


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com


_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

Antje (OpenStreetMap)
In reply to this post by Antje (OpenStreetMap)
Here is the list of London bus routes for starters: http://wiki.openstreetmap.org/wiki/Bus_routes_in_London

The ones that I dramatically improved are the new-style route_master relations, which are: 3, 4, 8-11, 18, 19, 21, 24, 30, 38, 43, 49, 57, 73, 76, 100, 144, 148, 192, 205, 277, 341, 390, 393, 394, 476.

I was going to do 453 because of the Borismaster, but I am doubtful.

I’m well known for extremely strict standards in bus routes because I just want nothing but the best on OSM: If you open the route 30 relations (unaffected by the incidents), you can see the effort I put into making the routing perfect, from the stops to the directions and even the operators. Given the military-precision effort, I don’t have the perseverance like most of you do because I now have university to attend to.

Even the Inner ring road is damaged (3124618).

Maybe we need a second “bus route czar”.

Antje.

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

Frederik Ramm
In reply to this post by Antje (OpenStreetMap)
Hi,

On 10/04/2014 02:22 AM, Antje (OpenStreetMap) wrote:
> Suddenly I came back to the map just to find that my new bus relations are damaged by some vandal.

When I read your message about "*my* bus relations" and your "military
precision" and "extremely high standards", my first thought was, oh dear
a normal mapper has dared to touch someone's delicate opus.

But you're right, there were indeed a couple mass deletion incidents in
the last few days in London, and it seems that this one was not properly
cleaned up (I thought I had, but it seems I missed some relations). I am
in the process of fixing it.

A message of "oh dear something is broken can you help me fix it" would
have achieved the same, it doesn't have to be a drastic "I give up" ;)

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

David Woolley
In reply to this post by Antje (OpenStreetMap)
On 04/10/14 01:47, Antje (OpenStreetMap) wrote:
> Even the Inner ring road is damaged (3124618
> <http://www.openstreetmap.org/relation/3124618>).

This is the only specific one you identified.  I assume you are
referring to http://www.openstreetmap.org/changeset/25784400 which has
the blank equivalent comment of "commit", and and no source, as do all
the user's other changesets.

This was done with iD which has a bad reputation for collateral damage,
and without a sensible commit comment, it is difficult to work out what
was intended, but I suspect that this relatively new editor is not
actually malicious.  That might have to be revised if you can work out
the intent of the edits and it becomes clear that they had malicious intent.

I would suspect that the editor is taking on too much for their level of
experience.  I would also have a general concern that such large numbers
of edits may be based on copyright sources, but without understanding
what they have been doing (changeset lists for this sort of edit are
just too long to work out the theme of the edit), I can't work out the
true source.   iD's Bing Imagery tag is pretty useless, as it will put
it there even if they never looked at the imagery.



_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

David Woolley
On 04/10/14 09:57, David Woolley wrote:

>
> This was done with iD which has a bad reputation for collateral damage,
> and without a sensible commit comment, it is difficult to work out what
> was intended, but I suspect that this relatively new editor is not
> actually malicious.  That might have to be revised if you can work out
> the intent of the edits and it becomes clear that they had malicious
> intent.
>
Looking a bit more carefully, it does look like this changeset is a mass
deletion with no associated real edits (the only changes are the
resulting fixups to relations), so, if not malicious, it is probably a
mistaken attempt at personal mapping.

Looking at one of the deleted ways, woodpecker_repair has considered it
to be accidental.

The big problem with relations is that they tend to be subject to
frequent edits, so reverts may fail, because they would take out a
subsequent legitimate change.  In this particular case, the same person
probably damaged relations in multiple edits, making only their very
last change affecting the relation revertable.  Maybe there should be
some super revert tool that takes a list of changesets, and will revert
objects that were last changed by any of them.

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

Antje (OpenStreetMap)
In reply to this post by Antje (OpenStreetMap)
I am sorry for the upset: this is the problem with someone carelessly editing at the very least.
_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

SomeoneElse
In reply to this post by David Woolley
On 04/10/2014 10:14, David Woolley wrote:
> ... it is probably a mistaken attempt at personal mapping.
>
>

That's what it looked like to me, certainly.

>
> The big problem with relations is that they tend to be subject to
> frequent edits, so reverts may fail, because they would take out a
> subsequent legitimate change.  In this particular case, the same
> person probably damaged relations in multiple edits, making only their
> very last change affecting the relation revertable.

The usual JOSM revert approach is to start at the latest problematic
changeset in a series and work backwards to the start; the problem is
that it can take out valid edits to the same data as "collateral damage"
on the way.  Depending on how large the problem and the
non-problematical edits were this can be difficult to achieve perfectly
- sometimes there has to be a manual tidying-up exercise.

> Maybe there should be some super revert tool that takes a list of
> changesets, and will revert objects that were last changed by any of them.

That's pretty much what the JOSM revert plugin does (in fact the way
that it manages to do what it does as well as it does is actually
extremely impressive).  There are other revert options as well of course
(the wiki's got details).

I suspect that the problem with London is that it's a "target" for a
couple of reasons.  One is that it's a "known name" - a target for
actual vandals (of which there are few, thankfully).  The other is that
there are a lot of people there who are just learning to map stuff, or
(like this person, probably) wanted a personal map of something, thought
that that is what they were creating, and did a lot of damage in the
process.

Because London is densely populated and there's a lot of detail, it
doesn't take long for other people to modify the affected data, making
reverts more difficult - the sooner this stuff is spotted the better
(within minutes if possible).  If any Londoners don't already, I'd
strongly suggest subscribing to a "WhoDidIt" feed for the area (see the
links from http://wiki.openstreetmap.org/wiki/Quality_assurance ) and a
new mappers feed (such as
http://resultmaps.neis-one.org/newestosm.php?zoom=11&lat=51.54427&lon=-0.14762&layers=0B0TFT 
).  If something is spotted reporting it on IRC (there are usually
people in the #osm-gb channel, failing that there are _always_ people in
#osm) is probably the quickest way at getting stuff resolved.

Cheers,

Andy


_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

Robert Scott
In reply to this post by Antje (OpenStreetMap)
On Saturday 04 October 2014, Antje (OpenStreetMap) wrote:
> I am sorry for the upset: this is the problem with someone carelessly editing at the very least.

I'm afraid part of the price of having "extremely high standards" for relations is eternal vigilance. It is exteremely easy to inadvertantly (subtly) "break" route relations and I think most average-skilled mappers will have probably done it a few times.

It would be unreasonable to expect ways with route relations on them to be considered "hallowed ground" and only to be edited by those skilled enough to leave the relations in perfect order.


robert.

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

Roger Calvert
Perhaps the principle OSM editors could emit a warning whenever an edit is undertaken which could invalidate a relation, also noting how many other ways would be affected. This at least would give mappers a chance to consider carefully whether they really know what they are doing.

Roger

On 04/10/2014 21:34, Robert Scott wrote:
On Saturday 04 October 2014, Antje (OpenStreetMap) wrote:
I am sorry for the upset: this is the problem with someone carelessly editing at the very least.
I'm afraid part of the price of having "extremely high standards" for relations is eternal vigilance. It is exteremely easy to inadvertantly (subtly) "break" route relations and I think most average-skilled mappers will have probably done it a few times.

It would be unreasonable to expect ways with route relations on them to be considered "hallowed ground" and only to be edited by those skilled enough to leave the relations in perfect order.


robert.

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb

--


Roger Calvert


_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

David Woolley
On 04/10/14 21:58, Roger Calvert wrote:
> Perhaps the principle OSM editors could emit a warning whenever an edit
> is undertaken which could invalidate a relation, also noting how many
> other ways would be affected. This at least would give mappers a chance
> to consider carefully whether they really know what they are doing.

JOSM already warns if you try to delete a member of a relation, although
it only lists the relations, and doesn't indicate how many other members
they have.  It does this at the point where you attempt to delete the
member, and goes modal for a confirmation.

However, iD gives no warning when you delete the member, and, although
it lists the relations at the commit stage, no-one is going to notice
that, especially if there are 17 pages worth of way and node deletions,
as in this case.

Note that both of them fix up the relations, by removing the member, so
the relation is never structurally invalid, although, as in the ring
road case, it might result in graph that isn't fully connected.

I think iD has taken totally the wrong approach.  If the concept is too
difficult for the target audience, it should have refused the operation,
rather than hidden the problem.

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

Frederik Ramm
Hi,

On 10/05/2014 01:35 AM, David Woolley wrote:
> Note that both of them fix up the relations, by removing the member, so
> the relation is never structurally invalid

The API would not allow deleting a way that is still member of a
relation, so relations will (barring API bugs) always be structurally
valid, no matter how braindead an editor is.

> I think iD has taken totally the wrong approach.  If the concept is too
> difficult for the target audience, it should have refused the operation,
> rather than hidden the problem.

I can see both sides.

If you want to delete something for a legitimate reason - meaning:
because it just isn't there on the ground - then why should you care in
how many relations it is - if it isn't there then it ought to be
deleted, period, and you'll be thankful if the editor takes care of
ensuring referential integrity of relations for you.

Difficulties arise when you delete something in error (then of course
pointing out to you how big the effect of your change is would
potentially make you rethink), or when you delete something with the
plan of re-drawing it. This is not something that an experienced mapper
would normally do - they would just improve the object that's there. But
newbies who think "drawing program" when they use an OSM editor are more
prone to deleting something and re-creating it. In that case, making the
user aware that they'll have to put the newly created thing back into
all these relations might discourage them from making that edit. A
relation saved, but an improvement lost...

JOSM has a plugin that will let you make a "replace geometry" operation.
You draw your new thing, then order JOSM to replace the geometry of the
old thing by what you've just drawn, and JOSM attempts to retain the
history and tags and relation memberships of the old object. But that,
again, is a very advanced operation that will be difficult to sell to a
newbie.

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

lsces
On 05/10/14 00:55, Frederik Ramm wrote:
> I can see both sides.
>
> If you want to delete something for a legitimate reason - meaning:
> because it just isn't there on the ground - then why should you care in
> how many relations it is - if it isn't there then it ought to be
> deleted, period, and you'll be thankful if the editor takes care of
> ensuring referential integrity of relations for you.

The fundamental problem here is this concept of 'delete' taking
priority. Something I've moaned about before. Yes there are legitimate
reasons why 'delete' may be an appropriate action, but it quite simply
currently there are no protections to prevent novice mappers using it as
an easy way of mapping. There SHOULD be at least a two stage step to
delete, and more important the historic aspects SHOULD still be
respected a little more. That a road has moved due to an improvement
scheme is an historic fact, and the old road's data is still valid and
while for some it's trash, for others of us it is still a valid element
in a view of the data at an earlier time. I still find the relations
area ill-conceived as maintaining integrity does require a lot more
manual work, and I think there is a lot of room for improvement when it
comes to things like routing data and maintaining closed boundaries?
That iD breaks things is a fact that needs to be addressed and perhaps
it's about time it's edits where they do delete anything relation based
should be ring fenced and require a second opinion before they can be
completed? But I think what is actually needed is a proper review of the
'micro/macro' mapping situation again. Where a 'way' exists that joins
to locations together is a macro element that may well consist of many
parallel and interlinked objects, which a relation tries to correlate?
But if there was a constraint on the relation saying that something is a
closed loop, such as a boundary, or a defined link between two points,
then when an element needed to maintain that constraint is deleted it
can be flagged better? If the break is due to some micro-mapping change
such as perhaps breaking a way to add a new speed limit, the API should
know that the extra new way needs to be added to the relation
automatically? If a section of the way is deleted and redrawn then there
should be a block on the deleted element being removed until the
'damage' is repaired. Something that JOSM at least tries to help with,
but iD ignores?

And if the deletion is due to a road improvement scheme the data should
simply be correctly marked with an end date rather than being deleted at
all, but keeping the correct historic view of the relation is something
that needs to be considered as well! It is in the change log but perhaps
not in the right format to be accessed easily in future? :(

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Deletions and newbie editors (was: Vandalism in London)

David Woolley
In reply to this post by Frederik Ramm
On 05/10/14 00:55, Frederik Ramm wrote:
> If you want to delete something for a legitimate reason - meaning:
> because it just isn't there on the ground

Even then it is a dangerous operation for newbies, as objects may have
tags that need to survive, and which may not be displayed in iD's
default view.  A classic example is NaPTAN stop data, where the rule for
one that  has gone away is to invalidate the bus stop tag and add
physically_present=no, but leave the node present.  I think I've seen
cases where a stop being moved has triggered an delete/add operation
that has lost he NaPTAN tagging.

Although I can't remember seeing this, I can also imagine a newbie
deleting the node when a shop closes, rather than keeping it as a vacant
shop.

Maybe newbie editors should clear the tags and set a fixme, rather than
actually deleting tagged features.  They could then hide the feature
from the newbie, whilst it is still visible in advanced editors.  I
know that real deletions don't actually delete the object from the
database, but the object is not loaded into editors, so people cannot
see that somebody removed something, so it is much more difficult for
someone familiar with the area, but not with the specific object, to
spot that, sometime in the past, the map was damaged by a newbie
deletion, and it is much more difficult for them to find the object and
the changeset to revert, to avoid a re-add.

I've excluded untagged nodes, as deleting them may be expedient when
re-modelling a way, although I'll try to avoid deletion, even then.  A
difficult case is something like a gate, where keeping the node, either
means detaching it from the way, or leaving a node that affects the path
of the way.

A weaker approach would be to require newbies to delete all tags and
relation memberships, one by one, before the editor will accept a
delete.  Unfortunately newbie cookbook guides tend to come up with the
easiest solution, not the right one.  In the contexts I most see, that
is to turn off all the security features, but in this case, it might be
a mechanical deletion of all tags and memberships, without applying any
thought.

iD's relation deletion is a sort of mechanically applied example of the
cookbook approach I fear.  The API won't let it delete the object, so it
removes the memberships rather than questioning the operation.

Having several decades of experience in the software industry, starting
with JOSM was very easy for me, but I wonder whether newbie editors
really benefit newbies.  To me, iD is actually a little more difficult
than JOSM to use, even for simple things.


_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

David Woolley
In reply to this post by lsces
On 05/10/14 09:49, Lester Caine wrote:
> there
> should be a block on the deleted element being removed until the
> 'damage' is repaired. Something that JOSM at least tries to help with,
> but iD ignores?

Where the damage is the breaking of a relation, iD is not ignoring it,
it is actively but silently deleting the membership, so that the newbie
gets the presentational effect they desire, without ever becoming aware
of the implications.

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Vandalism in London

Andy Street-2
In reply to this post by David Woolley
On Sun, 05 Oct 2014 00:35:20 +0100
David Woolley <[hidden email]> wrote:

> I think iD has taken totally the wrong approach.  If the concept is
> too difficult for the target audience, it should have refused the
> operation, rather than hidden the problem.

Simply refusing to delete seems rather unhelpful. I'd much prefer
the user to be presented with a dialog box that explains the problem in
simple terms before allowing them to either continue with the delete or
seek assistance. If the user requires assistance a note could be opened
stating something along the lines of "I require assistance deleting
element x for reason y, please help me.".

--
Regards,

Andy Street

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Deletions and newbie editors

Spike
In reply to this post by David Woolley
On 05/10/2014 10:47, David Woolley wrote:
> A classic example is NaPTAN stop data, where the rule for one that  
> has gone away is to invalidate the bus stop tag and add
> physically_present=no, but leave the node present.  I think I've seen
> cases where a stop being moved has triggered an delete/add operation
> that has lost he NaPTAN tagging.

Could I ask please the logic behind retaining references to a stop that
does not exist?

I have a local example of a stop that has not had a physical presence in
living memory but STILL shows on bus company maps.

Spike

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Deletions and newbie editors

David Woolley
On 05/10/14 11:27, Spike wrote:

> On 05/10/2014 10:47, David Woolley wrote:
>> A classic example is NaPTAN stop data, where the rule for one that has
>> gone away is to invalidate the bus stop tag and add
>> physically_present=no, but leave the node present.  I think I've seen
>> cases where a stop being moved has triggered an delete/add operation
>> that has lost he NaPTAN tagging.
>
> Could I ask please the logic behind retaining references to a stop that
> does not exist?
>
> I have a local example of a stop that has not had a physical presence in
> living memory but STILL shows on bus company maps.
>

I didn't set the rules, but I believe it is because the data is
imported, so the existence of the data is controlled by the source of
the import.

Whilst the object still exists, it no longer has the the
highway=bus_stop tag, so is not considered to be a bus stop, and should
be deleted from any routes that it is on (very few people actually map
stops on routes in the first place).

There are also some stops that are actual stops, but are not signed
(customary stops), and amongst those, you will probably find a few that
are only used for rail replacement services, so would have to be
surveyed on the right weekend to actually be found (they may have
temporary signs on those days).

(There is a problem with NaPTAN, that has been discussed before, than
the NaPTAN list is dynamic, but OSM only has a single snapshot of it.)

In practice, I think I have found more NaPTAN nodes deleted in error
than ones that represent stops that are never used.

You will find other regional imports with special rules, and they tend
to be the sort of things that get erroneously repaired by people working
outside the area.


_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Deletions and newbie editors

Dan S
2014-10-05 12:11 GMT+01:00 David Woolley <[hidden email]>:

> On 05/10/14 11:27, Spike wrote:
>>
>> On 05/10/2014 10:47, David Woolley wrote:
>>>
>>> A classic example is NaPTAN stop data, where the rule for one that has
>>> gone away is to invalidate the bus stop tag and add
>>> physically_present=no, but leave the node present.  I think I've seen
>>> cases where a stop being moved has triggered an delete/add operation
>>> that has lost he NaPTAN tagging.
>>
>>
>> Could I ask please the logic behind retaining references to a stop that
>> does not exist?
>>
>> I have a local example of a stop that has not had a physical presence in
>> living memory but STILL shows on bus company maps.
>>
>
> I didn't set the rules, but I believe it is because the data is imported, so
> the existence of the data is controlled by the source of the import.
>
> Whilst the object still exists, it no longer has the the highway=bus_stop
> tag, so is not considered to be a bus stop, and should be deleted from any
> routes that it is on (very few people actually map stops on routes in the
> first place).

I don't understand why the osm object should continue to exist then.
If the bus stop ceases to exist, and the object is purely a bus-stop,
the object should be deleted, no? It doesn't make any difference that
the data was imported. (Future data-conflaters can detect naptan IDs
that vanish, just as well as they can detect naptan IDs that have
special this-has-vanished tags.)

It doesn't seem sustainable to have "special rules" for certain data
items, decided by whoever did/discussed the import, since they can't
expect the global community of OSMers to be aware of those special
rules.

Dan

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
Reply | Threaded
Open this post in threaded view
|

Re: Deletions and newbie editors

Ian Caldwell
In reply to this post by David Woolley

On 5 October 2014 12:11, David Woolley <[hidden email]> wrote:
Could I ask please the logic behind retaining references to a stop that
does not exist?

In rural area there are places that buses stop but no physical stop. And in Malvern there are examples of where this only a physical stop on one side of the road (it says both directions) but NaPTAN has two stops.



Ian

_______________________________________________
Talk-GB mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-gb
123