Re: [Talk-ca] Building Import

[Andrew Lester]

I disagree. Silence won't solve anything. 

I'm speaking here as a local BC mapper, and I strongly disagree with these 
recent imports. I thought we had a general consensus that we'd discuss this as 
a community and figure things out before restarting the import, but it seems 
that some mappers don't like having to wait or deal with other people. 
Considering that Danny seems to consider orthogonal buildings to be outright 
wrong (a position that I strongly disagree with and I think some others do 
too), there's clearly still some discussion required before imports can be 
started again. Sure, you could go ahead and import anyway contrary to other 
community members' wishes, but that sure won't make you any friends and you run 
the risk of having your changesets reverted if the data quality is too poor or 
violates the import guidelines. 

Please, please, please, let's hammer things out first before we import any of 
this data. The buildings aren't going anywhere, so there's no need to rush poor 
data into the database. If you're itching to map some things, go for a walk and 
map some addresses and businesses near you. 

Andrew 
Victoria, BC, Canada 



From: "Danny McDonald"  
To: "talk-ca"  
Sent: Friday, March 15, 2019 8:48:55 AM 
Subject: Re: [Talk-ca] Building Import 

OK, so this discussion has gone a bit off the rails. In terms of the DWG, this 
has all happened so fast - the referral to the DWG was less than 2 hours after 
the initial message, and was not in response to any actual edits I made after 
receiving Pierre's stop message. 
I suggest that we all stop emailing this list for the rest of the day, given 
the high level of tension on both sides. I will not be importing anything for 
the next week (at the very least), and I don't think anyone else will either. 
DannyMcD 

___ 
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] 2020 building import wiki comment by Nate Wessel

[Andrew Lester]

I was surprised this morning when I saw that a chunk of buildings had been 
imported in Victoria, BC. The changeset linked to the wiki plan and I then 
checked my email and saw this email chain. 

The "local" (in this case the Canadian community) has not been sufficiently 
consulted. Looking back in the mailing list, there were some tangential 
discussions about some things related to this import (mostly without any final 
consensus), and then a single email stating that the import plan had been 
created and sent off to the imports list 
(https://lists.openstreetmap.org/pipermail/talk-ca/2018-November/008864.html). 
After that, nothing. I can't find any emails related to this import that were 
linked to both the imports and talk-ca list, nor are there any that bring back 
the results from the imports list for those who aren't following that. There 
also wasn't any notification that the import was actually going ahead. I'd 
consider all of this to be a major failure of the "Community Buy-in" section of 
the Import/Guidelines. 

For such a major import, we should be going above-and-beyond to make sure every 
possible aspect has been addressed adequately. The lack of confidence from the 
general OSM community as a result of the botched import in Ottawa and the 
ongoing dislike of our CANVEC imports means we need to treat this import with 
kid gloves. We should be striving to ensure that there's no reason why someone 
could look at this import and find faults with it. That may seem like a lofty 
goal, but we're talking about a building import for the second-largest country 
in the world. 

Once the administrative portions are dealt with and the community has been 
sufficiently consulted, the technical area needs to be looked at. Now that I've 
seen some of the data in action, there are various issues that need to be dealt 
with. Some that became immediately apparent on the data imported in Victoria, 
BC include: 
-A significant number of unsquare buildings (JOSM validator reports this as an 
Other/Building with an almost square angle). Of an estimated 935 buildings in 
this chunk, 692 have almost-square angles. Looking more closely and running the 
JOSM Orthogonalize tool on a sampling of buildings, I believe all of them have 
unsquare angles. This may be the result of rounding errors in data conversion 
and should be fixed in the source data before importing. 
-Inconsistent tagging (some houses are building=yes, some are 
building=detached) 
-A need for simplification (extra nodes in nearly-straight segments that are 
straight in reality) 

I'd suggest the following plan: 
1. Update the tasking manager to indicate in clear terms that this import is on 
hold and no data should be imported at this time. Ideally, the tasking manager 
should be taken down entirely so no data can be imported. 
2. Send a clear, unambiguous email to the talk-ca list indicating that this 
import is being planned and to solicit feedback. 
3. Wait. THIS IS IMPORTANT! The community needs to be given time to see that 
this import is being planned, and to discuss the many aspects related to it. 
For such a major import, silence-as-tacit-acceptance doesn't fly. There are 
local communities out there that need to be brought in to the process. If 
necessary, figure out who the active contributors are in various jurisdictions 
and contact them directly. 
4. Figure out the technical details. It's only after the import had already 
started that people are now talking about conflation and data quality. These 
need to be figured out, a plan documented, and the source data cleaned. Tags 
also need to be clarified. The current wiki plan gives almost no guidance about 
how to actually perform the import. 
5. Only after all of the above has been figured out, let the community know 
that the import is actually going ahead. 

Come on, people. We can do a lot better than this, and definitely should. Let's 
make this a shining example of why imports can be a good thing for OSM, not 
provide fodder for those opposed to them. 

Andrew Lester 
Victoria, BC 


From: "John Whelan"  
To: "Nate Wessel"  
Cc: "talk-ca"  
Sent: Saturday, January 19, 2019 5:07:52 AM 
Subject: Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel 

I'm saying when the matter was first raised on the import mailing list as a 
heads up I made reference to the existing Ottawa pilot and gave a link 
basically saying we would be following the same pattern. There was considerable 
discussion around the Ottawa import plan both on the import plan and talk-ca 
and the Ottawa import which I didn't draw up. Later there was a formal link to 
the data import plan. 

So two stages if you like. This is what we are thinking of doing and this is 
how we intend to proceed. 

Cheerio John 

Nate Wessel wrote on 2019-01-18 11:38 PM: 




John, 


I'm sorry to keep saying this, but I really do not think this is an acceptable 
import ap

Re: [Talk-ca] canvec imports

[Andrew Lester]

I agree. A selective import from CANVEC is fine and generally gives good 
results. As long as you don't import things like forests and buildings (which 
are both woefully out-of-date, broken, or outright wrong), there usually isn't 
a problem. However, if someone just imports an entire block of data without 
inspecting it, that's when we run into the visible issues that the peanut 
gallery picks apart. 

Andrew 
Victoria, BC 


From: "James"  
To: "Andrew"  
Cc: "talk-ca"  
Sent: Tuesday, November 27, 2018 9:58:19 AM 
Subject: Re: [Talk-ca] canvec imports 

not sure why Canvec always gets shat uppon, their water features are great and 
pretty accurate, the forest/landcover on the other hand needs fixing before 
import. I think it's clear enough on the canvec wiki page that only experienced 
mappers/importers should attempt a canvec import. 

On Tue., Nov. 27, 2018, 12:54 p.m. Andrew < andrew.alli...@teksavvy.com wrote: 


FYI Canada 

I made a few imports to canada a while ago and apparently 
raised the ire of someone. 

Here we go again :-( 

--- 
This was the first message 

>>Please, fix issues caused by this changeset for example in region of 

Yup, that was it, I was like ok, whats wrong with the changeset? Found 
an overlapping way. Figured that was it :-) 

And now 

Where is documentation page of this import? Can you link to discussion 
done before this import started? 

And So On. 

--- 
Hi PurpleMustang, 

XXX X has sent you a message through OpenStreetMap with the 
subject Re: Canvec Import: 

XXX X 
On 2018-11-27 17:21:34 UTC PurpleMustang wrote: 

Hello: This import has been a work in progress for about 10 years now 
:-) 

https://wiki.openstreetmap.org/wiki/Import/Catalogue 

https://wiki.openstreetmap.org/wiki/Geobase/Announcement 

Andrew 

Note that currently active import should have a wiki page describing 
what exactly is imported and how data is processed - see 
https://wiki.openstreetmap.org/wiki/Automated_ 

 

Oh Well Here we go again 

