Ian -- I think your general logic is flawless -- it's just that there is more information in play that informs a routing engine's decisions that may be less obvious or even outside of the realm of OSM. One example is live traffic data: if the _link shows as having a current speed of, say, 10kph and the non _link turn shows a current speed of 30kph the engine may decide, lacking an explicit restriction, to take the non _link turn because it's faster even if that is an illegal turn. That is why we need these restrictions to be explicit in the data.
Also, as Kevin already pointed out, routing engines don't have 'common sense' like (most..) humans do. When a human in a car drives up to an intersection like Pierre's example http://www.openstreetmap.org/relation/5743392#map=19/40.66600/-111.86704 <http://www.openstreetmap.org/relation/5743392#map=19/40.66600/-111.86704> she will never make a U turn there [1]. No sign exists there but just human common sense (and hopefully some knowledge of traffic laws!) will inform that decision. A routing engine would have no qualms whatsoever suggesting that turn though! That's why they need to be made explicit to get routing results that don't get people into trouble or worse [2]. This all may seem to add complexity to the map. I understand that. I like to keep things as simple as possible as well [3]. This is however the reality of a growing OSM in general, and extends beyond the navigation use case. As more people use OSM in different ways there will continue to be extensions to the tagging system. As a community we need to ensure that any new tagging makes logical sense and does not make things unnecessarily complex. I hope this helps clarify a bit! Martijn [1] See the OSC image: http://openstreetcam.org/details/1170/292 <http://openstreetcam.org/details/1170/292> [2] Not to freak you out but this problem is real and people have gotten in really bad situations because of a combination of lacking data and poor judgement: https://news.vice.com/story/gps-blamed-for-sending-trucks-crashing-into-this-tiny-arkansas-town <https://news.vice.com/story/gps-blamed-for-sending-trucks-crashing-into-this-tiny-arkansas-town>, http://www.bbc.com/news/technology-37703556 <http://www.bbc.com/news/technology-37703556>, http://www.npr.org/2011/07/26/137646147/the-gps-a-fatally-misleading-travel-companion <http://www.npr.org/2011/07/26/137646147/the-gps-a-fatally-misleading-travel-companion> [3] Using turn tags on ways instead of turn restriction relations, like Pierre suggested, may seem simpler at first but can easily become more complex than adding turn restrictions if you follow the guidelines fully.. See http://wiki.openstreetmap.org/wiki/Key:turn#Turning_indications_per_lane <http://wiki.openstreetmap.org/wiki/Key:turn#Turning_indications_per_lane> > On Mar 30, 2017, at 6:00 PM, Ian Bruseker <ian.bruse...@gmail.com> wrote: > > Martijn, > > Can I ask what is possibly a really dumb question? As stated earlier I'm not > a lawyer, and really in truth I'm no cartographer either. I generally stick > to adding POIs for stores in local stripmalls, because that's not too > dangerous to the map. ;-) Not being an expert in mapping, I probably just > don't get why routing software works the way it does. Why, in your example > that you gave, would OSRM (or Scout) choose to send the user to the corner to > turn at all? I just don't get the logic of it. The code seems pretty > obvious (what I really am, after all, is a computer nerd). In silly > pseudocode: "if exists link-type road between current_location and > destination, route via link road". Why would it even look far enough ahead > to see the corner to see whether there was a turn restriction or not, when > there is already a more obvious path to take? I mean, "obvious" to me as a > human, I guess. If I were driving down a road I'd never been to, and my > passenger said "ok, take your next right", and I saw a turning > lane/ramp/something, that's where I would go. Shouldn't that be the routing > software's first choice? If it's looking far enough ahead on its path to > even get to "you can't turn right here", then I would think its next step > would be "ok, you can't turn right here, so I'll need to take them to the > _next_ place they can turn right and route them back around the block to the > road they want", not to then look backwards from the turn restriction to see > if there was a linking road it could take instead. The choice should have > been made to take the linking road before it even cared whether it was > allowed to turn them at the hard corner ahead, which would make putting the > restrictions on the map for the purpose of "routing hint" sort of > unnecessary, wouldn't it, if the software had just picked the correct route > the first time? Or worse, if they are there and the routing software hits > them, wouldn't they then result in even longer routes, because once it got > that far down the path, the only way to look is forward, which is a longer > path? I don't mean to tell you how to write your software. ;-) Like I said, > I don't actually know how routing software is coded. And I'm sure you've > considered this. I'm just curious, given that consideration, _why_ would > that route even happen in the first place (to take the hard corner rather > than the link road)? > > Sorry if I'm derailing this discussion. I don't touch the road network too > much in my mapping unless I am pretty sure what I'm changing is obviously > correct and simple, and I avoid weird intersections as much as possible. I'm > just curious to understand, so maybe in the future if I happen across such a > situation, I'll have some idea how to map it so it doesn't send a driver > making a dangerous turn or crashing through a fence or something. ;-) > > Thanks, > Ian > > > On 30 March 2017 at 09:50, Martijn van Exel <m...@rtijn.org > <mailto:m...@rtijn.org>> wrote: > Hi Andrew (and let me reply to Pierre's comments too, sorry Pierre, I am a > little slow parsing French). > > First off thanks for your additional comments, they are really useful. I > realize that I should have shared more detail about what we are planning to > do and will do a better job in the future if new projects arise. We are > actually working on a Github repository (similar to Mapbox's) where we will > share more details about mapping projects and where everybody will be able to > talk to the team about what we do. Of course we will continue to post here as > well. > > We do have a serious onboarding process for new mappers on our team where > more experienced mappers guide the newcomers and introduce them to the OSM > ecosystem. So they are not quite thrown in the deep end, but like everybody > else they go through a learning process where they make simple edits first. > We don't ever use live OSM data for pilot or test projects. > > I don't feel there's a consensus about the turn restrictions in places where > they are not marked. There are really good (routing / safety related) reasons > for this as I pointed out before [1] and in my research I have found many of > these in the U.S. as well, but until that is cleared up we will not add any > more. This includes the left turn restrictions Pierre mentioned. To Pierre's > comments, I don't think that there's really an easier way to map this, turn > restrictions have been discussed in the community at length and other > solutions not based on relations just don't scale well to complex situations. > > The Bing imagery alignment issue is one that we have not given proper > attention and I will impress upon the team that they should pay really close > attention to this and be even more restrained in modifying local mappers' > work. I seem to remember there is a site / place that lists offset issues > with Bing imagery by region? Is there a good source to look at for this? > > I'm thinking it would be good to hold an online town hall where some of our > team members and myself can answer any questions and discuss the issues > raised? If you're interested in this let me know off-list and we can set up a > time. > > Thanks again for your feedback and willingness to work on this with me and > the team. We really do want to improve the map for everyone and we will be > taking this as an opportunity to do significantly better. > > Martijn > > [1] Look for example at this situation where there is no turn restriction on > an intersection with a _link road and OSRM does not route over the _link > road. > https://www.openstreetmap.org/directions?engine=osrm_car&route=40.66610%2C-111.86760%3B40.66386%2C-111.86464#map=18/40.66520/-111.86552 > > <https://www.openstreetmap.org/directions?engine=osrm_car&route=40.66610,-111.86760;40.66386,-111.86464#map=18/40.66520/-111.86552> > It is these kinds of (potentially unsafe) situations that we are really > looking to prevent, not only for Scout users but for all routing software > using OSM. (This is in the US not in Canada but the situation could occur > anywhere.) > >> On Mar 29, 2017, at 11:14 PM, Andrew Lester <a-les...@shaw.ca >> <mailto:a-les...@shaw.ca>> wrote: >> >> Hi Martijn, >> >> Thanks for your comments. Yes, I have commented on relevant changesets, >> though not every one I've come across. To be honest, there are far too many >> problematic changesets to start discussions on all of them. >> >> In using some QA tools to fix other problems, I've come across further >> instances of what could best be described as "sloppy" edits. For example, >> adjustments to road alignments to align them with Bing, but obviously with >> no attempt to properly align the imagery first. Bing is off by 15-20 metres >> in much of southern Vancouver Island outside of downtown Victoria, and I've >> seen some roads being moved that much out of place. Here's an example >> changeset: https://www.openstreetmap.org/changeset/46740353 >> <https://www.openstreetmap.org/changeset/46740353> (viewed with Achavi: >> https://overpass-api.de/achavi/?changeset=46740353#map=16 >> <https://overpass-api.de/achavi/?changeset=46740353#map=16>). I see the >> source "Geobase roads" has been listed as being used as part of the edits, >> which actually reflects the correct alignment, but this seems to have been >> ignored in favour of the poorly-aligned Bing imagery. In addition, I've >> found a number of edits by Telenav members creating or moving highways such >> that they cross footways without an intersecting node, which indicates that >> the JOSM validator isn't being used before uploading the changes. >> >> In my opinion, based on what I'm seeing, the Telenav members don't have >> enough experience with the OSM ecosystem, tagging/mapping conventions, or >> editing tools to be making such widespread and prolific changes. I would >> strongly recommend that these members focus on mapping a local area that >> they can visit in person in order to gain experience with all aspects of >> actual on-the-ground mapping, and then later begin expanding to the rest of >> the country. Right now it seems like they're being thrown into the deep end >> with the hope that they'll just figure things out, and we're having to deal >> with the mess they're creating. I'm sure they mean well, but they just >> aren't qualified to be making the nationwide changes they are currently. I >> also strongly recommend that detailed proposals are brought to this >> community's attention before widespread tagging changes are made, such as >> the creation of tens of thousands of restrictions as detailed by Pierre. It >> would be good to confirm that the team is going to be making useful and >> correct changes before actually going ahead, just in case there's a better >> way of tagging/mapping things that the team wasn't aware of. >> >> As for the right-turn restrictions that I brought up earlier, I've posed the >> question of the legality of these right turns to a couple of sources (one >> that's pretty official) and am just waiting on a response. I hope to have >> one soon. This will only apply to BC, but it might help indicate whether the >> laws need to be investigated for other provinces as well. >> >> Andrew >> >> From: m...@rtijn.org <mailto:m...@rtijn.org> >> To: "talk-ca" <talk-ca@openstreetmap.org <mailto:talk-ca@openstreetmap.org>> >> Sent: Monday, March 27, 2017 9:08:26 AM >> Subject: Re: [Talk-ca] Telenav mapping turn restrictions >> >> Hi all, >> >> Thanks for your thoughtful commentary. >> >> First off, our mapping team’s only objective is to improve the map for us >> and for everyone. In doing this we always respect the work of local mappers, >> and follow community conventions. None of our edits are automated. There is >> a person using JOSM behind every changeset, so if you observe something >> untoward, please comment on the changeset so we can learn, discuss or undo >> if necessary. >> >> Some of our mapping team members are on this list and they can (and will) >> explain a bit more about how (and why) we add turn restrictions. >> >> I make a point to announce any new mapping projects we start to the local >> mailing lists (like I did when I started this thread). If there is anything >> we can do to be more open about our mapping projects I would be eager to >> discuss with you. >> >> Again, if you have specific concerns about edits any of our team members >> make in your local area, please! raise them in the changeset comments. It’s >> the single most effective way for us to learn how to to do better. Members >> of our mapping team are always identifiable by their usernames ending in >> _telenav. >> >> Martijn >> >> > On Mar 26, 2017, at 7:45 PM, Stewart C. Russell <scr...@gmail.com >> > <mailto:scr...@gmail.com>> wrote: >> > >> > Hi Andrew: >> > >> >> … I had already removed some of the >> >> right turn restrictions, but I can add them back in >> > >> > Are the restrictions even necessary? If there are turn lanes present, >> > one should use them. I can see, however, that routing software might >> > send vehicles through the traffic lights if the turn lane were a longer >> > route. I wonder if Telenav are tagging to work around their routing >> > algorithms? >> > >> >> There's still the matter of armchair mapping wiping out on-the-ground >> >> mapping. >> > >> > Yes, this is troubling to me too. Have you left comments on the >> > changesets? Telenav's actions need to be brought out into the open. >> > >> > I'm really not looking forward to seeing what all this algorithmic >> > mapping's going to do with Canada's logging roads ... >> > >> > Stewart >> > >> > >> > _______________________________________________ >> > Talk-ca mailing list >> > Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org> >> > https://lists.openstreetmap.org/listinfo/talk-ca >> > <https://lists.openstreetmap.org/listinfo/talk-ca> >> >> >> _______________________________________________ >> Talk-ca mailing list >> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org> >> https://lists.openstreetmap.org/listinfo/talk-ca >> <https://lists.openstreetmap.org/listinfo/talk-ca> > > > _______________________________________________ > Talk-ca mailing list > Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org> > https://lists.openstreetmap.org/listinfo/talk-ca > <https://lists.openstreetmap.org/listinfo/talk-ca> > >
_______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca