[Talk-ca] weeklyOSM #349 21/03/2017-27/03/2017

[weeklyteam]

The weekly round-up of OSM news, issue # 349,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8905/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Telenav mapping turn restrictions

[Kevin Farrugia]

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"  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 
> 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"  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  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 

Re: [Talk-ca] Telenav mapping turn restrictions

[Ian Bruseker]

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  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"  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  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 

Re: [Talk-ca] Telenav mapping turn restrictions

[Kevin Farrugia]

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"  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  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 

Re: [Talk-ca] Telenav mapping turn restrictions

[Ian Bruseker]

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  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 

Re: [Talk-ca] Telenav mapping turn restrictions

[Pierre Béland]

Bonjour Martijn
Le problème de navigation que tu mentionnes ne s'explique pas par les données 
OSM. Vous tentatives de régler ces problèmes des logiciels de navigation 
alourdissent inutilement la base OSM. Les cles turn peuvent souvent etre 
utilisées et sont moins complexes que les relations de restriction - voir 
exemples

The navigation problem you present is not due to OSM data. The fixes for 
software navigation problems make the database unecessary more complex, 
especially with restriction relations - See examples.

way=385943816, relation no left turn , junction to a oneway - Why ?
way=385943815, relation no left turn, turn=through key would be simpler

your routing example to turn right, the routing software skips the primary 
link. Why ?
way=172236000, primary link well connected -> routing software problem to fix 
first ?
More routing examples around:
routing software accepts the previous primary link to turn right
https://www.openstreetmap.org/directions?engine=mapzen_car=40.66632%2C-111.86855%3B40.66532%2C-111.86682#map=18/40.66579/-111.86688

routing software accepts to turn left even if a restriction relation on turn 
leftway=385943814, relation 5743391, restriction no left 
turnhttps://www.openstreetmap.org/directions?engine=mapzen_car=40.66632%2C-111.86855%3B40.66641%2C-111.86492#map=18/40.66600/-111.86668

In the opposite direction, the software accepts to turn left on the primary 
linkhttps://www.openstreetmap.org/directions?engine=mapzen_car=40.66503%2C-111.86237%3B40.66532%2C-111.86682#map=17/40.66552/-111.86460
And worst, the software accepts to make a u-turn on the primary links - 
probably adding a simple key turn=through would fix this.
https://www.openstreetmap.org/directions?engine=mapzen_car=40.66503%2C-111.86237%3B40.66608%2C-111.86699#map=18/40.66574/-111.86540
 Pierre 


  De : Martijn van Exel 
 À : Andrew Lester  
Cc : talk-ca 
 Envoyé le : jeudi 30 mars 2017 11h51
 Objet : Re: [Talk-ca] Telenav mapping turn restrictions
   
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=40.66610%2C-111.86760%3B40.66386%2C-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 

Re: [Talk-ca] Telenav mapping turn restrictions

[Martijn van Exel]

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=40.66610%2C-111.86760%3B40.66386%2C-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  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