Re: [Talk-ca] Ottawa import: deleting existing content

[Stewart C. Russell]

On 2017-03-31 10:35 PM, James wrote:
> Your example for building deletion, has 0 building deletion
> 
> https://overpass-api.de/achavi/?changeset=47337186

Ah, linked to the wrong one. This has it:
https://overpass-api.de/achavi/?changeset=47302320

Here's jiminie's original changeset:
https://overpass-api.de/achavi/?changeset=46827970=19=45.42954=-75.63272=B0TTTFT

Near the top is way #480316854, an H-shaped house number 1031.

It's been deleted and replaced with way #483739791 in carpbunker's
changeset 47302320.

The scope of the import was not to delete ways.

 Stewart


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Ottawa import: deleting existing content

[James]

Your example for building deletion, has 0 building deletion

https://overpass-api.de/achavi/?changeset=47337186

On Mar 31, 2017 10:05 PM, "Kyle Nuttall"  wrote:

> From what I've seen, the address interpolations are very inaccurate. The
> ends are not position properly, sometimes there will be odd numbers on an
> even way (and vise versa), sometimes the addresses are backwards, sometimes
> on the wrong side of the street, sometimes both.
>
> 'Okay' data is better than no data but with the actual individual
> addresses now in Ottawa, there's good data that supercedes this bad data.
>
> In my opinion these interpolations are actually making Ottawa worse and I
> question the necessity of them.
>
> Cheers,
> Kyle
>
> On Mar 31, 2017 9:48 PM, James  wrote:
>
> Just an FYI canvec is not the best in Ottawa:
> https://drive.google.com/file/d/0B9ueWCOgxq2GT0JfTkRnb2JXcTQ/
> view?usp=drivesdk
>
>
> On Mar 31, 2017 9:37 PM, "Stewart C. Russell"  wrote:
>
> It seems that some of the import users didn't get the “Don't delete
> stuff” memo. User carpbunker is deleting address interpolation ways
> (example: https://www.openstreetmap.org/changeset/47333119) and existing
> buildings (example: https://www.openstreetmap.org/changeset/47337186).
> Please stop doing that. You need to work around existing contributions.
>
> I'd left changeset comments, but they had not been responded to until I
> threatened to talk this to talk-ca.
>
> The user claims to be deleting "bad address imports", but didn't discuss
> how those previous contributions were bad here before unilaterally
> deciding to delete nodes. Their import-only account is now a mess of
> imports and deletions and will be hard to unpick.
>
>  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

Re: [Talk-ca] Ottawa import: deleting existing content

[Kyle Nuttall]

From what I've seen, the address interpolations are very inaccurate. The ends 
are not position properly, sometimes there will be odd numbers on an even way 
(and vise versa), sometimes the addresses are backwards, sometimes on the wrong 
side of the street, sometimes both.

'Okay' data is better than no data but with the actual individual addresses now 
in Ottawa, there's good data that supercedes this bad data.

In my opinion these interpolations are actually making Ottawa worse and I 
question the necessity of them.

Cheers,
Kyle

On Mar 31, 2017 9:48 PM, James  wrote:
Just an FYI canvec is not the best in Ottawa:
https://drive.google.com/file/d/0B9ueWCOgxq2GT0JfTkRnb2JXcTQ/view?usp=drivesdk


On Mar 31, 2017 9:37 PM, "Stewart C. Russell" 
> wrote:
It seems that some of the import users didn't get the “Don't delete
stuff” memo. User carpbunker is deleting address interpolation ways
(example: https://www.openstreetmap.org/changeset/47333119) and existing
buildings (example: https://www.openstreetmap.org/changeset/47337186).
Please stop doing that. You need to work around existing contributions.

I'd left changeset comments, but they had not been responded to until I
threatened to talk this to talk-ca.

The user claims to be deleting "bad address imports", but didn't discuss
how those previous contributions were bad here before unilaterally
deciding to delete nodes. Their import-only account is now a mess of
imports and deletions and will be hard to unpick.

 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

Re: [Talk-ca] Ottawa import: deleting existing content

[James]

Just an FYI canvec is not the best in Ottawa:
https://drive.google.com/file/d/0B9ueWCOgxq2GT0JfTkRnb2JXcTQ/view?usp=drivesdk


On Mar 31, 2017 9:37 PM, "Stewart C. Russell"  wrote:

> It seems that some of the import users didn't get the “Don't delete
> stuff” memo. User carpbunker is deleting address interpolation ways
> (example: https://www.openstreetmap.org/changeset/47333119) and existing
> buildings (example: https://www.openstreetmap.org/changeset/47337186).
> Please stop doing that. You need to work around existing contributions.
>
> I'd left changeset comments, but they had not been responded to until I
> threatened to talk this to talk-ca.
>
> The user claims to be deleting "bad address imports", but didn't discuss
> how those previous contributions were bad here before unilaterally
> deciding to delete nodes. Their import-only account is now a mess of
> imports and deletions and will be hard to unpick.
>
>  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] Ottawa import: deleting existing content

[Stewart C. Russell]

It seems that some of the import users didn't get the “Don't delete
stuff” memo. User carpbunker is deleting address interpolation ways
(example: https://www.openstreetmap.org/changeset/47333119) and existing
buildings (example: https://www.openstreetmap.org/changeset/47337186).
Please stop doing that. You need to work around existing contributions.

I'd left changeset comments, but they had not been responded to until I
threatened to talk this to talk-ca.

The user claims to be deleting "bad address imports", but didn't discuss
how those previous contributions were bad here before unilaterally
deciding to delete nodes. Their import-only account is now a mess of
imports and deletions and will be hard to unpick.

 Stewart

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Telenav mapping turn restrictions

[Stewart C. Russell]

On 2017-03-31 04:29 PM, Martijn van Exel wrote:
> … 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.

but … but — that's Tagging For The Map, or worse, Tagging To Fix
Software Stupidity. It's explicitly mapping something that's *not*
there, and so is contrary to what we're supposed to map.

I don't have a problem with it being in Telenav's data, but it doesn't
belong in OSM.

 Stewart


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Telenav mapping turn restrictions

[Martijn van Exel]

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

[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
 
,
 http://www.bbc.com/news/technology-37703556 
, 
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 
 

> On Mar 30, 2017, at 6:00 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