Andrew 
aka CanvecImports 


___ 
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

Re: [Talk-ca] Exit with name on node *and* destination

[Andrew Lester]

I just cleaned up a handful of junctions in the western provinces where refs 
were in the name tag, destination was in the name on the junction in addition 
to the link way, etc. Running an Overpass query for all of Canada 
(http://overpass-turbo.eu/s/DrL) now shows that there are almost 2000 of these 
in Ontario and Quebec, 2 in Nova Scotia, and 1 in Newfoundland. The last 3 look 
legitimate, but a quick scan of the ones in Ontario and Quebec shows that most 
are clear tagging-for-the-renderer. In a few test cases, the destinations are 
already on the link ways, so there's no need for the destination to be in the 
name on the junction nodes. 

Does anyone have a good reason for keeping these as they are? My opinion is 
that these should all have the names removed when it's clearly the destination, 
and that this destination info should be added to the link way if it isn't 
already. 

Andrew Lester 
Victoria, BC 


From: "Martijn van Exel"  
To: "talk-ca"  
Sent: Tuesday, November 6, 2018 7:56:23 AM 
Subject: Re: [Talk-ca] Exit with name on node *and* destination 

So apparently this is pretty common practice in Quebec. There are 755 junction 
nodes that have name tags. See https://overpass-turbo.eu/s/Dr9. Other provinces 
don't have nearly that many. 

The user breakdown for latest edit on those nodes doesn't really surface one 
mapper who consistently added these tags. See https://overpass-turbo.eu/s/Drf 

I'm inclined to leave it to the local Quebec community to say something more 
definitive about what, if anything, needs to be done with these name tags... 
I'm happy to set up a MapRoulette challenge to enable us to systematically look 
at these nodes.. 

Best, 
-- 
Martijn van Exel 
m...@rtijn.org 

On Tue, Nov 6, 2018, at 08:33, Martijn van Exel wrote: 
> Is there an Overpass or other query that could detect all these 
> situations? I could make a MapRoulette challenge out of them so we can 
> look at them together and remove the name on nodes where it's not 
> appropriate / redundant. 
> 
> I'll ask on IRC as well.. I am not that much of an expert in Overpass. 
> -- 
> Martijn van Exel 
> m...@rtijn.org 
> 
> On Mon, Nov 5, 2018, at 18:23, Jarek Piórkowski wrote: 
> > Yep, so in this case removing the name and keeping the ref on the 
> > junction node sounds appropriate. 
> > 
> > While we're at it, the service road 
> > https://www.openstreetmap.org/way/48154169 doesn't seem to show up on 
> > any of the current imagery in iD. Does it still exist? 
> > 
> > --Jarek 
> > 
> > On Mon, 5 Nov 2018 at 16:28, Pierre Béland  wrote: 
> > > 
> > > Je disais précédemment 
> > > > Je ne sais pour les autres provinces, mais au Québec les no. de sorties 
> > > > correspondent aux bornes kilométriques de la route (ici 15 pour km 15). 
> > > > Il est plus informatif d'afficher le no de sortie (ref=15) 
> > > 
> > > 
> > > Ici c'est sortie 11pour km 11, et non 15 comme j'ai dit précédemment. Sur 
> > > la carte, la numérotation de la sortie était «noyée» sous le texte. 
> > > 
> > > 
> > > Pierre 
> > > 
> 
> ___ 
> 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

Re: [Talk-ca] Dartmouthmapmaker

[Andrew Lester]

I'm not sure how helpful that article would be, considering that it focuses on 
building tagging, but this user is primarily working on admin boundaries and 
highways. 

John, I'm surprised that you were able to successfully have a discussion with 
them. A number of other contributors have tried to communicate with them 
through various means, but they either didn't respond or responded in a way 
that demonstrates they clearly don't understand what's happening. The fact that 
they refused to communicate is what led to the current block, and I'm not 
confident that they'll suddenly change their ways once the block ends. I guess 
we'll see what happens in a couple of days. 

Andrew Lester 
Victoria, BC 


From: "OSM Volunteer stevea"  
To: "john whelan" , "talk-ca" 
 
Sent: Thursday, November 1, 2018 9:54:40 AM 
Subject: Re: [Talk-ca] Dartmouthmapmaker 

Being as gentle (though not local) as I can be, I continue to assert that our 
wiki for BC2020 in general and 
https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Building_Canada_2020#The_data_that_could_be_mapped
 as a specific section IN that wiki (calling attention to these tags, with 
hundreds of potential values): 

building 
man_made 
addr 
start_date 
entrance 
amenity 
and others 

might prove very helpful starting points. Often the simple act of reading OSM's 
built-in wiki documentation is one of the best, if not THE best starting point. 
Of course, talk- mailing lists, our forum and many other sources of 
advice/documentation/help are available, too. 

Regards. 
SteveA 
California 

> On Nov 1, 2018, at 9:40 AM, john whelan  wrote: 
> I've discussed the Open Data side with them but I think they could do with a 
> bit of guidence on the tagging side. Could someone ideally more local than I 
> point them gently towards map features and more standard tagging? 
> 
> I must confess my knowledge of tagging is a little limited to highways and 
> buildings. 
> 
> I get the impression they are open to dialog if treated gently. 
> 
> Thanks John 
> ___ 
> 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

Re: [Talk-ca] Nova Scotia imports, and boundary=land_area

[Andrew Lester]

Hi Frederik, 

What this mapper is doing is not usual or desired. As you've seen by the 
changeset discussions and edit wars, the general OSM community does not agree 
with the way they're doing things. I sent them a message a few days ago 
pointing out a number of the issues you listed and suggesting that they take a 
break from adding new data to go back and fix these issues, but I see that 
they've continued to import with the same issues, and they haven't replied to 
my message. Based on what I've seen and read, I suspect: 
1. They only have a basic understanding of OSM, and certainly not enough 
knowledge or experience to be making the type of mass-edits they are. 
2. They may be mapping for the specific purpose of Garmin GPS map use, and as a 
result are misusing tags to fit that usage rather than changing their Garmin 
map generation process. 
3. They may not even be living in Nova Scotia (some of what I've read implies 
that they're mapping remotely and English may not be their primary language). 

At this point, I think it might be a good idea to have the DWG step in. Clearly 
this mapper isn't going to stop what they're doing based solely on 
communication from other mappers. It's already going to take a while to clean 
up the mess they've made, so we need to stop the creation of even more mess. 

Andrew Lester 
Victoria, BC, Canada 


From: "Frederik Ramm"  
To: "talk-ca"  
Sent: Sunday, October 21, 2018 6:18:24 AM 
Subject: [Talk-ca] Nova Scotia imports, and boundary=land_area 

Hi, 

there's a mapper in Canada - Darthmouthmapper - who seems to: 

1. import data from a source he calls "Nova Scotia Open Data" - I am not 
aware of any imports discussion, and the source specification is not 
precise enough to determine the legal status of that. Judging from past 
changeset comments, whatever imports procedure is used must have a 
number of flaws. 

2. import administrative boundaries 

2a. as a mesh of closed ways (where most people would prefer relations), 

2b. with, among other things, the tags "_Shape_Area_=yes", 
"addrcountry=Canada" (no colon!), "addr:postcode" (which is not 
generally used for objects that do not represent an address), and 
"type=land_area" (which is not generally used on closed ways). 

2c. The combination of a level-8 admin boundary and place=village is 
also unusual (eg https://www.openstreetmap.org/way/616463020) but I 
cannot judge if this is normal in Canada. This is also used in 
residential areas https://www.openstreetmap.org/way/636390857 - is this 
area really a "village"? 

3. use a ton of is_in tags which are highly unusual nowadays 

4. occasionally change existing relations (not ways) from type=boundary 
to type=land_area (https://www.openstreetmap.org/relation/8417484/history) 

5. add addr:postcode and addr:province to place=village nodes 

6. revert corrections applied to this by other users, claiming that "The 
video and instructions state these can be part of the ways" 

A number of people have complained in the past 
http://resultmaps.neis-one.org/osm-discussion-comments?uid=698649 
but many of the issues seem to be present still. 

Before I ask him to fix this -- are any of the behaviours / mapping 
techniques outlined above somehow usual in Canada? 

Bye 
Frederik 

-- 
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" 

___ 
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] Trans-Canada Highway research

[Andrew Lester]

While standardization may be nice, it often won't be possible even within a 
single country. As has already been discussed, there are differing conventions 
in different provinces, so please don't try to apply a single plan to all 
provinces. How the TCH is handled in OSM will vary depending on the province. 

For example, in BC (and some other western provinces), the TCH carries the 1 
ref. In some places where other ref'ed highways coincide with the TCH, the ref 
is recorded as "ref=1;19", for example. There are places within cities where 
the TCH runs on city roads with different names (e.g. Douglas Street in 
Victoria), so those ways are named with the local name and the TCH name is 
recorded in the alt_name or nat_name tag (a separate argument is which one of 
these to use). An alternate name should never be added to the primary name in 
brackets like proposed. That's exactly what the alt_name (and similar) tags are 
for. There are also many places where Trans-Canada Highway is the official 
local name of the road, like most of the highway in BC. 

As for the correct spelling of the TCH, I think it would be fairly 
uncontroversial to standardize the name to "Trans-Canada Highway" or "Route 
Transcanadienne" where it's appropriate to use the TCH name, because those are 
the official spellings. Any variants can be considered errors. 

As for varying highway classifications, this is correct and to be expected. 
Unlike the US interstate system, the Trans-Canada Highway network varies in 
construction and importance all across the country, so the classification can't 
be standardized to just motorway or trunk. There are sections where primary is 
the most appropriate, and possibly even secondary in some places. Just on 
Vancouver Island alone, the roads designated as the TCH vary from a six-lane 
motorway all the way down to a two-lane effectively-tertiary road. 

Since there will need to be a lot of local knowledge required for such a 
project, I strongly recommend that this project not be undertaken by Telenav. 
This is the kind of work that Canadians should be doing, being the most 
familiar with the on-the-ground situation which will dictate how the highway is 
handled in each province. The numerous past issues with Telenav's contributions 
is also a factor that can't be ignored. Does it really make sense for a team of 
Romanians with a history of questionable decisions to be making sweeping 
changes to the Canadian national highway network? At least they've brought a 
proposal to the community this time rather than just push forward with a faulty 
plan like they have in the past. I'm still cleaning up after previous Telenav 
projects in my area that added countless non-existent turn restrictions and 
names and also removed valid data. 

Andrew 
Victoria, BC, Canada 


From: "Olivia Robu - (p)"  
To: "talk-ca"  
Sent: Monday, March 26, 2018 4:20:16 AM 
Subject: [Talk-ca] Trans-Canada Highway research 



Hello, 

The Telenav Map team has done some research on the status of the ways and 
relations of Trans-Canada Highway. 

Here are some conclusions from this research: 

* The highway is formed from 30 routes; 
* Every route has different names for the name tag, such as: street names, 
other routes names or Trans-Canada highway name in different forms; 
* The issue above is repeating for the ref tag; 
* The name of Trans-Canada highway has more than one form (Trans-Canada 
Highway, TransCanada Highway, Trans Canada Highway, etc); 
* Another issue is the variety of names in other tags related to it (such 
as: name:en, name:fr, alt_name, alt_name:en, alt_name:fr, nat_name); 
* There are some routes that don’t have a route name only ref (5 routes); 
* There are some routes that overlap: 
* in Manitoba: - PTH 1 (MB Trans-Canada Highway) and Trans-Canada 
Highway (Super); 


- Yellowhead Highway and PTH 16 (MB Trans-Canada Highway); 



* in Alberta: Trans-Canada Highway (AB) and Trans-Canada Highway 
(Super); 
* in British Columbia: - Trans-Canada Highway (BC, Super) and 
Trans-Canada Highway; 


* About 90% of these routes are broken; * About 80% of these routes 
have highway value flip flop (motorway, trunk, primary); 




We propose to make some improvements to standardize all the routes. We would 
like to get your thoughts and feedback on the following questions: 

* What is the correct form for the name that appears in the way name tag? 
For example: “Highway 417” is part of Trans-Canada Highway and has the name 
value tag “Highway 417”. To resolve this issue, we would need to standardize 
the ways’ name tag for all the provinces. The question is, should we modify the 
way names in to “Trans-Canada Highway”, or should we insert the name 
“Trans-Canada Highway” at the end of the name, like this: “Highway 417 
(Trans-Canada Highway)”, or should we leave it like it is? 
* Another issue 

Re: [Talk-ca] Telenav mapping turn restrictions

[Andrew Lester]

Okay Telenav, you win. 

I've come across many mapping issues over the last few weeks, and nearly all of 
them have been created by Telenav mappers. These include malformed restrictions 
that prevent legal routing (these are in addition to the subjective turn 
restrictions discussed previously), adding names to driveways in strata 
developments (that I had previously removed), replacing my on-the-ground 
mapping with their own based solely on out-of-date imagery or the 
often-questionable Geobase, wildly incorrect highway classifications, and much 
more. Since these mappers seem to be intent on destroying the map (their 
actions can't be classified as anything but destructive), I'm throwing in the 
towel. If Telenav wishes to pay their employees to degrade the quality of the 
map, there isn't much I can do as a lone hobbyist in my spare time. At the rate 
I'm seeing things going, it won't be long until the OSM database has been 
degraded to the state that Google Maps is in these days since they started 
letting any yahoo edit their map. 

Going forward, I'm going to stick to mapping trails (which I sincerely hope 
Telenav doesn't branch out to), things like parks, and adding new roads. If a 
Telenav mapper later comes along and removes that new/realigned road because it 
doesn't look like that on Bing, then I guess they'd win again. I'm no longer 
going to clean up after Telenav, because they don't appear to want a quality 
map. I'll just have to accept that the routing on my OSM-based Garmin maps will 
gradually degrade and will likely contain routing issues, so I'll be careful 
about selecting my own route. 

I used to promote OSM as a great map that had benefits over others like Google, 
but I'm going to stop doing so because I no longer believe that. 
Congratulations, Telenav. You've beaten a heavy mapper into submission. You're 
free to degrade the map in the Victoria area as much as you want, and I won't 
fight back anymore. 

...at least the Telenav employees still get paid, so someone benefits from all 
of this in some twisted way... 

Andrew Lester 
Victoria, BC, Canada 


From: m...@rtijn.org 
To: "James Mast" <rickmastfa...@hotmail.com> 
Cc: "OSM US" <talk...@openstreetmap.org>, "talk-ca" <talk-ca@openstreetmap.org> 
Sent: Wednesday, April 5, 2017 6:00:35 AM 
Subject: Re: [Talk-ca] Telenav mapping turn restrictions 

James — Thanks. This means that at the very least we need to check on a 
jurisdiction by jurisdiction basis if these turns are allowed or not. 

Just as a data point, Google maps won’t let you make that turn either [1]. 
That’s not to argue that I am right in any way, just to show that false 
assumptions regarding turns are made outside of OSM. 

[1] 
https://www.google.com/maps/dir/40.586229,-80.0446722/40.586796,-80.0438587/@40.5879274,-80.0482634,17.23z/data=!4m2!4m1!3e0
 





On Apr 3, 2017, at 9:31 PM, James Mast < rickmastfa...@hotmail.com > wrote: 

Martijn, that intersection for as long as I can remember, has allowed the right 
turn @ the intersection and also via the slip lane. The slip lane being closed 
when StreetView drove by was indeed temporary. They were using it as a 
temporary staging area for construction vehicles for the bridge they were 
replacing on Pine Creek Road (well since completed) that was on the other side 
of the intersection. 

-James 

From: Martijn van Exel < m...@rtijn.org > 
Sent: Monday, April 3, 2017 1:18:38 PM 
To: James Mast 
Cc: talk-ca@openstreetmap.org ; OSM US 
Subject: Re: [Talk-ca] Telenav mapping turn restrictions 
James -- I could not find any OSC / Mapillary imagery at the location of your 
example so I took a peek at <> google street view. What I see there is 
that the slip road / ramp was (as of Aug 2016 -- temporarily?) closed to 
traffic which may very well inform the allowed right turn at the intersection? 
Or do you know this to be permanent? In this particular case, based on the info 
I have, the _link way should have access=no and indeed no restriction would be 
necessary. (Obviously I can't make those edits because of <> above.) 

I'm not saying that there cannot be exceptions to the general rule that 'when 
there is a turn ramp one must use it', (and as I said before our team is not 
adding these 'implicit' restrictions until we clear this up). What I am looking 
for is more clarity (specifically in Canada but in the US also) as to traffic 
regulations that would make adding these restrictions not only valid but also a 
boost to the quality of OSM data. I would only want us to add these if there is 
no confusion regarding correctness and there is added value to adding them. 

I'm cc-ing the US list as there are very similar traffic situations there and 
I'm interested in clarifying the situation there as well. 

Martijn 


BQ_BEGIN

On Apr 3, 2017, at 6:47 AM, James Mast < rickmastfa...@hotmail.com > wrote: 




Martijn, with your example you gav

Re: [Talk-ca] Telenav mapping turn restrictions

[Andrew Lester]

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

Re: [Talk-ca] Telenav mapping turn restrictions

[Andrew Lester]

ndicated to turn at exactly the spot marked, because you "must" follow the 
traffic control device indications, which is more than just signs, and those 
devices are indicating that you "must" take the linking lane. 

I totally accept that I'm being a major buttinsky here and probably coming off 
like a huge know-it-all, and I am SO sorry about that, but, given that whatever 
decision is made about whether this is right or not will live on in the map, I 
totally agree with what I think the spirit of what you're saying, which is "it 
needs to be correct". I just think that the "correct" thing is that you can't 
actually legally turn at that spot, just as that turn restriction edit 
indicates. If you got that far, go straight and find another way to your 
destination, or turn right and expect a ticket or an accident to happen. Any 
lawyers or police officers on this list? Their opinions are worth WAY more than 
mine. :-) Again, I am really really sorry to butt in. I just like "correctness" 
in the map, as you clearly do. I totally agree with the other half of your 
email, that having on-the-ground work killed by bad imagery traces is terrible. 
That's why I only edit places where I have actually put my own two feet on the 
ground. :-) 

Ian 


On 25 March 2017 at 21:52, Andrew Lester < a-les...@shaw.ca > wrote: 



I just discovered that user georges_telenav has been mapping turn restrictions 
in the Victoria, BC area. While some of them seem valid, there are hundreds of 
right-turn restrictions that can't possibly be based on either Mapillary or 
OpenStreetView as stated below, because these restrictions simply don't exist 
in reality. Here's an example: http://www.openstreetmap.org/relation/7014602 

I don't know about the rest of Canada, but at least in BC, this type of turn is 
perfectly legal unless otherwise indicated. Most drivers would use the link 
road and I'd expect routers should always prefer that, but there's nothing 
wrong if a driver gets past the link road and then changes their mind and wants 
to turn right. I can think of a handful of locations around town where there 
may be a sign explicitly forbidding this or at least implying it (e.g. "only 
left turn"), but the vast majority of the instances that this user has mapped 
do not have such signage. I'm in the process of cleaning all these up, but I'm 
worried there may be thousands more of these all over the place outside my 
immediate region. 

However, what I discovered while cleaning these up is even more disturbing. 
This is a region with significant growth, and there are frequent changes and 
additions to the road network. So far, I've discovered several cases where a 
reconfigured intersection or new road I had carefully mapped by GPS has been 
obliterated and replaced with an old configuration, apparently based on 
out-of-date aerial imagery. I take pride in mapping these changes as soon as 
possible after they're completed so end-users have the most reliable data (and 
I often mention this to people as one of the benefits of using OSM data in 
applications), so it's disappointing to see a distant armchair mapper destroy 
this careful on-the-ground work based on faulty assumptions and out-of-date 
imagery. I've also seen Telenav mappers adding residential roads that are 
clearly driveways and making edits without properly aligning aerial imagery, so 
I'm not exactly filled with confidence that they should be making widespread 
changes like they are. 

Martijn, I think Telenav needs to stop what they're doing and have a careful 
discussion with us about their plans and editing procedures before making any 
more edits. At least in my area, their edits have not only failed to improve 
the dataset, but in a number of cases has actually degraded it. Something needs 
to be done about this before things go too far. I already have a lot of cleanup 
work ahead of me, and I'd like to avoid this happening again in the future (at 
least by Telenav). 

Andrew 
Victoria, BC, Canada 


From: "James" < james2...@gmail.com > 
To: "John Marshall" < rps...@gmail.com > 
Cc: "talk-ca" < talk-ca@openstreetmap.org > 
Sent: Wednesday, October 19, 2016 11:44:53 AM 
Subject: Re: [Talk-ca] Telenav mapping turn restrictions 



Yeah no one really wants to do that, except maybe mapbox's india contractors 

On Oct 19, 2016 2:43 PM, "John Marshall" < rps...@gmail.com > wrote: 

BQ_BEGIN

Make sense to me. A dding turn restrictions is something I don't want to add. 
Happy to see all my Mapillary and OpenStreetView imagery being used to help 
improve the map. 

John 

On Tue, Oct 18, 2016 at 9:24 AM, Begin Daniel < jfd...@hotmail.com > wrote: 

BQ_BEGIN



Go with the recommended scheme as described on the wiki. 

Daniel 



From: Martijn van Exel [mailto: m...@rtijn.org ] 
Sent: Monday, 17 October, 2016 23:53 
To: Talk-CA OpenStreetMa

Re: [Talk-ca] Telenav mapping turn restrictions

[Andrew Lester]

I just discovered that user georges_telenav has been mapping turn restrictions 
in the Victoria, BC area. While some of them seem valid, there are hundreds of 
right-turn restrictions that can't possibly be based on either Mapillary or 
OpenStreetView as stated below, because these restrictions simply don't exist 
in reality. Here's an example: http://www.openstreetmap.org/relation/7014602 

I don't know about the rest of Canada, but at least in BC, this type of turn is 
perfectly legal unless otherwise indicated. Most drivers would use the link 
road and I'd expect routers should always prefer that, but there's nothing 
wrong if a driver gets past the link road and then changes their mind and wants 
to turn right. I can think of a handful of locations around town where there 
may be a sign explicitly forbidding this or at least implying it (e.g. "only 
left turn"), but the vast majority of the instances that this user has mapped 
do not have such signage. I'm in the process of cleaning all these up, but I'm 
worried there may be thousands more of these all over the place outside my 
immediate region. 

However, what I discovered while cleaning these up is even more disturbing. 
This is a region with significant growth, and there are frequent changes and 
additions to the road network. So far, I've discovered several cases where a 
reconfigured intersection or new road I had carefully mapped by GPS has been 
obliterated and replaced with an old configuration, apparently based on 
out-of-date aerial imagery. I take pride in mapping these changes as soon as 
possible after they're completed so end-users have the most reliable data (and 
I often mention this to people as one of the benefits of using OSM data in 
applications), so it's disappointing to see a distant armchair mapper destroy 
this careful on-the-ground work based on faulty assumptions and out-of-date 
imagery. I've also seen Telenav mappers adding residential roads that are 
clearly driveways and making edits without properly aligning aerial imagery, so 
I'm not exactly filled with confidence that they should be making widespread 
changes like they are. 

Martijn, I think Telenav needs to stop what they're doing and have a careful 
discussion with us about their plans and editing procedures before making any 
more edits. At least in my area, their edits have not only failed to improve 
the dataset, but in a number of cases has actually degraded it. Something needs 
to be done about this before things go too far. I already have a lot of cleanup 
work ahead of me, and I'd like to avoid this happening again in the future (at 
least by Telenav). 

