Re: [Talk-GB] Vandalism in London

[Lester Caine]

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
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] Deletions and newbie editors (was: Vandalism in London)

[David Woolley]

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
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Vandalism in London

[David Woolley]

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
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Vandalism in London

[Andy Street]

On Sun, 05 Oct 2014 00:35:20 +0100
David Woolley  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
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors

[Spike]

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
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] 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
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors

[Dan S]

2014-10-05 12:11 GMT+01:00 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).

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
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors

[Ian Caldwell]

On 5 October 2014 12:11, David Woolley  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
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors (was: Vandalism in London)

[David Woolley]

On 05/10/14 11:25, Andy Street wrote:

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.".


Newbies will tend to do what is necessary to suppress the error message, 
without thinking what they are doing.  Alternatively, they will reject 
the editor as one of the big problem with creating dumbed down 
interfaces to complex software is that the market will select the 
product that appears to hide the problem over the one that puts them to 
the trouble of doing the right thing.**


In other fields, there are large after markets for cook books telling 
people how to achieve particular effects in a mechanical fashion.


Newbies don't want to know the reasons, and I suspect most of them see 
the map as the standard rendering, and have trouble with the 
abstractions that underlie it and which need to be understood for such a 
message to make sense.  Those who do want to know the reasons, would 
probably find an advanced editor much easier to use.


JOSM does give such warnings, but JOSM is aimed at people who understand 
the abstraction below the rendering.  It is the lack of having to deal 
with such warnings that makes newbie editors newbie editors.


The standard newbie response to an access violation in Unix/Linux is to 
set the file mode to 777.  The standard newbie way of killing a process 
is kill -9.


** A 40 year old example is that the programming adviser at university 
told me that users preferred the statistics package that didn't warn 
them about the loss of significance errors when trying to fit 
multi-variable models with too many variables, even though the result 
was meaningless models.



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Vandalism in London

[Lester Caine]

On 05/10/14 11:25, Andy Street 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.".

Which sort of ties in with my constraints on relations.
If an edit is breaking something it's easy enough to say "unable to
proceed because ... " but ideally the API should be able to find a new
missing bit and add it into the relation? Only blocking something when
the new edit does create a conflict because the relation is now broken?

-- 
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
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors (was: Vandalism in London)

[Andy Street]

On Sun, 05 Oct 2014 12:47:29 +0100
David Woolley  wrote:

> Newbies will tend to do what is necessary to suppress the error
> message, without thinking what they are doing.  Alternatively, they
> will reject the editor as one of the big problem with creating dumbed
> down interfaces to complex software is that the market will select
> the product that appears to hide the problem over the one that puts
> them to the trouble of doing the right thing.**

I agree; people will generally follow the path of least resistance.

> Newbies don't want to know the reasons, and I suspect most of them
> see the map as the standard rendering, and have trouble with the 
> abstractions that underlie it and which need to be understood for
> such a message to make sense.  Those who do want to know the reasons,
> would probably find an advanced editor much easier to use.

Those reasons will still need to be explained when the editor refuses
to delete some ways but not others so I don't see how you would get
around that problem.

> The standard newbie response to an access violation in Unix/Linux is
> to set the file mode to 777.  The standard newbie way of killing a
> process is kill -9.

The standard newbie response to "You cannot delete this way because it
is part of a relation" would be to delete the relation membership in
the edit panel and try again.

It is hard to make people engage with things they don't understand or
that they feel are irrelevant. If we want people to care about relations
then we need to explain to them why they are important and make the
learning process as painless as possible.

-- 
Regards,

Andy Street

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors (was: Vandalism in London)

[Antje (OpenStreetMap)]

I am trying to think how to reduce incidents that would cause alarm to users 
like me, but there is no point in flagging new editors because it won’t help 
them integrate into OSM.

I am not an expert in iD since I moved on from Potlatch, but Potlatch at least 
denotes relations on ways, while iD does not.

I know that people are trying to make OSM easy to edit but how it would not 
make sense to at least put a prompt saying “Deleting this way will affect 
routes that depend on it: make sure that such routes have an appropriate 
diversion. Are you sure you want to do this?”

