Re: [Talk-GB] Deletions and newbie editors (was: Vandalism in London)
That's interesting Andy, thanks Dan 2014-10-05 23:07 GMT+01:00 SomeoneElse li...@mail.atownsend.org.uk: 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 ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Deletions and newbie editors
On 05/10/14 22:28, Lester Caine wrote: All achievable if the API monitors the constraints on relations and checks that what JOSM submits is complete. That would represent a radical change in design philosophy. At the moment, the code behind the API (I standards interface) implements very few business rules. All it really knows about relations is that all the members must be currently live objects. It implements the business rules by refusing changes outright. The big advantage of that approach is that it allows decentralised addition of new features. Anyone can add a new tag, tag value, or relation type and create clients and, possibly, renderers that use them, without needing a central authority to write code to support them. Currently, it is the editors that implement business rules. Whilst you could have common libraries, JOSM would need a Java one, but other clients would need ones for other languages or platforms. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Deletions and newbie editors
On 06/10/14 09:26, David Woolley wrote: On 05/10/14 22:28, Lester Caine wrote: All achievable if the API monitors the constraints on relations and checks that what JOSM submits is complete. That would represent a radical change in design philosophy. At the moment, the code behind the API (I standards interface) implements very few business rules. All it really knows about relations is that all the members must be currently live objects. It implements the business rules by refusing changes outright. The big advantage of that approach is that it allows decentralised addition of new features. Anyone can add a new tag, tag value, or relation type and create clients and, possibly, renderers that use them, without needing a central authority to write code to support them. Currently, it is the editors that implement business rules. Whilst you could have common libraries, JOSM would need a Java one, but other clients would need ones for other languages or platforms. The decentralised approach only works if ALL the edit tools are able to ensure data integrity. We are now adding a layer of material that can only be created by relations, and if someone is going to have to manually check every one when any changes are added to the general area it can only get worse. Coastline is probably a good example of the problems maintaining continuous relations? That Antje has spent a lot of time creating data which is now being destroyed is the problem and I'd rather see some edits blocked instead of breaking the integrity of other data. I don't see that a test for a constraint ensuring continuity is a block to decentralisation, if only to flag that something does need fixing! This is not a 'radical change' but rather that we now need tools that can handle this secondary layer of material. This may need more tools like the coastline tests but the underlying 'rules' still need to be respected. -- 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
On 05/10/14 21:31, David Woolley wrote: 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. It has been pointed out to me, off list, that the overpass API can retrieve a back-dated version. Although I haven't tried this out yet, this would seem to be the option: http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Attic_data_.28.22date.22.29. ___ 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)
I'd echo Andy's comments, particularly about politely contacting all new users in your neck of the woods. My principal difficulty is in working out what people have done in each changeset. The best tool we had for this - OWL - is now defunct. This let you browse around the area looking at all changesets, seeing features that had been deleted / moved / tagged, getting popups with more info, and being able to go through to the changeset. http://wiki.openstreetmap.org/wiki/OWL It would be wonderful if somebody could resurrect that tool! Regards, Tom On 5 October 2014 23:07, SomeoneElse li...@mail.atownsend.org.uk wrote: 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 -- http://tom.acrewoods.net http://twitter.com/tom_chance ___ 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)
On 06/10/2014 11:30, Tom Chance wrote: My principal difficulty is in working out what people have done in each changeset. The best tool we had for this - OWL - is now defunct. This let you browse around the area looking at all changesets, seeing features that had been deleted / moved / tagged, getting popups with more info, and being able to go through to the changeset. http://wiki.openstreetmap.org/wiki/OWL (just in case people aren't aware) a couple of other options are the OSM history viewer: http://osmhv.openstreetmap.de/index.jsp and Achavi: http://wiki.openstreetmap.org/wiki/Achavi Cheers, Andy ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Deletions and newbie editors
On 06/10/14 10:35, David Woolley wrote: On 05/10/14 21:31, David Woolley wrote: 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. It has been pointed out to me, off list, that the overpass API can retrieve a back-dated version. Although I haven't tried this out yet, this would seem to be the option: http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Attic_data_.28.22date.22.29. The information is available, but as yet there is no joined up method of doing some things. As far as I am aware. That allows you to see the state of the data at a time, but not a view of what exists at that time. If the start_date is correctly added to every object in an area of the map, then by changing the limit created by selecting a particular date, you see a set of data based on that date. This is fine for objects that still exist, but leaves a hole where objects have changed and it is this that OHM is trying to address. Trying to merge data from the current 'filtered' view and some alternate source is the tricky bit. Reading a CURRENT set of data will include the state_date tag and so filtering that can happen locally, but adding the essentially quite small amount of historic changes is not so easy to achieve? -- 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
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
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
2014-10-05 12:11 GMT+01:00 David Woolley for...@david-woolley.me.uk: 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
On 5 October 2014 12:11, David Woolley 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
Re: [Talk-GB] Deletions and newbie editors (was: Vandalism in London)
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] Deletions and newbie editors (was: Vandalism in London)
On Sun, 05 Oct 2014 12:47:29 +0100 David Woolley for...@david-woolley.me.uk 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)
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
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 ian1caldwell+...@googlemail.commailto:ian1caldwell+...@googlemail.com wrote: On 5 October 2014 12:11, David Woolley for...@david-woolley.me.ukmailto: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.orgmailto: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
That should have been DfT in my last sentence. Curse autocorrect! Sent from my iPhone On 5 Oct 2014, at 18:00, Stuart Reynolds stu...@travelinesoutheast.org.ukmailto: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 ian1caldwell+...@googlemail.commailto:ian1caldwell+...@googlemail.com wrote: On 5 October 2014 12:11, David Woolley for...@david-woolley.me.ukmailto: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.orgmailto:Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.orgmailto: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
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 http://wiki.openstreetmap.org/wiki/NaPTAN/Surveying_and_Merging_NaPTAN_and_OSM_data#physically_present ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Deletions and newbie editors
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 http://wiki.openstreetmap.org/wiki/NaPTAN/Surveying_and_Merging_NaPTAN_and_OSM_data#physically_present 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
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 for...@david-woolley.me.uk 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 http://wiki.openstreetmap.org/wiki/NaPTAN/Surveying_and_Merging_NaPTAN_and_OSM_data#physically_present ___ 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
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
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)
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
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)
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