Andrew 
Victoria, BC, Canada 


From: "James"  
To: "John Marshall"  
Cc: "talk-ca"  
Sent: Wednesday, October 19, 2016 11:44:53 AM 
Subject: Re: [Talk-ca] Telenav mapping turn restrictions 



Yeah no one really wants to do that, except maybe mapbox's india contractors 

On Oct 19, 2016 2:43 PM, "John Marshall" < rps...@gmail.com > wrote: 



Make sense to me. A dding turn restrictions is something I don't want to add. 
Happy to see all my Mapillary and OpenStreetView imagery being used to help 
improve the map. 

John 

On Tue, Oct 18, 2016 at 9:24 AM, Begin Daniel < jfd...@hotmail.com > wrote: 

BQ_BEGIN



Go with the recommended scheme as described on the wiki. 

Daniel 



From: Martijn van Exel [mailto: m...@rtijn.org ] 
Sent: Monday, 17 October, 2016 23:53 
To: Talk-CA OpenStreetMap 
Subject: [Talk-ca] Telenav mapping turn restrictions 





Hi all, 





I wanted to give you a heads up that my colleagues on the Telenav map team are 
starting work on adding turn restrictions in Toronto, Montréal, and later on 
also Vancouver, Ottawa and Calgary. We are using OpenStreetView and Mapillary 
as sources. If you have any questions or concerns, please reach out to me and 
we will address it right away. 





For conditional (time-restricted) turn restrictions, we intend to use the 
schema described in http://wiki.openstreetmap.org/wiki/Conditional_restrictions 
. We encounter a more complex mapping of conditional turn restrictions 
sometimes, where mappers have used day_on / day_off and hour_on / hour_off. 
This is uncommon and as far as I know not recommended for mapping 
time-restricted turn restrictions. If we encounter these, our proposal would be 
to remove these tags and if necessary replace them with the preferred scheme as 
described on the wiki. Opinions? 





Best, 


Martijn 




___ 
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 


BQ_END


___ 
Talk-ca mailing list 
Talk-ca@openstreetmap.org 

Re: [Talk-ca] CanVec Reverts

[Andrew Lester]

If people from outside of Canada have decided that our data is so bad that it 
needs to be completely wiped out in its entirety, then I guess we're going to 
have to do something drastic to try to prevent this. 

@Michael, Frederik, Paul: would it be good enough for us to wipe out any and 
all CanVec forest data (or even ALL forest data because some could have been 
derived from CanVec)? This seems to be the biggest cause for concern. If not, 
what do you think we need to do to prevent all CanVec data from being wiped 
out? Wiping out all CanVec data would effectively clear out the majority of the 
Canadian map and really isn't an option in our minds. Do we need to get rid of 
all forest data and then go on a cooperative fixing blitz (maybe using 
MapRoulette or Tasking Manager) to fix every single JOSM validator error across 
the country? In short, if we're doing things so wrong, what can we do to make 
things right other than have a German revert all of our changesets so we can 
start from scratch? 