I notice that the relations are way down the sidebar: is this causing some 
users to not know about relations?

Antje
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors

[Stuart Reynolds]

This is digressing somewhat into a discussion about NaPTAN but before I get 
into that point, if I can just pick up on the comment about leaving things in 
because it shows a history of what the data looked like. Sorry, but OSM IS a 
dynamic data set and doesn't AFAIK have the facility to keep a history in that 
sense. Personally I would not want to see a road alignment that no longer 
existed- it would be clutter.

On NaPTAN, deleted stops are those that have been removed and should 
correspondingly be removed from OSM. However there is evidence that some 
authorities delete stops simply because no service calls there-but that is 
wrong. Suspended stops on the other hand should rightly remain in the data.

CUS stop types are the custom and practice ones that have no physical 
infrastructure. In the case where a stop says "stops both sides" then there 
should be one MKD (marked) stop and one C US in NaPTAN. Unfortunately it 
doesn't always happen like that.

If you find examples you consider to be erroneous then please DM me and I will 
try and pass it on to three people concerned and/or SeT who look after the 
standard. Just don't inundate me, ok :-)

Stuart

Sent from my iPhone

On 5 Oct 2014, at 12:33, Ian Caldwell 
mailto:ian1caldwell+...@googlemail.com>> wrote:


On 5 October 2014 12:11, David Woolley 
mailto:for...@david-woolley.me.uk>> 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
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors

[Stuart Reynolds]

That should have been DfT in my last sentence. Curse autocorrect!

Sent from my iPhone

On 5 Oct 2014, at 18:00, Stuart Reynolds 
mailto:stu...@travelinesoutheast.org.uk>> 
wrote:

This is digressing somewhat into a discussion about NaPTAN but before I get 
into that point, if I can just pick up on the comment about leaving things in 
because it shows a history of what the data looked like. Sorry, but OSM IS a 
dynamic data set and doesn't AFAIK have the facility to keep a history in that 
sense. Personally I would not want to see a road alignment that no longer 
existed- it would be clutter.

On NaPTAN, deleted stops are those that have been removed and should 
correspondingly be removed from OSM. However there is evidence that some 
authorities delete stops simply because no service calls there-but that is 
wrong. Suspended stops on the other hand should rightly remain in the data.

CUS stop types are the custom and practice ones that have no physical 
infrastructure. In the case where a stop says "stops both sides" then there 
should be one MKD (marked) stop and one C US in NaPTAN. Unfortunately it 
doesn't always happen like that.

If you find examples you consider to be erroneous then please DM me and I will 
try and pass it on to three people concerned and/or SeT who look after the 
standard. Just don't inundate me, ok :-)

Stuart

Sent from my iPhone

On 5 Oct 2014, at 12:33, Ian Caldwell 
mailto:ian1caldwell+...@googlemail.com>> wrote:


On 5 October 2014 12:11, David Woolley 
mailto:for...@david-woolley.me.uk>> 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
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors

[David Woolley]

On 05/10/14 17:58, Stuart Reynolds wrote:


On NaPTAN, deleted stops are those that have been removed and should
correspondingly be removed from OSM


If that is the new policy, you should change 



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors

[David Woolley]

On 05/10/14 18:20, David Woolley wrote:

On 05/10/14 17:58, Stuart Reynolds wrote:


On NaPTAN, deleted stops are those that have been removed and should
correspondingly be removed from OSM


If that is the new policy, you should change




I think this will result in a slight increase in the rate at which valid 
NaPTAN data is lost from the map.  I've resurrected a few valid NaPTAN 
stops, so I know that this data is already decaying.



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors

[Stuart Reynolds]

That's my view as someone who is closely involved with NaPTAN. I don't know 
what official OSM policy is-I'm just saying what it ought to be

Regards
Stuart

Sent from my iPhone

> On 5 Oct 2014, at 18:20, David Woolley  wrote:
> 
>> On 05/10/14 17:58, Stuart Reynolds wrote:
>> 
>> On NaPTAN, deleted stops are those that have been removed and should
>> correspondingly be removed from OSM
> 
> If that is the new policy, you should change 
> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors

[Lester Caine]

On 05/10/14 17:58, Stuart Reynolds wrote:
> This is digressing somewhat into a discussion about NaPTAN but before I
> get into that point, if I can just pick up on the comment about leaving
> things in because it shows a history of what the data looked like.
> Sorry, but OSM IS a dynamic data set and doesn't AFAIK have the facility
> to keep a history in that sense. Personally I would not want to see a
> road alignment that no longer existed- it would be clutter.

None of the history would be displayed on the 'current' map, but
correctly handled objects that have yet to be constructed would have a
start date in the future and renderers could include or ignore them, and
historic material would have an end date set which the renderers would
also respect. A view of the data with any out of scope material
suppressed is easy to implement, but at present we still don't have a
reliable method of archiving material even if that involves transferring
it to a separate copy of the whole database which can be used by
historic rendering applications.

We are not asking 'current only' mappers to do anything as the detail is
already mapped, and there are a number of projects using archives like
the Library of Scotland scans to add a lot more historic material. A
large proportion if that history is being used on the current map to
fill in house numbers and other fine detail so the idea of two separate
databases simply does not make any sense going forward. The bulk of the
additional data is simply adding the correct start date to already
mapped existing objects!

-- 
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
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors

[David Woolley]

On 05/10/14 21:00, Lester Caine wrote:


and
historic material would have an end date set which the renderers would
also respect. A view of the data with any out of scope material
suppressed is easy to implement, but at present we still don't have a
reliable method of archiving material even if that involves transferring
it to a separate copy of the whole database which can be used by
historic rendering applications.


This part already exists, which it is one of the reasons why it is bad 
to do delete/re-add.  The data is archived in the live, online, 
database, now!


Whilst the archive exists and is accessible, what I'm not aware of is an 
API interface that allows one to retrieve the versions of objects that 
existed at a particular date.


That's also why deletions are particularly dangerous.  There is no easy 
way to find objects that used to exist in a particular area, whereas, if 
an object exists, you can search its back versions to backdate it.


There are some tactics you can use, like looking at back histories of 
relations, or recovering the changeset that created contemporaneous objects.


Unfortunately, editors can make it difficult to maintain the identity of 
an object, e.g. it is difficult to detach a node from a way without 
creating a low level delete/re-add.  Also, if you merge objects, you 
have to choose to maintain the history on just one of them, and getting 
the editor to choose one particular one is difficult.  (I think recent 
versions of JOSM may be able detach a node from a way.  The safest way 
of merging is possibly to do a paste tags, into the one you want to keep.)


The dates that apply here are the dates of mapping, not the the date the 
real world object came into existence, and there is no way of future 
dating.  Basically you can construct the map as of a date, but not a map 
of the world as of that date.







___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors (was: Vandalism in London)

[David Woolley]

On 05/10/14 14:11, Lester Caine wrote:


Which sort of ties in with my constraints on relations.
If an edit is breaking something it's easy enough to say "unable to
proceed because ... " but ideally the API should be able to find a new
missing bit and add it into the relation? Only blocking something when
the new edit does create a conflict because the relation is now broken?


JOSM, rather than the API, already does this for way splits, although it 
doesn't handle some of the more complex cases of splitting roundabouts 
well.  I wouldn't be surprised if iD did as well.


It is deletions and effective deletions (like removing one direction by 
adding oneway=yes) that are difficult to automate.  If you did automate 
them, I think the editor would need to tag the relations for review. 
There are many reason why the information needed to make a good guess 
might not be available at the time needed.




___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors

[Lester Caine]

On 05/10/14 21:43, David Woolley wrote:
> On 05/10/14 14:11, Lester Caine wrote:
> 
>> Which sort of ties in with my constraints on relations.
>> If an edit is breaking something it's easy enough to say "unable to
>> proceed because ... " but ideally the API should be able to find a new
>> missing bit and add it into the relation? Only blocking something when
>> the new edit does create a conflict because the relation is now broken?
> 
> JOSM, rather than the API, already does this for way splits, although it
> doesn't handle some of the more complex cases of splitting roundabouts
> well.  I wouldn't be surprised if iD did as well.
> 
> It is deletions and effective deletions (like removing one direction by
> adding oneway=yes) that are difficult to automate.  If you did automate
> them, I think the editor would need to tag the relations for review.
> There are many reason why the information needed to make a good guess
> might not be available at the time needed.

