Thanks. > can you share the ids of the objects in your query that meet your dual > criteria of "kerb=raised added by SC, barrier=kerb added by iD?"
There are 1,059 nodes that meet these criteria (or met them when I last ran the script to identify them). You can find 100 examples here: https://community.openstreetmap.org/t/proposed-edit-of-some-barrier-kerb-kerb-raised-nodes/98038/13 Discourse won't let me add the full list to the forum post but I'll email it to you. I have checked a lot of them. I am fairly sure that all of them are indeed mistakes. For example, the example you give (https://www.openstreetmap.org/node/9407931159) is not on that list because it does not conform to the pattern described (SC adds kerb=raised, iD adds barrier=kerb). > - a complete error (often a wrong position) -> removing barrier=kerb tag is > ok but keeping kerb=* mean that someone will have to go over these objects > again > https://www.openstreetmap.org/node/2405171 > this is a good example of the problem I am talking about > you removed barrier=kerb and that is a correct removal > but the main tag is still missing: if people cross the road at this point > (given the connecting paths on both sides of the road), it's clearly > highway=crossing > if it is deemed not to be a highway=crossing because there is another one > nearby, then the paths crossing the road should be modified to use the > existing pedestrian crossing https://www.openstreetmap.org/node/2665802262 > so in the end, the node is still erroneous: what does kerb=raised refer to > here? it's still not maped, so every data user would have to play the > guessing game between "there is a missing barrier=kerb" affecting vehicles" > and "there is a missing highway=crossing" and "error there is nothing" What I am proposing is essentially to revert these nodes to their previous state: after someone added kerb=raised using StreetComplete, but before someone else added barrier=kerb. So yes, these 1,059 nodes will be left with kerb=raised. But there are already about 5,000 nodes with kerb=raised on roads (https://overpass-turbo.eu/s/1unD), most of them added by StreetComplete. More such nodes are being created all the time. For all of these nodes, the data consumer has to play the guessing game you describe. Therefore I agree with you that kerb=raised is ambiguous and not the best solution to say that there is a kerb on each side of a road at this point. In my view, something like sidewalk:both:kerb=raised would be better. Others have used kerb:location=footway. Others suggest crossing=informal (because there are objections to tagging points as crossing=unmarked where there is no crossing infrastructure). There are countless possible solutions, and there is an ongoing discussion with the developer of StreetComplete here: https://community.openstreetmap.org/t/tagging-kerbs-on-crossings/9290/24 Please contribute your thoughts to that discussion. Once there is a consensus, we can think about a separate mechanical re-tagging of the nodes that have been tagged kerb=raised by StreetComplete. > if we aim for quality, there is no urgency That is true, there is no rush, and of course I won't proceed as long as there are concerns. The reason I am motivated to fix these nodes soon is because they lead to routing issues in routers that (correctly, in my view) avoid routing vehicles over barrier=kerb. See the examples at https://community.openstreetmap.org/t/barrier-kerb-kann-zu-routing-problemen-fuhren-osrm/97348. The discussions on this topic have been going on since February (https://community.openstreetmap.org/t/tagging-kerbs-on-crossings/9290). Therefore I think that we can safely remove barrier=kerb from the 1,059 nodes now and that will solve the immediate routing issues for routers that trust that barrier=kerb means that there is a kerb across the road. Once we have decided what to do with the 5,000 or so + 1,059 nodes with kerb=raised - this probably requires a longer discussion - we can then discuss separately what to replace that tag with. What do you think? _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