Andrew 
Victoria, BC, Canada 

- Original Message -

From: "Sam Dyck"  
To: "Talk-CA OpenStreetMap"  
Sent: Thursday, September 1, 2016 2:38:38 PM 
Subject: Re: [Talk-ca] CanVec Reverts 


After reading Paul's email again, its possible that what Nakaner is doing is in 
line with Paul's suggestion, if unnecessarily confrontational. I tried to play 
around in JOSM to see if I could get the forest polygons to a point where 
Nakaner would leave us alone by mercilessly deleting all of the inner ways in 
the forest multipolygons, but because of the way things are structured around 
rivers that would be several hours worth of work for one tile. Given this 
perhaps the only solution is to bulk delete all Canvec forest data. As someone 
who actually finds the forest data useful this would be extremely unfortunate, 
but if it allows us to continue imports without excessive external scrutiny 
then I am willing to except it. (apologies for the English only emails, my 
French writing skills are sadly lacking) 



On Thu, Sep 1, 2016 at 4:20 PM, Pierre Béland < pierz...@yahoo.fr > wrote: 




L'idéal préparer Une réponse standard indiquant que l'Import Canvec par la 
communauté OSM Canada est itératif et nous nous assurons collectivement 
d'améliorer les données. Voir page Wiki Import Canvec et venir discuter sur 
Talk-Ca si vous avez d'autres questions. 




Pierre 








De : Sam Dyck < samueld...@gmail.com > 
À : Talk-CA OpenStreetMap < talk-ca@openstreetmap.org > 
Envoyé le : jeudi 1 Septembre 2016 17h06 
Objet : Re: [Talk-ca] CanVec Reverts 






I received the following changeset comment from Nakaner for a Canvec import 
(changeset 
38158126) at 15:55 Central Time (20:55 UTC): 

"This changeset has uploaded data which does not fit to each other. There is an 
offset between the water areas and the forest areas. Example: 
https://www.openstreetmap.org/ way/406539219 
Could you please fix this?" 
I believe the given what we have just spent the last 24 hours discussing this 
request is unreasonable and the issue is not significant. Thoughts? 
Sam 

___ 
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

Re: [Talk-ca] OSM data quality in Canada

[Andrew Lester]

If this is the consensus, I've been blissfully unaware and the wiki needs to be 
updated. The Canadian tagging guidelines 
(https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Regional_roadways_.28below_provincially_controlled.29)
 recommend using unclassified when not in residential areas, and that's how 
I've been tagging. The CANVEC imports generally use residential as you describe 
which has led to a lot of mis-tagged highways, but I wouldn't say this is a 
consensus agreement that this is how we want it to be. It’s just how the data 
was imported. I'm gradually re-tagging such highways in my area, but there's a 
lot that need to be fixed across very large areas and not many people working 
on it.

 

Andrew Lester

Victoria, BC, Canada

 

From: Harald Kliems [mailto:kli...@gmail.com] 
Sent: Wednesday, June 17, 2015 1:27 PM
To: Martijn van Exel; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] OSM data quality in Canada

 

A few things I can think of:

 

On Wed, Jun 17, 2015 at 3:13 PM Martijn van Exel m...@rtijn.org 
mailto:m...@rtijn.org  wrote:

* Are there any Canada-specific mapping and tagging conventions?

- There seems to be a strong consensus that what elsewhere would be 
highway=unclassified is highway=residential, no matter if the road is in a 
populated area or not.

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

Re: [Talk-ca] Target Canada

[Andrew Lester]

I don't understand why this was done. Not all of these stores are closed 
permanently. Unless you plan to do the reverse on Saturday for the ones 
remaining open , we'll be left with shop=vacant where the shop is actually open 
. If some of these are in areas without regular contributors, they could remain 
vacant for a long time. shop=vacant also doesn't render on the standard map, 
so it would be easy for these incorrectly- vacant locations to go unnoticed, 
whereas a visible Future Shop would be more likely to be noticed and then get 
fixed. 

The most I would have done would be to add a note or fixme that the name would 
be changing as of April 4. If you plan to do the same thing for the Target 
locations, please let us know in advance. 

Andrew Lester 
Victoria, BC, Canada 

- Original Message -

From: Andrew MacKinnon andrew...@gmail.com 
To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org 
Sent: Thursday, April 2, 2015 11:49:15 AM 
Subject: Re: [Talk-ca] Target Canada 

I have already changed every Future 
Shop which is in OSM to shop=vacant. See 
http://wiki.openstreetmap.org/wiki/Future Shop . 

___ 
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] Alberta Park's Data on Protected Areas – Legal or not

[Andrew Lester]

I couldn't see a license anywhere on that site other than the copyright notice 
at the bottom of the page (which very unequivocally states we can't use 
anything on the website), so I downloaded the dataset to see if there was 
anything in there. Inside the XML file in the dataset are the following:
purposeData provided for internal use within Alberta Tourism, Parks and 
Recreation (TPR). Within TPR, data for sites designated by Order-in-Council, 
and data pertaining to Crown Reservations, are managed in the same dataset. For 
external clients, data are provided as separate shapefiles. (Designated Parks  
Protected Areas, vs. Crown Reservations)./purpose

and

useconstNo constraints within TPR. Data provided to external clients are for 
their internal use only. Data are not to be redistributed./useconst

Now, IANAL, but those would seem to indicate that we can't use this data in 
OSM. We could still ask them for explicit permission, though, to see if they'll 
override the above.

Andrew
alester
Victoria, BC, Canada

- Original Message -
From: Victor Chwieros wchwie...@yahoo.com
To: talk-ca@openstreetmap.org
Sent: Monday, May 12, 2014 8:15:13 PM
Subject: [Talk-ca] Alberta Park's Data on Protected Areas – Legal or not




Are we allowed to use the Alberta Park's Protected Areas (Shapefile) in OSM? 

Data source is the last entry on this list: 

http://www.albertaparks.ca/albertaparksca/library/downloadable-data-sets.aspx 

Reason I ask is that a number of the provincial parks have not been mapped. One 
example is: 

https://en.wikipedia.org/wiki/Kinbrook_Island_Provincial_Park 

http://www.openstreetmap.org/#map=14/50.4407/-111.9076 


I checked the NRCan data and it is not part of the “Atlas of Canada 1,000,000 
National Frameworks Data, Protected Areas-Protected Areas” - so we can't get 
the park boundary from there. 


Victor 




___
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] coastline between Montreal and Sorel, Quebec

[Andrew Lester]

Why not tag it as both? The surrounding ways are already tagged with both.
...or tag the ways as coastline and make one or more relations to mark the 
riverbank area. Whatever happens, having the coastline end for this short 
stretch does seem wrong, and if someone is reverting changes there, someone 
needs to contact them and find out their reasons.

Andrew
alester
Victoria, BC

Sent from my iPhone

On Apr 3, 2014, at 7:40 AM, Adam Martin s.adam.mar...@gmail.com wrote:

Charles,

I took a look at the area that you describe and I see what you mean - the 
coastline designation disappears around Sorel and reappears just past Montreal. 
Looking in the area of the gap, the use of Coastline appears to suddenly 
switch to Water and Riverbank. The source of the information also switches, 
from the NRCAN database to Bing. 

I am not aware of a discussion that flagged this area to be left as-is on the 
map. I am also not sure why someone would be protecting the area from 
corrections / changes. 

However, I believe I can see where the confusion came from (at least 
partially). For reference, this is the St. Lawrence River, an enormous waterway 
that drains the Great Lakes into the North Atlantic. A river of this size 
generally cannot be described accurately with a single line in the centre of 
the waterway as it eliminates a vital level of detail of the surrounding area. 
So the St. Lawrence needs to be detailed as a water polygon in order to 
preserve the shoreline. The problem here is that there seems to be some 
confusion as to what sort of shoreline this represents - coastline or 
riverbank. The answer to that is rather complex - where exactly does the St. 
Lawrence River stop being a river and become part of the eastern coast of 
Canada? The switch between descriptions here appears to be part of someones 
attempt to correct the designation of the shoreline in the river for an area 
that they consider to be part of the River that is the St. Lawrence (as 
opposed to the coastline that the river drains into).

I think the question here is the same - where does the St. Lawrence stop being 
a river and start being a part of the coastline? 

Adam


 On Wed, Apr 2, 2014 at 10:10 PM, Charles Basenga Kiyanda 
 perso...@charleskiyanda.com wrote:
 Anybody know why the coastline stops about midway along the Montreal Island 
 (and also Ile Jésus) and then starts again around Sorel? I got one report 
 from someone who tried to fix this and was quickly reverted. Should it be 
 fixed at some point and it's just such a large undertaking that nobody is 
 willing to do it yet or was there a discussion and subsequent consensus to 
 adopt the current state of the coastline?
 
 Thanks,
 
 Charles
 
 ___
 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

Re: [Talk-ca] GPS and Motorway links ...

[Andrew Lester]

If St. John's is west, what am I out here in BC? The far west? ;)

Thanks for going through and fixing all those!
Andrew

Sent from my iPhone

On Jan 16, 2014, at 2:29 PM, Harald Kliems kli...@gmail.com wrote:

I am happy to report that all of Canada should now be free of this issue! I 
just fixed the last one all the way west in Saint John's. Yay!

 Harald.


 On Sun, Jan 12, 2014 at 6:03 PM, Harald Kliems kli...@gmail.com wrote:
 Some updates on this issue:
 
 I contacted Martijn a while ago with the suggestion of running this as a 
 Maproulette. He liked the idea but I haven't heard back in a while. He also 
 asked me how many cases we're talking about and based on the Overpass query 
 mentioned upthread I came to the conclusion that the number is actually not 
 that high (maybe 400 cases in all of Canada at the most). Therefore I've 
 started fixing the issue manually and already cleaned up all of Quebec. It 
 took me several hours, but that's partly because you always discover other 
 issues to take care of as you go along (e.g. missing motorway_junction, name 
 vs. exit_to on those junctions etc.). 
 
 I'll continue working on this in Ontario now and I encourage others to go 
 ahead in the other provinces, too. Just run http://overpass-turbo.eu/s/1CI on 
 the appropriate bounding box and then go through each of the spots that come 
 up. If there is hi-res Bing imagery available the fix will be obvious; and if 
 not common sense should still tell you if a segment is oneway=yes or 
 oneway=no. I have added a oneway tag to every motorway_link segment, both to 
 avoid any misunderstanding with the default and to allow me to track the 
 progress on the Overpass map.
 
 Cheers,
  Harald.
 
 
 On Wed, Nov 27, 2013 at 11:04 AM, Harald Kliems kli...@gmail.com wrote:
 So before contacting Martijn I want to be sure that we can properly identify 
 the potentially problematic ways. What we are looking for are ways that 
 match the following query:
 
 (highway=motorway_link) AND (NOT oneway=*) AND (lanes!=1) 
 
 Or in natural language: ways that are motorway links but don't have the 
 oneway tag nor are tagged as having one lane. If you want to test this 
 query, go to this link http://overpass-turbo.eu/s/1CI and adjust the 
 bounding box coordinates for the desired area.
 
 Comments?
 
  Harald.
 
 
 On Tue, Nov 26, 2013 at 10:25 AM, Daniel Begin jfd...@hotmail.com wrote:
 The example I provided yesterday was not fixed.  Most the exits having a 
 similar look along the trans-Canada Highway in Quebec are the same. I have 
 also found examples in Alberta and In BC.
 
  
 
 Daniel
 
  
 
 From: Harald Kliems [mailto:kli...@gmail.com] 
 Sent: November-26-13 10:04
 To: Daniel Begin
 Cc: Connors, Bernie (SNB); Talk-CA OpenStreetMap
 
 
 Subject: Re: [Talk-ca] GPS and Motorway links ...
  
 
 I can write an email to Martijn with a proposal. Does anyone have a link to 
 an exit that has not been fixed yet to use as an example?
 
  
 
  Harald.
 
  
 
 On Tue, Nov 26, 2013 at 9:53 AM, Daniel Begin jfd...@hotmail.com wrote:
 
 It seems to me it is the only safe solution. I go for maproulette.org
 
 Daniel
 
  
 
 From: Connors, Bernie (SNB) [mailto:bernie.conn...@snb.ca] 
 Sent: November-26-13 08:19
 To: 'Harald Kliems'; Daniel Begin
 Cc: Talk-CA OpenStreetMap
 Subject: RE: [Talk-ca] GPS and Motorway links ...
 
  
 
 +1 for the Maproulette.org solution.
 
  
 
 Bernie.
 
 --
 
 Bernie Connors, P.Eng
 
 Tel: 506-444-2077
 
 bernie.conn...@snb.ca
 
 SNB – We make it happen…
 
 image001.jpg
 
  
 
 From: Harald Kliems [mailto:kli...@gmail.com] 
 Sent: Monday, 2013-11-25 5:05 PM
 To: Daniel Begin
 Cc: Talk-CA OpenStreetMap
 Subject: Re: [Talk-ca] GPS and Motorway links ...
 
  
 
  
 
  
 
 On Mon, Nov 25, 2013 at 3:35 PM, Daniel Begin jfd...@hotmail.com wrote:
 
 Hooo, I see, and I also see there was not a large consensus on that point 
 (Discussion) since all other ways are having a different behavior…
 
  
 
 About all motorway_link in Canada are having the same problem!
 
 I don't know, I rarely encounter this issue in practice. Adding oneway=no 
 to all motorway_link seems rather dangerous and counterproductive. The best 
 solution would probably be to create a query that will find all imported 
 motorway_link that have not been touched since the import and then check 
 them. Depending on how big the task is we could ask Martijn to set it up as 
 a Maproulette (http://maproulette.org/). Or we set up a wiki page to 
 coordinate people going through all the motorways/exits and make sure 
 everything is okay by hand. There are only 33 Autoroutes in Quebec after 
 all :-)
 
  
 
  Harald.
 
  
 
 
 
 
  
 
 -- 
 Please use encrypted communication whenever possible!
 Key-ID: 0x34cb93972f186565
 
 
 
 
 -- 
 Please use encrypted communication whenever possible!
 Key-ID: 0x34cb93972f186565
 
 
 
 -- 
 Please use encrypted communication whenever possible!
 Key-ID: 0x34cb93972f186565



-- 
Please use encrypted communication 

Re: [Talk-ca] Sewage dump stations

[Andrew Lester]

That's exactly the tagging I used when I mapped out some campgrounds in my 
area. It was the best match I could find in the wiki.

Andrew Lester
Victoria, BC

On 2013-03-04, at 7:53 AM, Clifford Snow cliff...@snowandsnow.us wrote:

I believe you want amenity=waste_disposal and waste=excrement 

Look under the waste tag on the wiki.

I do believe we need a single amenity=sewage_dump_station instead of the two 
tags, but... 
 


On Sun, Mar 3, 2013 at 11:48 PM, Tony Toews t...@tonytoews.com wrote:
 Folks
 
 One object that is of significant interest to RVs is the location of sewage 
 dump stations. I know of two in my small town one of which is hidden away 
 behind a gas station on a main highway and the other more logically placed in 
 the provincial park campground.
 
 I don't see any way to add dump stations as a discrete object.   Or am I 
 wrong?   Should I put them in as public toilets?  Just kidding.  
 
 Tony
 
 ___
 Talk-ca mailing list
 Talk-ca@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ca



-- 
Clifford

OpenStreetMap: Maps with a human touch
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Duplicate BC, Canada geometry

[Andrew Lester]

I haven't been doing much importing recently, but whenever I do, I _always_
download the area in JOSM first before adding anything to make sure I'm not
duplicating existing data. Without seeing an example, I really can't give an
explanation of what's happening.  As far as my CANVEC importing goes, all
but a handful have been on Vancouver Island. I've stumbled upon and fixed
other peoples' duplicated data in the past, but I haven't knowingly
duplicated data myself. I'd love to see where this is happening.

 

Andrew (alester/alester_imports)

 

From: Adam Dunn [mailto:dunna...@gmail.com] 
Sent: Saturday, February 16, 2013 7:45 PM
To: the Old Topo Depot
Cc: impo...@openstreetmap.org; talk-ca
Subject: Re: [Talk-ca] Duplicate BC, Canada geometry

 

Hmm, I think the last time I did imports in BC was back in 2010, and I
thought I was careful about leaving the map in a correct and consistent
state. Azub's imports are all in the Prince George or north area, and I
definitely know I haven't touched that area in a long time. Got any examples
or changeset numbers?

 

The nature of doing imports like Canvec tends to be spread over large areas
and large amounts of time. Any suggestions on techniques for coordinating
efforts? An email to the list saying I'll be working on Prince George area
this week? A shared spreadsheet?

 

Adam

 

On Sat, Feb 16, 2013 at 7:27 PM, the Old Topo Depot oldto...@novacell.com
wrote:

