Well, if distances are similar but peed limits are different, the router may prefer to go with the similar length route because it has a higher speed limit. Another case could be if the algorithm prefers the more major road classification over the lower classified road in the hierarchy, it could avoid the _link in order to satisfy it's hierarchy preferences.
-Kevin On Mar 30, 2017 7:29 PM, "Ian Bruseker" <ian.bruse...@gmail.com> wrote: > Kevin, > > That does make sense, but in the example Martijn gave, the starting point > is well before the turning lane, so I'm picturing the car being there and > the software still having time to make a choice which road to send it down. > Why did OSRM pick to ignore the turning road given there is all the > opportunity in the world to choose it instead of the actual intersection > corner? > > Ian > > > > On Mar 30, 2017, at 5:19 PM, Kevin Farrugia <kevinfarru...@gmail.com> > wrote: > > Hey Ian, > > The main purpose is to stop silly or dangerous things from happening. If a > user misses their turn and the engine reroutes them to turn right where > they shouldn't (or U-turn) the consequences could be catastrophic. When > people are following a computer's instructions they'll follow them blindly > (like when Michael drives his car into a lake in The Office). > > Plus if there's some weird error in the road topology or speed differences > that could cause it to happen it's best to have them there as a catch. > > That's my view/reasoning from my experience working with routing and > networks anyways. > > -Kevin (kevo) > > > On Mar 30, 2017 7:02 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> 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_c >> ar&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> 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 (viewed with >> Achavi: 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 >> *To: *"talk-ca" <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> >> 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 >> > https://lists.openstreetmap.org/listinfo/talk-ca >> >> >> _______________________________________________ >> Talk-ca mailing list >> Talk-ca@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-ca >> >> >> >> _______________________________________________ >> Talk-ca mailing list >> Talk-ca@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-ca >> >> > > _______________________________________________ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca > > >
_______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
