[Talk-ca] Telenav mapping turn restrictions

Kevin Farrugia kevinfarrugia at gmail.com
Thu Mar 30 23:37:06 UTC 2017


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.bruseker at 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 <kevinfarrugia at 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.bruseker at 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 at 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-lester at 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 at rtijn.org
>> *To: *"talk-ca" <talk-ca at 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 <scruss at 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 at openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>> _______________________________________________
>> Talk-ca mailing list
>> Talk-ca at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>>
>> _______________________________________________
>> Talk-ca mailing list
>> Talk-ca at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20170330/795412ad/attachment-0001.html>


More information about the Talk-ca mailing list