Users Adam Dunn (http://www.openstreetmap.org/user/Adam%20Dunn),
alester_imports (http://www.openstreetmap.org/user/alester_imports), and
azubimport (http://www.openstreetmap.org/user/azubimport) are duplicating
way geometry from multiple sources, in some cases within a few days of each
other.

 

Will the three (hopefully there are not more) of you please coordinate your
efforts, review your recent work, and de-duplicate way geometry and tagging
in BC, Canada (and elsewhere, if applicable).  I presume you've been
engaging with the import list, copied  ...

 

Thanks and best


 

-- 

John Novak
585-OLD-TOPOS (585-653-8676 tel:%28585-653-8676 )

 http://www.linkedin.com/in/johnanovak/
http://www.linkedin.com/in/johnanovak/

OSM ID:oldtopos

OSM Heat Map: http://yosmhm.neis-one.org/?oldtopos

OSM Edit Stats:http://hdyc.neis-one.org/?oldtopos


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

 

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

Re: [Talk-ca] Lake Winnipeg

[Andrew Lester]

I just took a look, and the relation was broken in two places. One of the
ways on the outer edge was missing, as was about half of one of the inner
islands. I added the necessary ways back into the relation, so it should
render properly now.

Andrew

Victoria, BC

 

From: Sam Dyck [mailto:samueld...@gmail.com] 
Sent: Saturday, January 26, 2013 10:54 AM
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] Lake Winnipeg

 

Hi

A while back I changed tagged the southern half of Lake Winnipeg as
natural=coastline so it will appear on all levels of the map. Per the
suggestion of someone on this list, I kept the old water multipolygon so
that it would not disappear until the next coastline update. It is now
disappearing from the map, see http://osm.org/go/Wp9lapp--

Can someone suggest a way to stop this?

Sam

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

Re: [Talk-ca] Proposed mechanical edits: GeoBase/CanVec Service Surface and GeoBase/CanVec name spaces

[Andrew Lester]

I've seen the double (and even triple) space problem here on Vancouver
Island, and I've stumbled upon it when looking at data in other parts of
Canada. I think all of the Geobase and Canvec 9 or earlier data is affected.
I just checked and the problem has been fixed with Canvec 10, so if the
existing data can be fixed, the problem won't come back.
Andrew Lester
Victoria, BC

-Original Message-
From: Paul Norman [mailto:penor...@mac.com] 
Sent: Saturday, August 11, 2012 10:54 AM
To: 'Harald Kliems'
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Proposed mechanical edits: GeoBase/CanVec Service
Surface and GeoBase/CanVec name spaces

No one pointed out any areas with problems outside the lower mainland so I
only did this locally. As for an entirely automated way to deal with name:
 ways, there isn't one.

 From: Harald Kliems [mailto:kli...@gmail.com]
 Sent: Saturday, August 11, 2012 8:21 AM
 Subject: Re: [Talk-ca] Proposed mechanical edits: GeoBase/CanVec 
 Service Surface and GeoBase/CanVec name spaces
 
 Hi Paul,
 did you ever get around to doing this? I was recently adding a bunch 
 of street names based on Geobase along the St. Lawrence between 
 Montreal and Quebec City and I noticed that there are still lots of 
 streets (and house number interpolations) with the double blanks. And 
 can somebody please tell me how to do a search and replace in JOSM to 
 deal with this semi-manually?
 Best,
  Harald.
 
 On Fri, Apr 6, 2012 at 4:34 PM, Paul Norman penor...@mac.com wrote:
  Since no one has objected (or commented) I'll go ahead with this if 
  I can get it in before the rebuild starts.
 
  -Original Message-
  From: Paul Norman [mailto:penor...@mac.com]
  Sent: Saturday, March 17, 2012 12:04 AM
  To: talk-ca@openstreetmap.org
  Subject: Re: [Talk-ca] Proposed mechanical edits: GeoBase/CanVec 
  Service Surface and GeoBase/CanVec name spaces
 
  Not listed in this message was the area this would be over. This 
  would only be over the lower mainland unless requested for another
 area.
 
   -Original Message-
   From: Paul Norman [mailto:penor...@mac.com]
   Subject: [Talk-ca] Proposed mechanical edits: GeoBase/CanVec 
   Service Surface and GeoBase/CanVec name spaces
  
   The GeoBase and CanVec imports in the lower mainland suffered 
   from two tagging errors I propose fixing with two one-time 
   mechanical
 edits.
  
   1. surface=unpaved service ways
  
   GeoBase and CanVec highway=service ways are mis-tagged with 
   surface=unpaved regardless of if they are paved or not. I propose 
   removing this tag as it is misleading. To avoid removal of this 
   tag where a mapper has reviewed it, I will only do the obvious 
   cases automatically and review the others.
  
   The obvious case is ways where none of the tagging has changed 
   since the import with the possible exception of geobase:uuid 
   which may have been combined with the value from another way in a
merge.
  
   These will be identified by the tags attribution=GeoBaseR 
   geobase:acquisitionTechnique=Orthophoto
   geobase:datasetName=NRN:British Columbia geobase:uuid=*
   source=Geobase_Import_2009 surface=unpaved highway=service
  
   2. Double-spaced names
  
   GeoBase and CanVec sometimes have names with two spaces in them.
   For example, West  70th Street. I propose fixing these.
   Unfortunately this is less automated and will require searching 
   through the road network with JOSM for name:  .
  
   The edit will be from my imports/mechanical edit account and 
   appropriately documented.
  
   As these edits will require touching a large number of roads I 
   also propose cleaning up unnecessary meta-information from the 
   import that is duplicated by other tags. For example, 
   geobase:datasetName=NRN:British Columbia can be inferred from 
   source=Geobase_Import_2009, being located in BC, and matching
  highway=*.
  
   It is not worth creating a new version of objects solely to 
   remove these tags, but since fixing the tagging requires creating 
   a new object anyways it is worth doing it in this case.
  
  
   ___
   Talk-ca mailing list
   Talk-ca@openstreetmap.org
   http://lists.openstreetmap.org/listinfo/talk-ca
 
 
  ___
  Talk-ca mailing list
  Talk-ca@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-ca
 
 
  ___
  Talk-ca mailing list
  Talk-ca@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-ca
 
 
 
 --
 Please use encrypted communication whenever possible!
 Key-ID: 0x199DC50F


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



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

Re: [Talk-ca] admin_level of canadian cities

[Andrew Lester]

Ahh, you’re absolutely correct. I hadn’t noticed that node. The one I was 
looking at is http://www.openstreetmap.org/browse/node/30915641, which isn’t 
part of any relations. One of these two “Quebec” nodes should probably be 
removed and the remaining one added to the provincial relation.

 

Andrew

 

From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] 
Sent: Thursday, June 14, 2012 11:52 AM
To: Andrew Lester; 'Bruno Remy'; talk-ca@openstreetmap.org
Subject: Re : [Talk-ca] admin_level of canadian cities

 

We should not confuse province and municipality levels.

 

Quebec city has admin_level=8. See  node description 
http://www.openstreetmap.org/browse/node/1781476959


Quebec province has admin_level=4. See  Administrative boundary 
relationhttp://www.openstreetmap.org/browse/relation/61549 

 

Pierre 

  _  

De : Andrew Lester a-les...@shaw.ca
À : 'Bruno Remy' bremy.qc...@gmail.com; talk-ca@openstreetmap.org 
Envoyé le : Jeudi 14 juin 2012 14h13
Objet : Re: [Talk-ca] admin_level of canadian cities





As far as I can tell, the reason Quebec City is tagged as admin_level=4 is 
because it’s the capital of the province. As per your linked wiki page, 
provinces are admin_level=4. For any old non-capital city, they should be 
tagged admin_level=8. Keep in mind that admin_level=* is primarily intended for 
use on boundary ways and relations, not the place=* node. The usage of 
admin_level=*and capital=* on city nodes is part of a proposed feature covering 
capitals (http://wiki.openstreetmap.org/wiki/Proposed_features/capital). 
Contrary to what that proposal outlines, the common usage according to Taginfo 
(http://taginfo.openstreetmap.org/keys/capital#values) seems to be that 
capitals are tagged as capital=[admin level number] (ie. Quebec City would be 
tagged capital=4).

 

Andrew Lester

Victoria, BC

 

From: Bruno Remy [mailto:bremy.qc...@gmail.com] 
Sent: Thursday, June 14, 2012 10:44 AM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] admin_level of canadian cities

 

hi,

What do you suggest for admin_level of canadian cities, because i noticed 
difference between the official Canadian recommendation on Openstreetmap wiki 
(http://wiki.openstreetmap.org/wiki/Admin_level#10_admin_level_values_for_specific_countries)
 witch is suggesting LEVEL 8 ... whereas you can check LEVEL 4 for big cities 
in Canada on Opensstreetmap (Quebec City as instance...)

So ... do we adjust our admin_level according to the canadian section of 
openstreetmap's wiki?
Or do you suggest to keep on tracks on LEVEL 8 usage... and why?

-- 
Bruno Remy


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



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

Re: [Talk-ca] Beginner questions

[Andrew Lester]

Looking at the history of the objects, it looks like another mapper used
Bing to map out the road network on Apr 14th, then you added CANVEC data on
top of this on the 15th, so nearly everything is now duplicated. Question:
Did you download the existing data for the town when you made your edits, or
did you just upload the CANVEC data? When importing data, you need to make
sure the data you're importing isn't going to conflict with existing data.
Download the existing data, make your additions or changes, then upload the
end result.

As for the buildings, Richard's suggestion of the orthogonalize tool is
the best. It has the keyboard shortcut of Q. It will take your best guess
and square off all corners to 90 degrees. Keep in mind that if there are any
other angles, like a wall that is 45 degrees with respect to another wall,
this tool will try to square it off and really mess it up. In cases like
this, I'll temporarily split the way such that I have the parts of the
building that are all square to each other in one way, orthogonalize that,
then combine the ways back together.

-Original Message-
From: Frank Cox [mailto:thea...@melvilletheatre.com] 
Sent: Sunday, April 15, 2012 11:27 PM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Beginner questions

I seem to have somehow ended up with duplicate streets, side-by-side.  So
the obvious fix would probably be to delete one of them, leave the other,
and name and classify the one that's left.  Is this correct?



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

Re: [Talk-ca] Killarney Lake, Fredericton, NB

[Andrew Lester]

I brought it up in JOSM, and the Validator plug-in reported an unclosed way.
There was a small (2.6m) gap in the northern side of the lake. I've closed
it, and it's rendering properly now.

Andrew Lester
Victoria, BC



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