Changes of direction and things like that certainly impact on routing
grids, but I was more concerned initially in maintaining the integrity
of the basic way, more for boundaries but also for way relations which
are intended to be a single way. Flagging up roundabout is probably a
very good example as I have to admit to having added the odd one in
recent years, but not been sure if it broke anything. If the road that
was broken ad been part of a boundary, then the original straight line
segment that was removed needed to be retained. Historically as an
indication on where the road went prior to the construction of the
roundabout, but also as an ongoing boundary segment straight across the
new roundabout, with other routing relations using the correct
roundabout segment :) All achievable if the API monitors the constraints
on relations and checks that what JOSM submits is complete.

-- 
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
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Deletions and newbie editors (was: Vandalism in London)

[SomeoneElse]

With new editors though I sometimes think we forget how hard it is for 
someone to start editing now in e.g. the centre of London compared to 
when we "experienced mappers" started.  Here, for example (courtesy of 
Martijn Van Exel's "OSM Then and Now") is what the area I started 
mapping in looked like at around the time that I started:


http://98.202.195.171/osm/16/32520/21295.png

I went through at least three iterations of how the paths there should 
be tagged, committed numerous "X not joined properly to Y" sins and on 
at least one occasion managed to duplicate all the minor roads in the area.


Many new mappers are just "hit and run" mappers and often it's easy to 
tidy up their contributions after they've long disappeared**. The ones 
who do stick around do need to be given a bit of time to get the hang of 
things - there are a lot of concepts to understand that really aren't 
obvious (the fact that the "map data" is more than just "the standard 
map style as seen at osm.org" is one of those).  However often a polite 
message helps - not a "you broke the map!" one, but more like "oh dear, 
something appears to have gone a bit wrong", together with an offer to 
assist and answer any other questions.


As has been said earlier in previous thread, it doesn't make sense to 
restrict the ability to edit OSM data to people who understand what e.g. 
relations are.


I'm certainly not the biggest fan of the way that iD does some things, 
but sometimes it seems to be being suggested that the people who wrote 
iD somehow "don't care" about OSM data quality and "if only it were more 
like JOSM" a number of these issues would go away.  The problem is that 
the task that iD sets itself is fundamentally different from the one 
that JOSM has.  The quickest scan of the discussions on 
https://github.com/openstreetmap/iD/issues would show that the balancing 
of "how to stop new editors from causing problems" with "how to allow 
new editors to contribute at all" is taken very seriously indeed***.


I did try and do some systematic analysis to compare editors back in 
September last year 
(https://lists.openstreetmap.org/pipermail/talk/2013-September/068178.html), 
and in that the "newbie error rate" in iD was lower than in P2 (and 
other editors including JOSM, although the numbers are a bit too low to 
reliably draw conclusions there).


This isn't so much an "iD" problem as a "new mappers" one (and we don't 
have so many new mappers coming forward that we can afford to shoo them 
away).  We do have ways of seeing new mappers when they start 
(http://resultmaps.neis-one.org/newestosm.php and the IRC country bot 
feeds).  We have ways of being informed about changesets in an area that 
might be problematical (WhoDidIt among others), ways to collaborate (IRC 
country channels, forums, mailing lists, etc.) and everyone has the 
ability to contact new mappers near them and offer to help.


Cheers,

Andy


** Of course, people who delete lots of things because they think 
they're editing _their own personal copy_ of the map data need to be 
addressed immediately - but those edits are easy to spot.


*** Some of what it feels like from the other end of "the iD debate" was 
written up at 
https://lists.openstreetmap.org/pipermail/osmf-talk/2014-September/002551.html 
(obviously read the thread and links to get the full context of that, 
but suffice to say that the reason that iD isn't perfect is because it 
is trying to solve a Very Hard Problem).



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb