Re: [Talk-ca] Proposal to tag Yonge Street in Toronto and York Region as Primary

[Kevin Farrugia]

Maybe we look at volume and connectivity to higher orders of road and/or
connectivity to other municipalities as the criteria?

In some areas these will also happen to be former provincial highways (ex:
parts of former Hwy 7, parts of former Hwy 10/Hurontario, Main St
(Hamilton), etc.) while others won't have ever been provincial, such as
Adelaide, Dixie, Steeles, King (Hamilton).

When those former highways were being made primary before, they were simply
only because they were former provincial highways and not because of
volume, for example Queen & Main (former Hwy 7 & Hwy 10) in downtown
Brampton was made Primary.

Thoughts?

-Kevin


On Fri, 17 Jul 2020 at 07:37, john whelan  wrote:

> What Jarek says makes sense to me.  I suspect many of the map users don't
> live where the use the map.
>
> Having said that could we come up with something that could be applied
> across Canada or is that too much to ask for?
>
> 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

Re: [Talk-ca] Proposal to tag Yonge Street in Toronto and York Region as Primary

[Kevin Farrugia]

Yeah, it changes from place to place and what has historically been
the standard.  I'm not against changing the standard, maybe we just need a
better or updated definition for what can be a primary road in Ontario.

Perhaps we make some standards for the heavily urbanised areas of Ontario
where "provincial highway or former provincial highway" isn't a useful
definition.  There are several Regional roads/numbered city roads that
would come to mind that would be decent candidates, as they connect lower
and/or upper tier municipalities, usually direct traffic to 400-Series
Highways, have heavy volume, and allow trucks.

Thoughts?

-Kevin


On Thu, 16 Jul 2020 at 21:08, Andrew Deng  wrote:

> I thought the tagging would be similar to the US, where roads are tagged
> based on its traffic volume and importance which is why I thought Yonge
> should be Primary. I see now.
>
> --
>
>
>
> Andrew
> Student
>
>
> On Thursday, July 16, 2020, 08:31:48 p.m. EDT, Kevin Farrugia <
> kevinfarru...@gmail.com> wrote:
>
>
> Hey Andrew,
>
> I'm in agreement with Justin.  I think it's too urban a road, with urban
> speed limits along almost its entire length and many traffic lights.  I
> definitely wouldn't consider the part of Yonge through downtown Toronto (or
> most of Toronto for that matter) to be Primary, with truck traffic banned
> and urban speed limits/road designs.  Arguably the subway has lowered the
> importance of Yonge Street for cars/trucks.  As for intercity travel, the
> 400-Series Highways have generally made travel using former King's Highways
> in the Golden Horseshoe a thing of the past (hence the download in the
> '90s), so being a former Provincial Highway is too simple of a definition,
> IMO.
>
> Some of those former King's Highways you mentioned in your email were
> tagged as Secondary from when they were first digitized until they were
> changed a year or so ago by one user, so they haven't always been like that
> and weren't really changed by consensus (thanks for the email, btw).
>
> My thoughts/opinion anyways...
>
> Cheers,
>
> -Kevin
>
>
> On Thu, 16 Jul 2020 at 14:09, Justin Tracey  wrote:
>
> In Canada, highway=primary is typically used for what I would call
> "highway-like" roads.[0] IMHO, Yonge is a "major" road, but has too many
> cross streets to be really considered highway-like, at least for most of
> its length. You can look at some of the other highway=primary roads in the
> area to see a more typical cross-traffic density. That said, I certainly
> wouldn't engage in an edit war over it or anything.
>
>  - Justin
>
> [0]
> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Sub-national_and_below
>
> On 2020-07-16 11:28 a.m., Andrew Deng via Talk-ca wrote:
>
> Hello, I believe Yonge Street in Toronto and York Region (Regional Road 1)
> should be tagged as highway=primary rather than highway=secondary as it is
> tagged now.
>
> Here are some reasons I believe why:
>
> 1) Yonge Street is considered the "Main Street" of Toronto, Thornhill,
> Richmond Hill, and Aurora. It is also a major road in Newmarket.
>
> 2) It is a major thoroughfare throughout the route. In Toronto, the Yonge
> subway follows it and in York Region, Viva bus lanes are being built. It
> also connects to Bradford in the north.
>
> 3) It was a former Ontario King's Highway - Highway 11. Some other former
> King's Highways in the Toronto/York area are tagged as highway=primary,
> such as Highway 27, Highway 7, and Highway 48.
>
> --
>
>
>
> Andrew
>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Proposal to tag Yonge Street in Toronto and York Region as Primary

[Kevin Farrugia]

Hey Andrew,

I'm in agreement with Justin.  I think it's too urban a road, with urban
speed limits along almost its entire length and many traffic lights.  I
definitely wouldn't consider the part of Yonge through downtown Toronto (or
most of Toronto for that matter) to be Primary, with truck traffic banned
and urban speed limits/road designs.  Arguably the subway has lowered the
importance of Yonge Street for cars/trucks.  As for intercity travel, the
400-Series Highways have generally made travel using former King's Highways
in the Golden Horseshoe a thing of the past (hence the download in the
'90s), so being a former Provincial Highway is too simple of a definition,
IMO.

Some of those former King's Highways you mentioned in your email were
tagged as Secondary from when they were first digitized until they were
changed a year or so ago by one user, so they haven't always been like that
and weren't really changed by consensus (thanks for the email, btw).

My thoughts/opinion anyways...

Cheers,

-Kevin


On Thu, 16 Jul 2020 at 14:09, Justin Tracey  wrote:

> In Canada, highway=primary is typically used for what I would call
> "highway-like" roads.[0] IMHO, Yonge is a "major" road, but has too many
> cross streets to be really considered highway-like, at least for most of
> its length. You can look at some of the other highway=primary roads in the
> area to see a more typical cross-traffic density. That said, I certainly
> wouldn't engage in an edit war over it or anything.
>
>  - Justin
>
> [0]
> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Sub-national_and_below
>
> On 2020-07-16 11:28 a.m., Andrew Deng via Talk-ca wrote:
>
> Hello, I believe Yonge Street in Toronto and York Region (Regional Road 1)
> should be tagged as highway=primary rather than highway=secondary as it is
> tagged now.
>
> Here are some reasons I believe why:
>
> 1) Yonge Street is considered the "Main Street" of Toronto, Thornhill,
> Richmond Hill, and Aurora. It is also a major road in Newmarket.
>
> 2) It is a major thoroughfare throughout the route. In Toronto, the Yonge
> subway follows it and in York Region, Viva bus lanes are being built. It
> also connects to Bradford in the north.
>
> 3) It was a former Ontario King's Highway - Highway 11. Some other former
> King's Highways in the Toronto/York area are tagged as highway=primary,
> such as Highway 27, Highway 7, and Highway 48.
>
> --
>
>
>
> Andrew
>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://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] NRCan lakes

[Kevin Farrugia]

I wouldn't worry about hoping the NRCan stuff is up to date. They're based
on data may/may not have been updated since the paper maps were printed in
the 70s/80s/90s and all aerial imagery that's in OSM would be newer than
that.

The National Hydro Network and National Road Network (based on provincial
data, which is based on municipal data) are both much more up to date and
actively maintained if you want some assistance when using imagery. I
believe both are automatically available in JOSM when editing in Canada.

---
Kevin F

On Wed., Jul. 8, 2020, 5:24 p.m. Hannes Röst,  wrote:

> Dear Daniel
>
> Thanks for your answers, I have tried to piece together this (apparently
> 10 year old) history of the import from the mailing list threads and the
> wiki and it has been somewhat difficult, especially as discussions seem to
> have been at multiple places. So, so many discussion about
> forests!...Overall there seem to be some questions about the quality and
> desirability of parts of the import of CanVec with the (Canadian) consus
> being that it is desireable to do the imports.
>
> The wiki still indicates to use the canvec.osm product even though the
> timestamps on the files are from 2013 [1] and it is not clear whether there
> is a newer / updated version of the data. When I compare the OSM files of
> tiles from the FTP site to the Toporama product doing some spot-checks I
> find them to be identical for hydrological data (wetlands, rivers etc) and
> almost identical for forests (with Toporama having some additional "inner"
> ways where no forest is, but not always more accurate). If my understanding
> is correct that the WMS endpoints of CanVec and Toporama are up-to-date,
> then this allows us to compare changes in the products since 2013 when the
> OSM FTP dump was made. On the other hand in the release notes from 2019 [2]
> they point to an FTP site but that one does not contain OSM files and the
> release notes seem to indicate 2016-01-14 as "original release" of the
> current CanVec data [3]. So it seems our version from 2013 is a bit behind
> but probably the best we have unless somebody is willing to create another
> export. However, it may make sense to load the *current* Toporama WSM layer
> into JOSM during an import and check for any updates since the 2013 dump.
> On the other hand, the data is not very up to date in cities, I found a
> large industrial complex in the Toporama map in downtown Toronto where "Marian
> Engel Park" is since at least 12 years [4], so we have to keep that in
> mind.
>
> The wiki also suggest to use a Google Sheet to track imports, but it does
> not seem to be used a lot - I assume from the wikipage that you have
> written most of it and initiated the import, correct?
>
> Best regards
>
> Hannes
>
> 1. https://wiki.openstreetmap.org/wiki/CanVec#Canvec_Product_-_Datasets
> 2.
> https://www.nrcan.gc.ca/science-and-data/science-and-research/earth-sciences/geography/topographic-information/whats-new/canvec-update-available-now/22543
> 3.
> https://ftp.maps.canada.ca/pub/nrcan_rncan/vector/canvec/doc/CanVec_en_Release_Note.pdf
> 4. https://www.openstreetmap.org/way/15804193
>
> *Gesendet:* Mittwoch, 08. Juli 2020 um 13:09 Uhr
> *Von:* "Daniel @jfd553" 
> *An:* "pierz...@yahoo.fr" , "Hannes Röst" <
> hannesro...@gmx.ch>
> *Cc:* "Talk-CA OpenStreetMap" 
> *Betreff:* Re: [Talk-ca] NRCan lakes
> OMG, a lot of pertinent questions!
> You are summarizing questions than were discussed on this list over the
> last decade. Discussions about canvec/osm data modeling, internal canvec
> data sources, import problems, edits problems, and artifacts from osm
> validation tools' history!
> Because of that, you cannot assume any coast-to-coast consistency with the
> problems you have identified, although you can find them almost everywhere.
> Here are some clues. Canvec model did not change much over years but the
> sources used to build the product changed (from federal to
> provincial/municipal). As far as I know,  canvec.osm product is not
> maintained anymore, even if its last version is still available. When you
> find inconsistencies, look at data history. It may help to identify if a
> problem comes from an initial import, from an adjustment with existing
> data, from a duplicated erroneous import, or from subsequent edits.
> Good mapping!
> Daniel
>
> Sent from Galaxy S7
> --
> *From:* Hannes Röst 
> *Sent:* Wednesday, July 8, 2020 11:41:50 AM
> *To:* pierz...@yahoo.fr 
> *Cc:* Talk-CA OpenStreetMap 
> *Subject:* Re: [Talk-ca] NRCan lakes
>
>
> Dear Pierre
>
> Thanks a lot, your explanation of the history is very helpful.  I can also
> see on the wiki and the mailing list some threads and pages that explain
> the import but some of the wiki pages are quite old (10 years or so) and
> its not clear whether they still all apply and contain current policy.
>
> In your example it seems that the import produced duplicated ways
> sometimes where the lake 

Re: [Talk-ca] can I submit road data?

[Kevin Farrugia]

Hey Jason,

Imports are quite the pain to try and do - there's a whole process in place
now to do them. It stems from the experience in the States of an import
more than a decade ago of the TIGER data (from the Census Bureau) that is
still being fixed after pretty large amounts of time working through it.

There could be multiple reasons for all of the road splits you're seeing-
one is that in most import data sources roads are split at traversable
intersections (as you would find in most GIS datasets), another reason is
that in OSM streets are split wherever there is a change in attributes, for
example where speed limits change, turn lanes appear/disappear, surface
types changes, or there's a bridge.

It might be worth trying Esri imagery.  I've noticed in the municipality I
work for, as well as others in the Toronto area, that they buy the aerial
imagery that we commission them to fly every spring. It might not be the
freshest available, but I've found the accuracy to be more accurate than
other commercial imagery available.

---
Kevin F

On Tue., Jul. 7, 2020, 1:02 p.m. Jason Carlson, 
wrote:

> While waiting for a response I think if I import roads that already exist
> (albeit incorrectly) it will possibly be just as much work to fix. I tried
> editing changes but the aerial photos by Bing are horribly inaccurate in
> some places. I think they must pay for accuracy based on the amount of
> population in an area. For example, one rural road comes to the right edge
> of a Bing aerial tile and stops as on the adjacent tile the road abruptly
> starts 30 meters to the south. I just noticed however I can load other
> aerial backgrounds including my own which is very accurate. The only thing
> that sucks is I have a lot of data that is missing such as road width, lane
> numbers, surface type, road name aliases (like historical or common local
> names), speed limits, even signage locations (like yield or stops). With my
> 3300+ roads (of which OpenStreetMap has split into a heck of lot more
> unnecessarily probably from the initial import) this is going to take some
> time to fix but hopefully after I do some mapping programs that use
> OpenStreetMaps will help people navigate to rural addresses in our region
> as right now GPS units are pretty much useless out here.
>
>
> On Fri, Jun 26, 2020 at 11:53 AM Jason Carlson 
> wrote:
>
>> I noticed a number of roads in our county are incorrect in our area (as
>> are most rural areas with next to no population). I recently rebuilt all
>> our GIS road data and submitted it to an organization that then
>> redistributes it to emergency dispatch services and about 25
>> organizations/companies. I did not see OpenStreetMap as one of the ones
>> they send data too so I was wondering if I could submit that data myself to
>> them?
>>
>> Jason
>>
> ___
> 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] WikiProject Canada Post - franchise assessment

[Kevin Farrugia]

Canada Post is a Crown Corporation so it kind of operates in its own world
even though it's subsidised and owned by the government. I don't think the
open government directive applied across all Crown ABCs but to the civil
service portion.

We're not doing an import of post offices in the actual sense so it may be
okay.

I think this is also a little different since Canada Post doesn't make
money selling the location of their offices like they do postal codes so
chances are they wouldn't target this as an issue.

---
Kevin

On Tue., Jun. 16, 2020, 10:18 a.m. john whelan, 
wrote:

> I think you can use it to see where to look.
>
> If there is only one building and you can see a Canada Post logo
> floating around I think it is fair game.
>
> Canada Post is part of federal government so there is some sort of
> commitment to Open Data floating around under the Federal government's open
> data initiative.
>
> Cheerio John
>
> On Tue, Jun 16, 2020, 09:10 Justin Tracey  wrote:
>
>> Is it legal to import that data from the Canada Post site?
>>
>>  - Justin
>>
>> On Tue, Jun 16, 2020 at 8:04 AM David Nelson via Talk-ca <
>> talk-ca@openstreetmap.org> wrote:
>>
>>> I have just finished assessing which post offices in Canada among those
>>> we have not yet added to OSM are franchises, and which of those franchise
>>> outlets' parent businesses already appear in our database.  Those such
>>> locations are now marked in pale red on the project's spreadsheets.  The
>>> node for each such post office location just has to be positioned right
>>> next to its respective parent business.  You can determine what each parent
>>> business is by looking on Canada Post’s own website, or by doing a simple
>>> web search for the postal code of each such outlet.  With this, we are in a
>>> position to immediately add nearly 700 more Canada Post outlets across the
>>> country to OSM.  This would bring the progress of this project to a
>>> completion measure of just under 48 percent.
>>>
>>>
>>>
>>> - David E. Nelson
>>>
>>> 
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Tagging sidewalks as separate ways and issues with bicycle routing

[Kevin Farrugia]

Correct - it's a municipal bylaw thing. For example, Burlington explicitly
allows bikes on sidewalks except downtown, while next door in Oakville
riding on sidewalks isn't allowed anywhere. Brampton allows bikes on
sidewalks if the wheel size is less than a certain size so that kids can
legally ride on sidewalks.

It's quite a patchwork/mess and best to avoid sidewalks in almost all cases
- adding them to the map in the first place or using them in routing when
not required...

---
Kevin/Kevo

On Fri., Apr. 3, 2020, 11:37 a.m. Justin Tracey,  wrote:

> I was assuming cyclists can figure out a turn indication onto a sidewalk
> should instead be interpreted as onto the adjacent street; maybe that's
> more difficult than I'd assumed.
>
> The Region of Waterloo allows bicycles on sidewalks in some situations,
> but I believe at least most of the constituent cities in it do not. In any
> case, it's certainly not provincial law for Ontario.
>
> On Fri, Apr 3, 2020 at 3:16 PM Martin Chalifoux <
> martin.chalif...@icloud.com> wrote:
>
>> When you follow a route with a riding app, you get turn prompts that are
>> then incorrect because a sidewalk is selected rather than the street. The
>> route is not just a line on a map, it becomes a set of turn-by-turn
>> directions eventually.
>>
>> What cities allow cycling on sidewalks anyway, seriously ? This sounds so
>> inadequate. That it is tolerated is one thing, but outright legal or
>> encouraged ? Makes no sense to me.
>>
>> On Apr 3, 2020, at 11:11, Justin Tracey  wrote:
>>
>> iD leaves all access tags undefined for sidewalks by default, what you're
>> seeing are the *implied* values (specifically, highway=footway implies
>> motor_vehicle=no, but does not make any implication about bicycle=*; scroll
>> down to the raw tags and you'll see both are left undefined). The reason
>> sidewalks cannot imply bicycle=no is that's not true in all legal
>> jurisdictions. The question is then whether routing engines should take
>> legal jurisdiction into account when deciding the default value for
>> bicycle=*, the way they do for maxspeed=*. The problem is that maxspeed=*
>> has defaults on a uniform provincial granularity, but bicycle=* has an
>> arbitrary granularity (any particular sidewalk could be subject to federal,
>> provincial, regional, or city laws).
>>
>> Personally, my approach has been noting when routing engines are taking
>> advantage of sidewalks they shouldn't be able to, and tagging those. Most
>> sidewalks run parallel to roads, and I assume cyclists/data consumers know
>> the respective rules they should be following, even if the routing engine
>> doesn't.
>>
>> On Fri, Apr 3, 2020 at 2:51 PM Martin Chalifoux via Talk-ca <
>> talk-ca@openstreetmap.org> wrote:
>>
>>> Maybe the issue is that in ID and I assume that is the Canadian default
>>> value, the bicycle access tag is left undefined. Why isn’t that tag
>>> defaulted to no as it is for cars ? Then an explicit yes tag can be added
>>> only to the odd place where cycling on a sidewalk is allowed. We are
>>> talking routing engines here, not the kid that plays on the street.
>>>
>>> On Apr 3, 2020, at 10:46, Nate Wessel  wrote:
>>>
>>> Which routing engines are causing problems exactly? Routing a bicycle on
>>> a sidewalk may be appropriate/reasonable in some cases and over short
>>> distances where one could be instructed to dismount and walk. I'd be
>>> interested to see some of the problematic routes that are being suggested
>>> to see if there isn't a more elegant way of resolving this.
>>>
>>> I personally only use explicit access tags where there is clear signage
>>> indicating some type of special access restriction. Otherwise the default
>>> should be assumed. Routing engines *should* be able to accommodate
>>> region differences in default values without needing to manually tag
>>> millions of ways. Whether they can or do allow that is a problem for the
>>> people developing the routing engines.
>>>
>>> Nate Wessel, PhD
>>> Planner, Cartographer, Transport Nerd
>>> NateWessel.com 
>>> On 2020-04-03 10:39 a.m., John Whelan wrote:
>>>
>>> I'd recommend bicycle=no and I live in Ottawa.  In Ottawa footpaths that
>>> connect in general are bicycle=yes as they come under municipal regulation
>>> but a sidewalk on a highway comes under provincial legislation which bans
>>> bicycles on sidewalks.  Sparks street is fun I think you are not permitted
>>> to ride your bicycle but I'm unsure if this is provincial, municipal or it
>>> might even be NCC which is federal of course.
>>>
>>> In the UK they are banned by law but in certain cities the Chief
>>> Constable has stated the law will not be enforced within the police force
>>> boundaries as a letter of interpretation.  It might be nice for Ottawa to
>>> do the same sometime but there again we have City of Ottawa police, OPP,
>>> RCMP and of course the PPS.
>>>
>>> Cheerio John
>>>
>>> James wrote on 2020-04-03 10:25 AM:

Re: [Talk-ca] Postcodes in Canada

[Kevin Farrugia]

I don't want to rain on the postal code party, and maybe I'm a little jaded
from using the data, but I use the Postal Code Conversion File (PCCF) from
Statistics Canada (who get it from Canada Post) at work.  In general I
would say that the postal code points are in mediocre shape.

Some things I've noticed about the data and postal codes in general:
* There is usually one postal code point per postal code, although there
are cases where there can be several points for a postal code.  For
example, with some postal codes, if you were to make them polygons, would
generate multiple polygons that are intersected by other postal codes.
* Postal codes, especially rural ones, pop in and out of existence and so
are a little harder to track and are less permanent than addresses.
* Postal codes will sometimes jump from one side of a road (even
municipality) between years as they try to improve accuracy.
I would check out the Limitations section if you'd like to see more:
https://www.canadapost.ca/cpc/assets/cpc/uploads/files/marketing/2017-postal-code-conversion-file-reference-guide-en.pdf

Forward Sortation Areas do exist as open data through Statistics Canada -
StatsCan generates these FSA polygons based on respondents of the Census.
There are two limitations to this dataset on which I would advise against
importing it into OSM:
1) Since businesses do not respond to the Census, they generally do not
have FSAs for large industrial areas.  These areas are covered by the
nearest FSA that they know about/can define, but this can also cause some
movements of boundaries from Census to Census.
2) Because postal codes are created for the purpose of mail sortation and
delivery, the FSA boundaries StatsCan is able to create are not exact.
Here's the reference document if you're interested:
https://www150.statcan.gc.ca/n1/pub/92-179-g/92-179-g2016001-eng.htm

If at some point they did release it as open data, it might be decent
enough for the purposes of general geocoding in OSM, I just don't want
people to think it's as well maintained and reliable as some other types of
government data.

-Kevin (Kevo)


On Wed, 2 Oct 2019 at 20:39, James  wrote:

> funny you should mention geocoder.ca
>
> The owner of that website was sued by Canada Post because he was crowd
> sourcing postal codes. Just recently (2 ish years ago?) they dropped the
> lawsuit because they knew they didnt have a case(He came to the Ottawa
> meetups a couple of times)
>
> On Wed., Oct. 2, 2019, 8:08 p.m. Jarek Piórkowski, 
> wrote:
>
>> Yeah, Canada Post currently considers postal codes their commercial
>> data. Crowd-sourcing all or a substantial amount of full codes seems
>> infeasible. Crowd-sourcing the forward sortation areas (the first A1A)
>> seems difficult since verifiability is going to be a problem
>> especially around the edges of the areas.
>>
>> The website OpenStreetMap.org returns results for some postal codes
>> from a third-party database https://geocoder.ca/?terms=1 which is not
>> ODbL-compatible either.
>>
>> Partial mapping is causing some problems with tools like Nominatim
>> that attach the nearest tagged postcode to search results, often
>> resulting in improper postal codes for reverse address lookups,
>> however that is arguably a tooling problem and not an OSM problem per
>> se.
>>
>> This isn't going to be pretty until Canada Post is persuaded to free
>> the data. Call your MP, everybody.
>>
>> --Jarek
>>
>> On Wed, 2 Oct 2019 at 17:38, john whelan  wrote:
>> >
>> > " The number one request on open.canada.ca is to open the postal code
>> database.  Feel free to add your vote.
>> https://open.canada.ca/en/suggested-datasets;
>> >
>> > Cheerio John
>> >
>> > On Wed, 2 Oct 2019 at 13:32, john whelan  wrote:
>> >>
>> >> On the import mailing list there is a proposal to import postcodes in
>> the UK one of the reasons given was that many like to input a postcode to
>> get directions on smartphones using things like OSMand.
>> >>
>> >> I don't think an Open Data source with the correct licensing is
>> available in Canada but OSMand appears to be able to use the postcode if it
>> is entered in the map as part of the address.  Is there any Open Data that
>> might be useful?
>> >>
>> >> I don't know if it is possible but could something be used to extract
>> postcodes in the current map and from there perhaps we could come up with a
>> list of missing postcodes that need one address with it in mapped?
>> >>
>> >> As a minimum if you could add a few in you know from local knowledge
>> that might help fill in some gaps.
>> >>
>> >> Thoughts
>> >>
>> >> 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
>>
> ___
> 

Re: [Talk-ca] Importing buildings in Canada

[Kevin Farrugia]

Hi Eric,

Welcome to OpenStreetMap!  It's also great that you're able to provide so
much imagery to Mapillary.

Are there certain areas of Ontario that are a priority or certain
attributes that are most important to your routing?  For example, maybe
Stouffville is in general a big issue for you or there are many missing
speed limits in Markham.

People on this list may be able to help out and map remotely with the
imagery you're providing or go collect information when they have free time.

---
Kevin F

On Mon., Sep. 30, 2019, 10:03 p.m. Eric Geiler, 
wrote:

> Team Canada, (unsure who this should be address to)
>
>
>
> We are a local/regional courier and trucking company in southern Ontario
> with a decent sized fleet.  We are using Mapbox for our mapping / nav
> engine, therefore subject to using OSM data.  We have noticed a number of
> “issues/lack of data” for southern Ontario.  This ranges from lack of lane
> info, to lack of buildings, missing streets, missing exit/on-ramps to for
> Hwy 400 (which we added, and had Mapbox expedite the changesets) as it
> affected navigation for our drivers.
>
>
>
> We are currently using a few devices to provide street level imagery via
> Mapillary, with a push coming shortly to map 1000km per day of street
> imagery.  We are currently mapping about 250km per day in York Region.  Our
> internal goal is to provide /gathered street level imagery for 75% York
> Region by end of January 2020.
>
>
>
> We are not in a position to provide map edits etc, as due to staff
> resources and lack of experience, our staff are not suited to become ‘map
> editors’ as our core business is transportation.  We are just trying to
> assist the editors with accurate ground level info.
>
>
>
> I would be interested in further understanding how we can become involved
> on a regional level to improve OSM in southern Ontario.
>
>
>
>
>
> [image: EricGeiler-1]
>
>
>
> *From:* Nate Wessel 
> *Sent:* Friday, September 27, 2019 12:03 PM
> *To:* talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>
>
>
> John,
> You are once again purposely mischaracterizing my position on this and I
> do not appreciate it one bit. Your import did not follow the import
> guidelines and was not approved by the broader community. It was not sent
> out to the mailing list, it was barely documented, it was not posted on the
> import page on the wiki... I could go on. I was not the only person who had
> a problem with it - I was just the first to say something. The buildings
> imported in Toronto were very low quality IMO and the changes were
> happening very, very quickly and without notice.
>
> But we do not need to rehash old fights.
>
> I would like to see buildings (re)imported in Toronto (the rest of Canada
> is not really my business), but I would like to see it done right. I can
> elaborate what I mean by that, but so can the archives of this mailing
> list. If people are interested in engaging in a serious discussion about
> moving forward with a building import for Toronto, I am happy to engage
> constructively with that.
>
> Respectfully,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
>
> On 2019-09-27 11:44 a.m., john whelan wrote:
>
> From memory we have imported Ottawa's buildings under the correct license
> (Stat Can so the federal government's open data license) and the quality
> was deemed acceptable by the local mappers.
>
>
>
> Then we opened up a second import plan to import buildings and a fair
> number were imported.  This included an task manager set up with tiles to
> assist the mapping.
>
>
>
> The data sources were different as each municipality created their own
> source.
>
>
>
> My understanding is some mappers thought the data should be preprocessed
> and two or three were going to come up with a plan to preprocess the data.
>
>
>
> About that time an American mapper, Nate, who was living in Toronto took
> exception to 1,000,000 buildings being imported in Western Canada and
> requested the DWG to remove them without waiting for discussion on talk-ca
> to address his concerns.
>
>
>
> We do have three sources of correctly licensed data, the Stat Can data
> sets, the Microsoft data sets, and the NR Canada LiDAR data.
>
>
>
> I do know that a number of departments and agencies would like to use
> buildings and although they can use the open data sources using OSM would
> be more convenient.
>
>
>
> I'm not sure what if anything is happening at the moment.
>
>
>
> Are we expecting local groups to draw up their own import plan as Ottawa
> did since we seem to be unable to get a consensus across Canada?
>
>
>
> My gut feeling is with three sources of data we'll see new mappers
> importing in buildings without going through an import process.  Are we
> content to let that happen?
>
>
>
> Have whoever it was who was going to come up with a preprocessing plan
> done so?  Has it been accepted by the rest of 

Re: [Talk-ca] Open Data for Airdrie AB

[Kevin Farrugia]

Hi Joshua,

The national data that gets mentioned here is actually municipal data
rolled up into one federated Federal dataset to avoid licensing issues
since the federal license has been approved by OSM.

As for the national import, that's for others to update you on 

---
Kevin (Kevo)

On Mon., Apr. 22, 2019, 3:42 p.m. Joshua Kenney, 
wrote:

> Hello everybody!
> Relatively new mapper here.  I've been working on mapping my home town,
> and a couple of other places I've been, for the past 3 or 4 months.
>
> I have found that my city of Airdrie, AB has a number of datasets
> available under an Open Data Licence:
>
> http://data-airdrie.opendata.arcgis.com/pages/our-open-licence
> The licence terms look straight forward enough, are there any additional
> steps I need to take to confirm compatibility with OSM?
>
> One of the datasets includes building footprints.  Would importing that
> get in the way of the import of the national data? Where can I access the
> national data to compare the quality?
>
> --Joshua
>
>
> ___
> 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] Saints in street names in Ontario

[Kevin Farrugia]

No, I'm referring to the official records of street names held by
municipalities. In many cases, at least in newer developments, they seem to
be abbreviated. If it's officially short form then it would be incorrect to
say it's Saint.

---
Kevin Farrugia

On Fri, Mar 15, 2019, 1:08 PM Martin Chalifoux 
wrote:

> I think the osm database should use proper words. Abbreviating is a
> rendering issue and many rendering engines can do that. Space constraints
> on signage dictate the use of abbreviations for those.
>
>
>
> On Mar 15, 2019, at 12:50, Kevin Farrugia  wrote:
>
> Hi Jarek,
>
> I agree that of the sign has a short form for saint then it should be that
> way on the map too, as the sign text comes from the official records of
> street names.
>
> I think St. Is better with a period as it makes it less ambiguous to it
> being an abbreviation and it may help screen readers or spoken directions
> in maps provide the right information.
>
> ---
> Kevin F
>
>
> On Fri, Mar 15, 2019, 12:44 PM Jarek Piórkowski 
> wrote:
>
>> Hi all,
>>
>> A couple of months back we established a consensus [1] that "St." in
>> Canadian English city names should not be expanded.
>>
>> I have been thinking of having the same for street names, and would
>> like to ask people's opinions.
>>
>> My main motivation is St. Clair Avenue in Toronto. Every city source I
>> could find and every street sign I saw in Mapillary says "St. Clair"
>> or "St Clair". The TTC stations and routes are consistently "St
>> Clair". The City uses "St. Clair Avenue West" in official documents
>> like [2]. Geobase in Toronto has "St Clair Avenue West" , "St Clarens
>> Avenue", and "St Helens Avenue". Currently most of the street is named
>> "Saint Clair Avenue West/East" in OpenStreetMap, but this is changed
>> for some parts of the road every now and then.
>>
>> As a local mapper I would say that "St. Clair Avenue West" is the full
>> name. Unlike with "Av", "Ave", "W", the "St" in "St Clair" is IMO not
>> an abbreviation.
>>
>> Across the Golden Horseshoe names starting with "St. " or "St " seem
>> to be a bit more common [3] than "Saint" [4], I gather the
>> acronym-expanders have not looked as much outside of Toronto.
>>
>> Would we have Ontario community consensus for a statement along the lines
>> of:
>> "Where "St." or "St" is normally used in the full street name, it
>> should not be expanded to "Saint" even if pronounced so"?
>>
>> (I don't know what the naming conventions are in other provinces, so I
>> focus on Ontario for now. Apologies for being Ontario-centric, but I
>> don't know of a better venue that is Ontario-specific. I'll post links
>> to this message in wiki talk pages for Ontario, WikiProject_Canada,
>> and Canadian_tagging_guidelines.)
>>
>> As part of my checks I also looked at London UK, which I gather might
>> be the most-intensively-mapped English-speaking city. (Recommendations
>> for better-mapped English-speaking cities welcome). Searching for
>> "St." in road names [5], it has street names for bigger streets like
>> "St. John Street" and "St. Pancras Way"; [6] has name="St. Paul's
>> Road" + not:name="Saint Paul's Road" and has had so for 5 years.
>> Compare with searching for "Saint" [7] which also has some hits,
>> suggesting that both can be valid depending on what is signed and
>> used. (Or maybe it's just inconsistent.)
>>
>> [1]
>> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Municipality_Names
>> [2]
>> https://www.toronto.ca/legdocs/mmis/2016/ey/bgrd/backgroundfile-92339.pdf
>> [3] https://overpass-turbo.eu/s/H1M
>> [4] https://overpass-turbo.eu/s/H1P
>> [5] https://overpass-turbo.eu/s/GPh
>> [6] https://osm.org/way/230843467
>> [7] https://overpass-turbo.eu/s/GPi
>>
>> Thanks,
>> --Jarek
>>
>> ___
>> 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] Saints in street names in Ontario

[Kevin Farrugia]

However, the street name is legally "St." in almost all cases, so saint is
wrong.

-------
Kevin Farrugia

On Fri, Mar 15, 2019, 1:00 PM Martin Chalifoux via Talk-ca <
talk-ca@openstreetmap.org> wrote:

> The word is definitely Saint. St is a contraction and neither proper
> English or French. It has the same Latin roots as sanctification and
> similar words.
>
> Similarly Av is a contraction for Avenue and not a word.
>
>
> https://en.m.wikipedia.org/wiki/Abbreviation
>
>
>
> On Mar 15, 2019, at 12:42, Jarek Piórkowski  wrote:
>
> Hi all,
>
> A couple of months back we established a consensus [1] that "St." in
> Canadian English city names should not be expanded.
>
> I have been thinking of having the same for street names, and would
> like to ask people's opinions.
>
> My main motivation is St. Clair Avenue in Toronto. Every city source I
> could find and every street sign I saw in Mapillary says "St. Clair"
> or "St Clair". The TTC stations and routes are consistently "St
> Clair". The City uses "St. Clair Avenue West" in official documents
> like [2]. Geobase in Toronto has "St Clair Avenue West" , "St Clarens
> Avenue", and "St Helens Avenue". Currently most of the street is named
> "Saint Clair Avenue West/East" in OpenStreetMap, but this is changed
> for some parts of the road every now and then.
>
> As a local mapper I would say that "St. Clair Avenue West" is the full
> name. Unlike with "Av", "Ave", "W", the "St" in "St Clair" is IMO not
> an abbreviation.
>
> Across the Golden Horseshoe names starting with "St. " or "St " seem
> to be a bit more common [3] than "Saint" [4], I gather the
> acronym-expanders have not looked as much outside of Toronto.
>
> Would we have Ontario community consensus for a statement along the lines
> of:
> "Where "St." or "St" is normally used in the full street name, it
> should not be expanded to "Saint" even if pronounced so"?
>
> (I don't know what the naming conventions are in other provinces, so I
> focus on Ontario for now. Apologies for being Ontario-centric, but I
> don't know of a better venue that is Ontario-specific. I'll post links
> to this message in wiki talk pages for Ontario, WikiProject_Canada,
> and Canadian_tagging_guidelines.)
>
> As part of my checks I also looked at London UK, which I gather might
> be the most-intensively-mapped English-speaking city. (Recommendations
> for better-mapped English-speaking cities welcome). Searching for
> "St." in road names [5], it has street names for bigger streets like
> "St. John Street" and "St. Pancras Way"; [6] has name="St. Paul's
> Road" + not:name="Saint Paul's Road" and has had so for 5 years.
> Compare with searching for "Saint" [7] which also has some hits,
> suggesting that both can be valid depending on what is signed and
> used. (Or maybe it's just inconsistent.)
>
> [1]
> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Municipality_Names
> [2]
> https://www.toronto.ca/legdocs/mmis/2016/ey/bgrd/backgroundfile-92339.pdf
> [3] https://overpass-turbo.eu/s/H1M
> [4] https://overpass-turbo.eu/s/H1P
> [5] https://overpass-turbo.eu/s/GPh
> [6] https://osm.org/way/230843467
> [7] https://overpass-turbo.eu/s/GPi
>
> Thanks,
> --Jarek
>
> ___
> 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] Saints in street names in Ontario

[Kevin Farrugia]

Hi Jarek,

I agree that of the sign has a short form for saint then it should be that
way on the map too, as the sign text comes from the official records of
street names.

I think St. Is better with a period as it makes it less ambiguous to it
being an abbreviation and it may help screen readers or spoken directions
in maps provide the right information.

---
Kevin F


On Fri, Mar 15, 2019, 12:44 PM Jarek Piórkowski  wrote:

> Hi all,
>
> A couple of months back we established a consensus [1] that "St." in
> Canadian English city names should not be expanded.
>
> I have been thinking of having the same for street names, and would
> like to ask people's opinions.
>
> My main motivation is St. Clair Avenue in Toronto. Every city source I
> could find and every street sign I saw in Mapillary says "St. Clair"
> or "St Clair". The TTC stations and routes are consistently "St
> Clair". The City uses "St. Clair Avenue West" in official documents
> like [2]. Geobase in Toronto has "St Clair Avenue West" , "St Clarens
> Avenue", and "St Helens Avenue". Currently most of the street is named
> "Saint Clair Avenue West/East" in OpenStreetMap, but this is changed
> for some parts of the road every now and then.
>
> As a local mapper I would say that "St. Clair Avenue West" is the full
> name. Unlike with "Av", "Ave", "W", the "St" in "St Clair" is IMO not
> an abbreviation.
>
> Across the Golden Horseshoe names starting with "St. " or "St " seem
> to be a bit more common [3] than "Saint" [4], I gather the
> acronym-expanders have not looked as much outside of Toronto.
>
> Would we have Ontario community consensus for a statement along the lines
> of:
> "Where "St." or "St" is normally used in the full street name, it
> should not be expanded to "Saint" even if pronounced so"?
>
> (I don't know what the naming conventions are in other provinces, so I
> focus on Ontario for now. Apologies for being Ontario-centric, but I
> don't know of a better venue that is Ontario-specific. I'll post links
> to this message in wiki talk pages for Ontario, WikiProject_Canada,
> and Canadian_tagging_guidelines.)
>
> As part of my checks I also looked at London UK, which I gather might
> be the most-intensively-mapped English-speaking city. (Recommendations
> for better-mapped English-speaking cities welcome). Searching for
> "St." in road names [5], it has street names for bigger streets like
> "St. John Street" and "St. Pancras Way"; [6] has name="St. Paul's
> Road" + not:name="Saint Paul's Road" and has had so for 5 years.
> Compare with searching for "Saint" [7] which also has some hits,
> suggesting that both can be valid depending on what is signed and
> used. (Or maybe it's just inconsistent.)
>
> [1]
> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Municipality_Names
> [2]
> https://www.toronto.ca/legdocs/mmis/2016/ey/bgrd/backgroundfile-92339.pdf
> [3] https://overpass-turbo.eu/s/H1M
> [4] https://overpass-turbo.eu/s/H1P
> [5] https://overpass-turbo.eu/s/GPh
> [6] https://osm.org/way/230843467
> [7] https://overpass-turbo.eu/s/GPi
>
> Thanks,
> --Jarek
>
> ___
> 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] Ongoing Canadian building import needs to be stopped, possibly reverted

[Kevin Farrugia]

Data is currently stored in OSM by mappers this way, regardless of the
source. I don't think a height or which part is needed to use the building
part tags. It provides the basis for later additions should a mapper be so
inclined to add it.

---
Kevin Farrugia

On Thu., Jan. 24, 2019, 11:51 a.m. Nate Wessel  Is it sufficient to tag fragments as building:part without indicating
> which part or how many stories? If the data is properly structured, this
> seems like something that could be handled in preprocessing by checking for
> overlapping polygons. It looks like perhaps we might just have to find the
> largest part for the footprint (building=yes) and any intersecting smaller
> buildings (building:part=yes).
>
> We might also need to generate some building relations for more complex
> features.
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com <http://natewessel.com>
>
> On 1/24/19 11:40 AM, Yaro Shkvorets wrote:
>
> OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
> It's not in the import wiki though since whoever wrote it didn't know
> about it at the time.
> Here's what I mean by mapping 3D features in our case. Say there is a
> residential tower on a podium. In the StatsCan data usually you would find
> both of these outlines - large podium outline and smaller tower outline
> inside it. They would both be tagged with "building=yes" tag. Obviously we
> can't upload that as-is. We can either just remove tower outline leaving
> only 2D podium outline. Or, we can tag the tower outline with
> "building:part=yes". Someone local can add other tags to it later on, such
> as "building:levels", "building:material", "building:min_level",
> "addr:housenumber" (if there are two towers on one podium with different
> house numbers for example), etc. I find the latter approach to be the right
> one.
>
> On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel  wrote:
>
>> Hi Yaro,
>>
>> I just had a chance to look at the documentation on the source data and I
>> wasn't able to find anything about 3D features or parts of buildings being
>> mapped separately. Are you guessing here, or is there documentation on
>> this? If so can you point us to it?
>>
>> In any case, the big shapefiles from StatsCan don't provide enough
>> information to reconstruct any 3D geometries, so I'd be inclined to remove
>> these from the import unless they can be brought in from another source
>> with better documentation / attribute tagging. (i.e. City of Toronto?)
>>
>> Thanks,
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com <http://natewessel.com>
>>
>> On 1/18/19 2:48 PM, Yaro Shkvorets wrote:
>>
>> Jarek,
>> There is no question we want this data. I went through much of it in
>> Toronto and Kingston and I found it to be very good, consistent and
>> precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes
>> ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D
>> features (when several buildings appear overlapped in the dataset) but you
>> just need to be familiar with `building:part` tag to sort through it. I
>> haven't looked at other provinces but in Ontario I really have no
>> complaints about dataset quality whatsoever. Also I don't get Nate's
>> "wildly unsimplified geometries" comment. IMO geometries are just perfectly
>> detailed.
>>
>>
>> On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski 
>> wrote:
>>
>>> Some more thoughts from me.
>>>
>>> Building outlines, particularly for single-family subdivisions as seen
>>> in Canadian suburbs, are extremely labour-intensive to map manually.
>>>
>>> My parents' house is now on OSM - accurately. They live in a city with
>>> about 10,000 buildings, and about 0.5 active mappers. This wouldn't
>>> been completed manually in the next 5 years.
>>>
>>> An option to do this automatically with a computer algorithm detecting
>>> objects from imagery could be suggested, but this has not been very
>>> accurate in OSM in the past, even when there is decent imagery. The
>>> only other feasible data source is government, where they have such
>>> data more or less.
>>>
>>> The alternative is of course the opinion that we should not have
>>> building outlines until someone goes through and adds the buildings
>>> manually. In practice what I've seen done in Toronto is that bigger
>>> buildings 

Re: [Talk-ca] Trans-Canada Highway research

[Kevin Farrugia]

The proper name for the highways that are under the Kings Highway system
(400-Series included) is "Highway xxx" or Highway xx, with the exception of
the QEW.  Highways signs and government data follow the same rules.

The Trans-Canada as a name/deaignation is almost inconsequential in Ontario
and to Ontarians.

-------
Kevin Farrugia


On Mon, Mar 26, 2018, 11:46 AM Viajero Perdido, <
viajero.perdido.spam.buc...@gmail.com> wrote:

> On 18-03-26 05:33 AM, talk-ca-requ...@openstreetmap.org wrote:
> > Message: 3
> > Date: Mon, 26 Mar 2018 11:33:14 +
> > From: James <james2...@gmail.com>
> > To: "Olivia Robu - (p)" <olivia.r...@telenav.com>
> > Cc: Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
> > Subject: Re: [Talk-ca] Trans-Canada Highway research
> > Message-ID:
> >   <
> cank4qi_u9uveodoc8try-mic-xgxsxbuuv0n9pssjo0v+jr...@mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > highway 417 should be tagged as highway 417 and not principally
> transcanada
> > way as this is how it's known locally. It can be tagged in transcanada
> > relation, but it's mainly known as the 417
>
> I disagree.  "Highway 417" is a low-value name, because the "ref" tag
> should already contain the number, causing numbered shields to be
> shown.  "Highway 417" is just a verbosification of the number.
> "Trans-Canada Highway", however, is a real name; it belongs in the name
> field.
>
> This way, most maps would show both name and number.
>
> To me, the (completely separate) issue is whether ordinary numbered
> highways should have a name tag at all, "Highway nnn", or simply nothing
> because "ref" takes care of it.  I've been able to find no guidance on
> this, and I've looked.  I've been leaving "Highway nnn" in place when I
> see it, which is most of the time.  But that's another discussion for
> another day.
>
> ___
> 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] Formatting of Municipality Names

[Kevin Farrugia]

Bernie is correct.  "City of", "Municipality of", "x County" is a legal
name that would be referring to the legal entity itself (the Government)
rather than the place.  The place should just be Toronto, Hamilton,
Mississauga etc..

The data source these legal names comes from has the legal name as it's
usually establishing the jurisdiction that contains the road.  The address
ranges are derived from the road system, so it's just been copied over.

-Kevin Farrugia
kevinfarru...@gmail.com

On 12 February 2018 at 21:02, Bernie Connors <bernie.conn...@unb.ca> wrote:

> I see the use of "City of" as indicating the official name of a
> municipality as it is defined in legislation. Here in New Brunswick the
> Municipalities Act‎ defines the official names of municipalities. Some opt
> to use "City of ", "Town of ", etc in the Municipalities Act and some
> don't. But when it comes to names on maps we should be more concerned with
> toponyms and not official names. The use of "City of ", "Town of ", etc is
> very rare in toponyms.  Here is a query on the Canadian Geographic Names
> Database searching for the term "of" in the "populated places" category -
> http://www4.rncan.gc.ca/search-place-names/search?q=
> of%5B%5D=985=O
>
> I only see two examples that include "City of ", "Town of ", etc across
> the entire country:
> City of Brant, ON
> Village of Queen Charlotte, BC
>
> Bernie.
>
> On Mon, Feb 12, 2018 at 7:45 PM, OSM Volunteer stevea <
> stevea...@softworkers.com> wrote:
>
>> I smell a harmonization with admin_level...not that there's anything
>> wrong with that.
>> SteveA
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
>
>
> --
> Bernie Connors
> New Maryland, NB
>
> ___
> 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] Formatting of Municipality Names

[Kevin Farrugia]

Hi Matthew,

Not having the "City of" or "Town of" would be preferred - the reason those
are there is that the CanVec data that was imported uses administrative
names in the data.

When people search or say an address out loud they would use "123 Yonge St,
Toronto" not "123 Yonge St, City of Toronto".  It's something that I think
was overlooked when the data was imported and has annoyed the hell out of
me when I see it...

As for examples like "North York, Toronto" - some people still use the
pre-amalgamation borough names for the suburbs that were annexed into the
City of Toronto.  Sometimes it's for a very good purpose - there are
multiple King, Queen, Main, etc. streets in the current city.  In the cases
you found, since there are so few, i would suggest the former city names be
moved to the city:suburb tag and Toronto stays in the addr:city tag?

-Kevin

On 12 February 2018 at 17:53, James  wrote:

> i believe "city of" is redundant as its a classification vs a name.
>
> Would we say "village of maniwaki"? nope.
>
> On Feb 12, 2018 5:51 PM, "Matthew Darwin"  wrote:
>
>> Hi,
>>
>> I am now reviewing the *addr**:city* tag.   Seems we are not very
>> consistent how we use it.  For example, Toronto:
>>
>>  110707 City of Toronto
>>9603 Toronto
>>   4 North York, Toronto
>>   2 Toronto, ON
>>   2 toronto
>>   1 York, Toronto
>>   1 Torontoitalian
>>   1 Toronto;City of Toronto
>>   1 Toronto
>>
>> Which is correct?  "*City of **Toronto*" or "*Toronto*"?   I would think
>> "Toronto"???   Why do people pick one over the other?
>>
>> There are more than 7000 unique names in Canada.  Below are the top 50.
>> Ottawa is not on the top of the list because there was a local decision to
>> not include the addr:city tag during address addition as there there are
>> many different "city" names since almagamation. (The official Canada Post
>> address still has the old municipality name prior to amalgamation while the
>> City of Ottawa works through de-duplicating street names).
>>
>>  110707 City of Toronto
>>  100066 Gatineau
>>   82606 Montréal
>>   79191 Surrey
>>   71932 Edmonton
>>   51096 Québec
>>   45716 City of Hamilton
>>   37232 Mississauga
>>   35763 Laval
>>   32029 Dartmouth
>>   30969 Kamloops
>>   27234 City of London
>>   25393 City of Brampton
>>   22881 Municipality of Chatham-Kent
>>   18534 Saguenay
>>   17921 Lévis
>>   17251 City of Vaughan
>>   16929 City of St. Catharines
>>   16796 Town of Markham
>>   16592 City of Kawartha Lakes
>>   16403 Trois-Rivières
>>   16086 City of Thunder Bay
>>   15788 Oakville
>>   15335 Sherbrooke
>>   14787 City of Niagara Falls
>>   14338 Norfolk County
>>   13966 City of Kingston
>>   13939 Fredericton
>>   12085 City of Oshawa
>>   11966 Saanich
>>   11950 Calgary
>>   11382 Terrebonne
>>   11332 Richmond Hill
>>   11321 City of Barrie
>>   11080 Town of Fort Erie
>>   10986 Cole Harbour
>>   10981 City of Burlington
>>   10641 Town of Whitby
>>   10635 Saint-Jean-sur-Richelieu
>>   10455 Drummondville
>>   10347 City of Guelph
>>9906 Municipality of Clarington
>>9666 City of Brantford
>>9603 Toronto
>>9487 Shawinigan
>>9384 City of Sarnia
>>9380 Red Deer
>>9102 City of Windsor
>>9044 City Of Sault Ste. Marie
>>8466 Sudbury
>>
>>
>> --
>> Matthew Darwinmatthew@mdarwin.cahttp://www.mdarwin.ca
>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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" <ian.bruse...@gmail.com> wrote:

> Kevin,
>
> That does make sense, but in the example Martijn gave, the starting point
> is well before the turning lane, so I'm picturing the car being there and
> the software still having time to make a choice which road to send it down.
> Why did OSRM pick to ignore the turning road given there is all the
> opportunity in the world to choose it instead of the actual intersection
> corner?
>
> Ian
>
>
>
> On Mar 30, 2017, at 5:19 PM, Kevin Farrugia <kevinfarru...@gmail.com>
> wrote:
>
> Hey Ian,
>
> The main purpose is to stop silly or dangerous things from happening. If a
> user misses their turn and the engine reroutes them to turn right where
> they shouldn't (or U-turn) the consequences could be catastrophic. When
> people are following a computer's instructions they'll follow them blindly
> (like when Michael drives his car into a lake in The Office).
>
> Plus if there's some weird error in the road topology or speed differences
> that could cause it to happen it's best to have them there as a catch.
>
> That's my view/reasoning from my experience working with routing and
> networks anyways.
>
> -Kevin (kevo)
>
>
> On Mar 30, 2017 7:02 PM, "Ian Bruseker" <ian.bruse...@gmail.com> wrote:
>
> Martijn,
>
> Can I ask what is possibly a really dumb question?  As stated earlier I'm
> not a lawyer, and really in truth I'm no cartographer either.  I generally
> stick to adding POIs for stores in local stripmalls, because that's not too
> dangerous to the map.  ;-)  Not being an expert in mapping, I probably just
> don't get why routing software works the way it does.  Why, in your example
> that you gave, would OSRM (or Scout) choose to send the user to the corner
> to turn at all?  I just don't get the logic of it.  The code seems pretty
> obvious (what I really am, after all, is a computer nerd).  In silly
> pseudocode: "if exists link-type road between current_location and
> destination, route via link road".  Why would it even look far enough ahead
> to see the corner to see whether there was a turn restriction or not, when
> there is already a more obvious path to take?  I mean, "obvious" to me as a
> human, I guess.  If I were driving down a road I'd never been to, and my
> passenger said "ok, take your next right", and I saw a turning
> lane/ramp/something, that's where I would go.  Shouldn't that be the
> routing software's first choice?  If it's looking far enough ahead on its
> path to even get to "you can't turn right here", then I would think its
> next step would be "ok, you can't turn right here, so I'll need to take
> them to the _next_ place they can turn right and route them back around the
> block to the road they want", not to then look backwards from the turn
> restriction to see if there was a linking road it could take instead.  The
> choice should have been made to take the linking road before it even cared
> whether it was allowed to turn them at the hard corner ahead, which would
> make putting the restrictions on the map for the purpose of "routing hint"
> sort of unnecessary, wouldn't it, if the software had just picked the
> correct route the first time?  Or worse, if they are there and the routing
> software hits them, wouldn't they then result in even longer routes,
> because once it got that far down the path, the only way to look is
> forward, which is a longer path?  I don't mean to tell you how to write
> your software. ;-)  Like I said, I don't actually know how routing software
> is coded.  And I'm sure you've considered this.  I'm just curious, given
> that consideration, _why_ would that route even happen in the first place
> (to take the hard corner rather than the link road)?
>
> Sorry if I'm derailing this discussion.  I don't touch the road network
> too much in my mapping unless I am pretty sure what I'm changing is
> obviously correct and simple, and I avoid weird intersections as much as
> possible.  I'm just curious to understand, so maybe in the future if I
> happen across such a situation, I'll have some idea how to map it so it
> doesn't send a driver making a dangerous turn or crashing through a fence
> or something.  ;-)
>
> Thanks,
> Ian
>
>
> On 30 March 2017 at 09:50, Marti

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] Municipal boundaries

[Kevin Farrugia]

Canada Post can be ignored, luckily, when it comes to municipal boundaries.
statscan's municipal boundaries are handy because it's country-wide and we
have a license agreement with them.

I don't think the boundaries with be an import in the true sense, more of a
guide that allows us to more easily create the boundaries.

In Ontario anyways boundaries usually follow roads and rivers so it's a
case of adding these to a boundary relation with the assistance of StatsCan
data.

On Mar 9, 2017 9:14 AM, "john whelan"  wrote:

> and just to add to the confusion Canada Post has its own set of rules.
> For example my official Canada Post address is Orleans yet no such
> municipality or town has ever existed.  There are other examples of Canada
> Post giving areas names.
>
> Cheerio John
>
> On 9 March 2017 at 08:55, Stewart C. Russell  wrote:
>
>> Hi Kevin -
>>
>> > CSDs are legal boundaries - I.e. the legal boundary of a lower tier
>> > municipality.
>>
>> I was a bit confused by terminology - I thought that Bjenk was referring
>> to LCTs. The one I live in looks like this:
>>
>> https://gist.github.com/scruss/e4778dfc3a0ea5261581e688c4332c93
>>
>> It's bounded by Eglinton Ave East, the Stouffville rail line, Corvette
>> Ave, Kennedy Rd, St Clair Ave East, the old GECO rail spur, and finally
>> Kennedy Rd again.
>>
>> There's nothing to say that you're in this area (ward?), and as it's
>> designated by boundary ways, any import relation would have to map on to
>> the existing ways in OSM, and not StatCan's data. Even though many of
>> our ways are based on earlier imports of Federal data, there isn't a
>> perfect match. To StatCan, Eglinton Ave East is just a line. To us, it's
>> multiple separated ways.
>>
>> I don't believe that these divisions belong in OSM, even although they
>> have legal definition for census use.
>>
>>  Stewart
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Municipal boundaries

[Kevin Farrugia]

Morning Bjenk,

Just a heads up - municipal boundaries are best of they aren't just
straight up imported because they're usually done as relations.  For
example, we generally add roads into the boundary relationship rather than
overlapping boundary and roads.  Here's one I did before:
http://www.openstreetmap.org/relation/4198907 as well as the municipalities
within it (CSD).

For those that don't know the StatsCan lexicon, in Ontario they relate as:
-Census Subdivision (CSD) is a single tier municipality or lower tier
municipality.
-Census Division (CD) is a upper tier municipality (county, region,
district) or a single tier municipality.

Hope that helps out,
Kevin


On Mar 7, 2017 8:51 AM, "Bjenk Ellefsen"  wrote:

Hello,

Municipal boundaries correspond to census subdivisions (CSD). I have seen
that many municipalities do not have a boundary yet. Is it ok if I start
adding some boundaries based on CSDs? Having the boundaries is important to
make extractions and analysis at the municipal level.

Bjenk

___
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] destination:street

[Kevin Farrugia]

Hey Martijn & everyone else,

The bulk of destination:street was added beginning with Mapbox's "Mapping
exit numbers and destinations in Canada", which described the methods to
use [https://github.com/mapbox/mapping/issues/220]  Since then, most of us
(me included) in Southern Ontario have just continued that method on the
map.  They used to be combined in the destination tag, but they've since
been separated out, so this is still actively used.  The documentation I
used to better understand it was on the Exit Info page:
http://wiki.openstreetmap.org/wiki/Exit_Info

I could see it having a bit more usefulness for routing purposes, but
you're on that side of the equation, not me :)

-Kevin (Kevo)

On Thu, Jan 19, 2017 at 8:00 PM, Martijn van Exel  wrote:

> Hi all,
>
> The Telenav mapping team noticed quite a few destination:street tags on
> (mostly) motorway_link off-ramps in Canada. This is an undocumented sub-tag
> of the destination tag so I am curious how it is being used and if there is
> some sort of consensus that is documented somewhere else than the OSM wiki.
>
> An Overpass query surfaced 1883 cases, http://overpass-turbo.eu/s/ln2
>
> Looking at a random one, http://www.openstreetmap.org/way/34154734 /
> http://openstreetcam.org/details/10767/4194 — I think in the US we would
> just map this as destination=Carman Road;Iriquois and destination:ref=1
>
> So my question is whether this is some relic of a past practice, or is
> this actively used and encouraged mapping practice and if so, where should
> it be documented? (https://wiki.openstreetmap.org/wiki/Proposed_features/
> Destination_details seems to be a good candidate.)
>
> We’re happy to help improve these tags based on OSC / Mapillary data but I
> wanted to make sure first that this is the way you all want to go.
>
> Happy mapping,
>
> Martijn van Exel
>
>
> ___
> 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] Fwd: [Imports] [Import] Ottawa Buildings & Addresses [Statistics Canada project]

[Kevin Farrugia]

Hi Christoph,

Sorry, after I sent my email I noticed I wasn't in the imports mailing
list.

Planimetrics represent whatever the ground condition was when the data was
created and updated, which is almost always done with high res
orthoimagery. If someone demolishes a shed in their backyard, the city
would likely need to notice it visually. Every place does it differently,
but that's likely what happens.

Don't think of planimetrics as what is planned, but rather map data that
isn't related to elevation. The Wikipedia definition is pretty decent:
https://en.wikipedia.org/wiki/Planimetrics#In_geography.  OSM data would be
considered planimetric.

Hope that clears it up a bit, :)

Kevin.

On Oct 25, 2016 9:44 AM, "James" <james2...@gmail.com> wrote:

>

>
> -- Forwarded message --
> From:* Christoph Hormann* <chris_horm...@gmx.de>
> Date: Tue, Oct 25, 2016 at 9:38 AM
> Subject: Re: [Imports] [Talk-ca] [Import] Ottawa Buildings & Addresses
[Statistics Canada project]
> To: James <james2...@gmail.com>
> Cc: OSM Imports List <impo...@openstreetmap.org>
>
>
> On Tuesday 25 October 2016, James wrote:
> > There is also a factual basis in the example Scruss provided:
> > https://wiki.openstreetmap.org/wiki/File:12.PNG
> >
> > TD Place(Renovated/New buildings constructed in Summer 2014) is not
> > mapped in the DWG(scruss said as far back as 2011)
> > In the newer data it is:
> > https://wiki.openstreetmap.org/wiki/File:13.PNG
>
> The fact that a lot of buildings are missing in 12.PNG not all of which
> are probably newly built idicates that these two data sets are not
> meant to represent the same feature set, likely the one in 12.PNG is
> limited to certain types of buildings (like houses).
>
> On Tuesday 25 October 2016, Kevin Farrugia wrote:
> > Generally the planimetric CAD drawings (what Stewart posted) are/were
> > the source for most municipal building footprints, from what I've
> > seen in my experience.
>
> If i understand this correctly that would mean the data set represents
> the state of affairs as they are planned, i.e. the plans submitted by
> the land owners to obtain permission to build which do not necessarly
> match what is actually built in reality or what might have been
> demolished or modified without knowledge of the authorities.
>
> --
> Christoph Hormann
> http://www.imagico.de/ <http://www.imagico.de/>
>
>
>
> --
> 外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] [Imports] [Import] Ottawa Buildings & Addresses [Statistics Canada project]

[Kevin Farrugia]

Generally the planimetric CAD drawings (what Stewart posted) are/were the
source for most municipal building footprints, from what I've seen in my
experience. In some cases the footprints are still maintained in that
format and exported out for GIS, while in other cases they're now
exclusively maintained in GIS. Ottawa may be doing the latter, which might
explain the mismatch between the two.  I know the latter has
happened/happens at my work.

On Oct 25, 2016 8:54 AM, "James"  wrote:

There is also a factual basis in the example Scruss provided:
https://wiki.openstreetmap.org/wiki/File:12.PNG

TD Place(Renovated/New buildings constructed in Summer 2014) is not mapped
in the DWG(scruss said as far back as 2011)
In the newer data it is:
https://wiki.openstreetmap.org/wiki/File:13.PNG

I know this as I am a local mapper.

On Mon, Oct 24, 2016 at 6:52 PM, James  wrote:

> I can guarantee that this data is roof level data. While I was examining
> data there were cart returns mapped as outlines. This data was also traced
> via orthophotos
>
> On Oct 24, 2016 6:45 PM, "Christoph Hormann"  wrote:
>
>> On Monday 24 October 2016, Stewart C. Russell wrote:
>> >
>> > > Could you please clarify what the alleged source of the building
>> > > data to be imported is?
>> >
>> > Yes, as far as I understand it, at least: these data to be imported
>> > were given to a group of OSM contributors by the City of Ottawa. They
>> > have explicit permission to include it in OSM from the City. The only
>> > place you can inspect the data is on the contributors' own hosting
>> > sites, as the city doesn't host it anywhere. Details of the licence
>> > and permissions are on the Ottawa import information page.
>>
>> I would then suggest to contact the person who provided the files for
>> metadata and specifications on those, in particular dates and methods
>> of survey, processing applied, especially coordinate system conversions
>> and specifications on what exactly is contained in it (i.e. what the
>> definition of a building is here and if it's ground footprints or roof
>> outlines).  You also might want to specifically ask regarding the
>> geometry issues i pointed out earlier.
>>
>> You can be pretty sure the original producer of this data set has this
>> information and if there is interest in having this data in OSM they
>> should also be willing to provide such information.
>>
>> In OpenStreetMap we put high importance on knowing and documenting how
>> data is acquired since - as every experienced mapper knows - sources of
>> information can be faulty and misleading.  Just because someone says: I
>> have this data here and you may use it and it mostly looks reasonable
>> and plausible at the first glance does not mean we should throw all our
>> sense for critical evaluation of sources out of the window, especially
>> if you plan to add several hundred thousand new features.
>>
>> > The public 2011 data set is cut into 2×1 km tiles, slicing through
>> > buildings on the border. There are no common attributes which would
>> > allow repair, as the data is packaged in AutoCAD DWG files.
>>
>> This alone should not be a problem since you know the location of the
>> cuts and therefore could dissolve them based on position.
>>
>> The real question is - is there a factual basis for the assumption that
>> the data you intend to import is newer than the data in these files?
>> Note a different level of detail is not necessarily an indication for
>> age or accuracy of the data.
>>
>>
>> --
>> Christoph Hormann
>> http://www.imagico.de/
>>
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
>


-- 
外に遊びに行こう！

___
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] City of Ottawa imported buildings & addresses

[Kevin Farrugia]

Yup, those ones James. Sorry, I'm in something right now so I can't Google.
:P

On Oct 17, 2016 1:37 PM, "James" <james2...@gmail.com> wrote:

> Like this one Kevin?
> https://lists.openstreetmap.org/pipermail/talk-ca/2016-July/007034.html
>
> or this one?
> https://www.mail-archive.com/talk-ca@openstreetmap.org/msg07024.html
>
> or this one?
> https://lists.openstreetmap.org/pipermail/talk-ca/2016-August/007151.html
>
> or this one?
> https://lists.openstreetmap.org/pipermail/talk-ca/2016-August/007068.html
>
> Tired of googling, but it's the ones I found in a couple of seconds
>
> On Mon, Oct 17, 2016 at 1:27 PM, Kevin Farrugia <kevinfarru...@gmail.com>
> wrote:
>
>> Afternoon,
>>
>> I'm not part of the import, but it's been discussed over the past several
>> months as a project by Statistics Canada. You'll be able to see the
>> discussions start in the summer. I'm on my phone right now so I haven't
>> pulled up the archive to look for links (sorry).
>>
>> On Oct 17, 2016 1:22 PM, "Michael Reichert" <naka...@gmx.net> wrote:
>>
>>> Hi AJ,
>>>
>>> Am 17.10.2016 um 18:59 schrieb AJ Ashton:
>>> > I haven't seen any substantial discussion about the Ottawa buildings &
>>> > addresses import anywhere. I did see the thread a number of weeks back,
>>> > "Crowdsourcing buildings with Statistics Canada," but I didn't see
>>> > anything discussed that sounds like the planning of a mass import. The
>>> > wiki page linked from the discussion [0] is completely empty. From a
>>> > changeset discussion I was pointed to another section of the wiki [2]
>>> > which again has few details and does not sound like an import
>>> > ("...inviting contributors to crowdsource information on buildings").
>>> >
>>> > [1]: http://wiki.openstreetmap.org/wiki/Ottawa_Gatineau_Buildings
>>> > [2]:
>>> > http://wiki.openstreetmap.org/wiki/WikiProject_Canada#Crowds
>>> ourcing_buildings_with_Statistics_Canada
>>>
>>> Thank you for highlighting it.
>>>
>>> In addition to the lacking documentation, LogicalViolinist neither uses
>>> a dedicated account nor the import has been discussed at the Imports
>>> mailing list (I had a look at the subjects of the last six months). He
>>> has been informed about the Import Guideline on August 29, 2016.
>>> https://www.openstreetmap.org/changeset/41776742
>>>
>>> I have asked a DWG member to block him to stop the ongoing import and
>>> start a discussion.
>>> https://www.openstreetmap.org/user_blocks/1065
>>>
>>> Best regards
>>>
>>> Michael
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
>>> ausgenommen)
>>> I prefer GPG encryption of emails. (does not apply on mailing lists)
>>>
>>>
>>> ___
>>> 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] Ottawa has changed its Open Data licence.

[Kevin Farrugia]

I think Stewart means make sure that the City has the rights to distribute
it if the data is created by some third party.

For example, some cities get their building footprints from their
orthoimagery provider (they're created as part of the orthorectification
process) while others digitize them from their own imagery (imagery
licenses usually include a term that makes derivative products their own
property). In the first case it couldn't be imported to OSM but in the
second, provided the imagery license allows it, it would be okay for import.

On Sep 15, 2016 8:01 AM, "john whelan"  wrote:

> I'm fairly certain that the city owns the bus stops and doesn't rent them
> from a third party.
>
> Do you have an example of what to look for for the GTFS data?
>
> Thanks John
>
> On 14 September 2016 at 22:18, Stewart C. Russell 
> wrote:
>
>> On 2016-09-14 05:15 PM, john whelan wrote:
>> > http://ottawa.ca/en/mobile-apps-and-open-data/open-data-lice
>> nce-version-20
>>
>> This is very neat! I noticed it yesterday, but was too jetlagged from
>> XOXO to say anything.
>>
>> > It should now be aligned with the Federal Government one so that should
>> > mean we can import the GTFS bus stop file.
>>
>> In theory, yes, but please check with the city that they have all
>> third-party rights cleared in any data set you propose to import. As was
>> recently discussed on the Legal-talk list, OGL does not cover
>> third-party rights:
>> https://lists.openstreetmap.org/pipermail/legal-talk/2016-Se
>> ptember/008541.html
>>
>> (This is something that Bjenk and the Stat Can team will need to take
>> seriously for any import data sets they wish to use)
>>
>> cheers,
>>  Stewart
>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Fwd: Re: [OSM-legal-talk] Licence compatibility: Open Data Licence for The Regional Municipality of Peel (Version 1.0)

[Kevin Farrugia]

Thanks for looking into it Stewart.

Are there any examples from other exemptions that I can look at when I
bring it up?

On Sep 8, 2016 6:20 PM, "James" <james2...@gmail.com> wrote:

> This is something Kevin Farrugia might be able to help us with
>
> On Sep 8, 2016 6:12 PM, "Stewart Russell" <scr...@gmail.com> wrote:
>
>> I checked on OSM-legal. Would probably work if we had a statement from
>> Peel agreeing to inclusion. As is, it's likely not compatible.
>>
>> Stewart
>>
>> -- Forwarded message --
>> From: "Simon Poole" <si...@poole.ch>
>> Date: Sep 8, 2016 13:57
>> Subject: Re: [OSM-legal-talk] Licence compatibility: Open Data Licence
>> for The Regional Municipality of Peel (Version 1.0)
>> To: <legal-t...@openstreetmap.org>
>> Cc:
>>
>> >
>> > The additional terms are "a bit of" a problem, however might be
>> surmountable if they are willing to give us a statement specifically for
>> the inclusion in OSM (along the lines of that they agree that the inclusion
>> of the data in OpenStreetMap and distribution on terms of an open and free
>> licence fulfils the conditions).
>> >
>> > All variants of the OGL have a further issue in that you actually have
>> to verify that the Licensor has the necessary rights to licence -all- the
>> material in their dataset to you on these terms. This might seem like a
>> theoretical hurdle invented by me, alas it is not, as some of our UK
>> colleagues can testify.
>> >
>> > Simon
>>
>> ___
>> 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] [Import] Local community approval building & addresses in Peel region

[Kevin Farrugia]

That was addressed in James' previous email after Stewart asked about it.

"Yes, there is a reason I put this documentation in .md(mark down), as it
is the same format used by the wiki. So all information that is found on
github will be *transferred over to the wiki once local approval is done.*"

I wouldn't say that's unreasonable from my standpoint - if the local
(Canadian) community decides not to approve then we don't make dead wiki
pages.

Kevin

On Sep 8, 2016 4:00 PM, "Michael Reichert"  wrote:

> Hi James,
>
> Am 08.09.2016 um 18:49 schrieb James:
> > As per the import guide lines I wish to seek approval for importing
> > building outlines and addresses in the region of Peel.
> >
> > Documentation is available here:
> > https://github.com/osmottawa/imports/blob/master/Peel-Region.md
>
> You know that the import documentation has to be placed at OSM Wiki,
> didn't you? Step 4.2 of import guidelines says:
> > You must write a plan for your import in the OSM wiki. Create a wiki
> > page outlining the details of your plan. […]
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
>
> ___
> 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] [Import] Local community approval building & addresses in Peel region

[Kevin Farrugia]

Hey all,

I'm the person at Peel that works with GIS data and posts data up to the
open data site so I can probably answer most questions that might come up.

1) I can look into having some sort of change or special case of the
licence for OSM if it is a show stopper, but the bureaucracy can move very
slowly so it's nice avoiding it when possible ;). I'm not sure what the
process would be for changes so I can't say what timelines would be like,
either.

I'll be at mappy hour next week after my couple month hiatus so no need to
invite anyone special. :)

Kevin

On Sep 8, 2016 2:24 PM, "Stewart Russell"  wrote:

> Hi James:
>
> As per the import guide lines I wish to seek approval for importing
>> building outlines and addresses in the region of Peel.
>>
>> Documentation is available here:
>> https://github.com/osmottawa/imports/blob/master/Peel-Region.md
>>
>
> Seems like a decent outline, though I have questions:
>
>1. Is the Region of Peel licence compatible? I see that it has
>automatic termination on breech (like many OGL clones) but it also adds
>"ensure that Your Use of the Information does not breach or infringe upon
>any applicable laws". This may add usage implications for those downstream.
>(Some folks from Peel came to a Toronto Mappy Hour a few years back.
>They might be willing to give permission to use the data under an
>ODbL-compatible licence.)
>2. How will you be handling overlapping existing buildings?
>3. Will you be posting these notes to the OSM wiki? It's a requirement
>of the guidelines (https://wiki.openstreetmap.
>org/wiki/Import/Guidelines#Step_4_-_Documentation
>
> ),
>and given the recent visibility than Canada imports have gained, might help
>avoid a procedural reversion.
>
> cheers from Portland, OR
>
>  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] Mapping exit numbers and destinations in Canada

[Kevin Farrugia]

Yes - recently bootprint, andrewpmk, and I have been changing and
correcting the name tags to destination in Ontario along the 400-Series
highways. If you see a ramp/link that is named, it's fine to change it over
to destination or correct a problem you find with it.

On Aug 11, 2016 8:38 AM, "Harald Kliems"  wrote:

> Hi Manohar:
> It is my understanding that including destinations in the name is an
> artifact of people tagging for the renderer (and/or tagging destinations at
> a time before there was an established tagging scheme). If you search
> through the talk-ca archives, you should be able to find some discussions
> on the topic.
>  Harald.
>
> On Thu, Aug 11, 2016 at 7:25 AM Manohar Erikipati 
> wrote:
>
>> Hello everyone!
>>
>> Turn restriction sprint was met with an amazing response! We loved
>> working with you all on adding turn-restrictions in Canada. We appreciate
>> the timely help and suggestions we got which helped us add correct
>> restrictions and to also maintain the quality of data we were adding on to
>> OpenStreetMap. We hope that this support will continue further, as we are
>> embarking on mapping exit numbers and destinations in the same 5 cities of
>> Canada.
>>
>> We have made an easier workflow [1] with tasking manager [2] for adding
>> exit and destinations. We would like your assistance, participation and
>> continued involvement in the project. We have captured the details of this
>> task here [3].
>>
>> After a preliminary look into the already mapped exit numbers and
>> destinations, we have these observations:
>>
>> - We noticed that `destination` (places, cities) and `destination:ref`
>> (highways) tags are being added to the nodes of exits as `name` tags.
>> - Few exit nodes have destinations given in the `ref` tag.
>> - The `destination:street` (towards streets, avenues, boulevard, rue)
>> tags were not being used.
>>
>> To begin with, we have one question: Destinations given in the name tag
>> of nodes is not usual protocol for adding these tags. We want to make sure
>> whether it is valid or if we could change these tags to the `destination`
>> based tags accordingly. For more details, here's the complete breakdown
>> [4]. To reach out to more audience, we have captured this in a OSM diary
>> post [5]. We would like to hear from the community about the agreed method
>> of mapping exit numbers and destinations to take this forward.
>>
>> 1. https://gist.github.com/manoharuss/3a1b4f640aaf2c052365fcb1ddb09beb
>> 2. http://cfn-tasking-manager-staging-vpc-387856624.us-east-
>> 1.elb.amazonaws.com/project/20
>> 3. https://github.com/mapbox/mapping/issues/220
>> 4. https://gist.github.com/poornibadrinath/9333f1489732c32c3ffadd58e3068b
>> 7e
>> 5. https://www.openstreetmap.org/user/poornibadrinath/diary/39246
>>
>> Thank you!
>>
>> Cheers,
>> Manohar Erikipati
>> ___
>> 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] Crowdsourcing buildings with Statistics Canada

[Kevin Farrugia]

For clarification - Canada Post only owns the postal code, the address
itself (123 Main St.) is created and approved by the municipality, so it's
their data and they can release that data if they wish to.

So it is perfectly fine to add the street number and name, just not the
postal code from an official source.

On Aug 10, 2016 11:00 AM, "Adam Martin"  wrote:

> Hey Bjenk,
>
> On the Address data, the Talk-CA group has had several discussions about
> it. The problem boils down to Canada Post, which treats the information as
> proprietary - they provide any individual going to their site the right to
> lookup an address in order to utilize their service to mail items. The
> actual database is theirs and even the postal code on my home is theirs,
> I'm just allowed to use it. This all likely has more to do with the fact
> that they have a service that links the addresses to mapped locations that
> is, of course, available only for those willing to pay for it. If they
> allowed OSM to integrate this information, they would lose that revenue
> stream.
>
> Suffice it to say that, apart from an individual adding their address
> manually to the map, Canada Post is not about to allow any party to use
> that information freely.
>
> On Wed, Aug 10, 2016 at 11:41 AM, Ellefsen, Bjenk (STATCAN) <
> bjenk.ellef...@canada.ca> wrote:
>
>> The postal code subject is interesting for many reasons. I read that
>> France has released a National address database, publically and free.
>>
>>
>>
>> There must be a way we can follow that example.
>>
>>
>>
>> I am still catching up, haha!
>>
>>
>>
>> Bjenk
>>
>>
>>
>> *From:* john whelan [mailto:jwhelan0...@gmail.com]
>> *Sent:* August-06-16 7:23 PM
>> *To:* Laura O'Grady 
>> *Cc:* Talk-CA OpenStreetMap ; Ellefsen, Bjenk
>> (STATCAN) ; Stewart C. Russell <
>> scr...@gmail.com>
>> *Subject:* Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada
>>
>>
>>
>> The postcode battle is being fought on the Open Data side.   There is an
>> open data mailing list whose name escapes me where they have been playing
>> for years to get the postcode data including access to information requests.
>>
>> Tracy at Carleton University is well connected on the Open Data side and
>> the postcode saga.  There is some hope now that the UK post office has made
>> the UK ones available.
>>
>> For the moment many commercial companies do list their postcode on their
>> web sites and the the commercial buildings that are the ones of interest to
>> Stats Canada.
>>
>> I suspect Bjenk will have fun when he checks his email on Monday morning
>> when he arrives in the office.  We've been quite chatty over the weekend.
>>
>> Cheerio John
>>
>>
>>
>> On 6 Aug 2016 7:02 pm, "Laura O'Grady"  wrote:
>>
>> There's a form [1] requesting this data set. Not sure if posting a
>> request will help as we know this has been going on for years.
>>
>>
>>
>> You can get the Forward Sortation Areas in a boundary file [2], which can
>> be exported from the db. I noticed the disclaimer, "This data includes
>> information copied with permission from Canada Post Corporation". But of
>> course this is incomplete. I wonder if it's the latter 3 characters,
>> the Local Delivery Unit, which can pinpoint to individual households is
>> being suppressed for privacy reasons.
>>
>>
>>
>> As an academic we battled Stats Can for years for access to data that was
>> paid for by taxpayer dollars. Eventually we won. So there's a precedent of
>> sorts.
>>
>>
>>
>> Has anyone tried filing a freedom of information request for the postal
>> codes?
>>
>>
>>
>> Laura
>>
>>
>>
>> -
>>
>> Laura O'Grady
>>
>> la...@lauraogrady.ca
>>
>>
>>
>>
>>
>> [1] http://open.canada.ca/en/suggested-datasets/postal-code-database
>>
>> [2] https://www12.statcan.gc.ca/census-recensement/2011/geo/
>> bound-limit/bound-limit-2011-eng.cfm
>>
>>
>> On Aug 6, 2016, at 2:12 PM, john whelan  wrote:
>>
>> ​I understand the current intent is data.gc.ca
>>
>> There is actually a lot of postcode data in Ottawa adhresses as it stands
>> especially for commercial buildings.  Don't hold your breath for Canada
>> Post and postcodes.
>>
>> Some attributes they would like at the moment I can't see how a mapper
>> would map them from physically looking at the building.
>>
>> If nothing else it should clean up the map.  For that reason it would be
>> nice to be able to pull chunks into JOSM and go over it looking for obvious
>> errors and spelling mistakes in tags.  Maperitive has the ability to
>> extract the tags and export them in spreadsheet format which is good for
>> this sort of thing but you need a source to feed it.​
>>
>>
>>
>>
>>
>> Cheerio John
>>
>>
>>
>> On 6 August 2016 at 12:38, Stewart C. Russell  wrote:
>>
>> Hi John - some great points here.
>>
>> > My understanding is currently he’s looking getting hold 

Re: [Talk-ca] aerial imagery for missing roads

[Kevin Farrugia]

Morning everyone,

I was looking at information on one of the Province's imagery programs
(SWOOP:
https://dr6j45jk9xcmk.cloudfront.net/documents/3609/lio-swoop2015-eng-final-2014-05-13.pdf)
and I had previously assumed that the imagery was paid for by the province
but the rights still owned by the imagery company, which is the case where
I work.  However, it looks like they might purchase the imagery outright
because it says the imagery is owned by the Queen's Printer, which is the
holder of the Crown's copyrights in Ontario.

If that's the case you can try contacting their open data team to see if
they can persuade the Ministry of Natural Resources to release the data
openly under the Open Government Directive as a WMS/TIFFs or you can lodge
a FIPPA request to have it released (I don't know how this affects you or
us being able to use it in OSM, however).

You can check out what their imagery looks like here to see if it's worth
your time contacting them:
http://www.giscoeapp.lrc.gov.on.ca/matm/Index.html?site=Make_A_Topographic_Map=MATM=en-US
(in Map Layers turn off Topographic Data to see the imagery).

-Kevin (Kevo)


On Sat, Jun 25, 2016 at 7:52 AM, Begin Daniel  wrote:

> Missing access=no and access=private tags I understand...
> Daniel
>
> -Original Message-
> From: Stewart C. Russell [mailto:scr...@gmail.com]
> Sent: June-24-16 22:45
> To: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] aerial imagery for missing roads
>
> On 2016-06-23 10:26 PM, Pierre Béland wrote:
> >
> > Going north outside of urban zones, there are many tracks for lumber
> > areas. Hard to assess the accessibility of such roads for cars.
>
> Most logging roads, certainly in BC, are private. While they look large,
> and make tempting additions to the map, accidentally routing traffic along
> them could be fatal. Logging trucks don't (can't!) stop, and unless you
> have authorization and the right radio to call in the checkpoints, the
> controller won't be able to tell you if there's a truck coming that you
> need to get out of the way of.
>
> CanVec also mistakenly digitized a bunch of private wind farm access roads
> in Ontario, such as https://www.openstreetmap.org/way/39334427 .
> While using these might not be life-threatening, it is trespassing to use
> them.
>
> cheers,
>  Stewart
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Fort McMurray - Canadian volunteer as a point of contact

[Kevin Farrugia]

According to Paul Norman in an earlier email that licence isn't compatible
with OSM's.
On May 10, 2016 1:47 PM, "James"  wrote:

> Planet has released FMM satelite imagery as CC-BY-SA
> https://www.planet.com/pulse/fort-mcmurray-wildfire/
>
> On Tue, May 10, 2016 at 1:40 PM, Heather Leson 
> wrote:
>
>> HI Bernie, someone contacted me off list. I am working to coordinate.
>> Just got off the phone with the CanVost liaison to learn more first.
>>
>> There is satellite imagery but the licenses are not ideal (yet).
>>
>> CanVOST - Canadian Virtual Operations Support Team.
>>
>> Heather
>>
>> Heather Leson
>> heatherle...@gmail.com
>> Twitter/skype: HeatherLeson
>> Blog: textontechs.com
>>
>> On Tue, May 10, 2016 at 8:36 PM, Bernie Connors 
>> wrote:
>>
>>> Is anybody following up on this opportunity to liaise with the emergency 
>>> managers in Fort McMurray? They are looking for an Albertan
>>>
>>>
>>> Morning from Doha.
>>>
>>> As mentioned previously there are emergency managers trying to get 
>>> imagery.
>>> This is their first time considering digital volunteers. If I can have 
>>> one
>>> Canadian volunteer as a point of contact I can hand off the discussion.
>>>
>>> Note: they would really love it if it was someone from alberta. 
>>> However, i
>>> think someone who can work on what is needed is also great.
>>>
>>> Heather - heatherleson at gmail.com
>>>
>>> --
>>> Bernie Connors
>>> New Maryland, NB
>>>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>
>
> --
> 外に遊びに行こう！
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] New project update

[Kevin Farrugia]

1) this would be inherent in the map since we'd be mapping it
2) again, this would be inherent in the map, although I wouldn't put a
measurement value in the attributes as this can be calculated outside of OSM
3) would probably be a hard to get for many buildings, but there are tags
around for this. I know the Long Form/NHS captures housing age, but this is
only done for residential buildings, correct?
4) this can be tagged, such as building=industrial or building=commercial
5) this is a simple tag - building:levels. There is also a height tag,
where the height is logged in metres.
6) hard-ish depending on the location and on the ground surveyors. In
cities that have open data compatible with OSM that post address points it
can be armchair mapped. For other places you'd need to go out and get those
addresses. Postal codes are in OSM but we can't bulk load them from
anywhere because Canada Post guards their copyright very aggressively. If
StatsCan has surveyors out for various surveys, they could easily collect
address information and send it back for input.
On Apr 22, 2016 11:03 AM, "John Whelan"  wrote:

>
>
> Ellefsen, Bjenk (STATCAN) wrote:
>
>> 1. precise location (coordinates, polygon)
>> 2. footprint, size
>> 3. year of construction
>> 4. activities (use)
>> 5. number of floors above ground
>> 6. address (number, street, postal code)
>>
>
> I think the first step might be to identify which tags are either in map
> features or tag info that align with the data you'd like to collect.
>
> Then scan a sample of the data base to see how many are there.  There
> maybe other tags that have the information.  That needs to be untangled.
>
> Remember you're after standard ways of doing things and that traditionally
> OSM has not been heavily standarised.  Which has been one of its strengths.
>
> Most mapping in OSM is done for a purpose, adding cycle paths etc.
>
> Maintaining store names in malls is problematic for us currently.  The
> turnover is too high.
>
> The year of construction is difficult to determine from a visual
> inspection which is how OSM tends to operate.  The days of the year of
> construction of the building being set in stone over the front door seem to
> have vanished.
>
> Post Code is especially difficult, the Post Office clings to the data.
>
> Street names can be interesting, in Ottawa about twenty plus change their
> name each year by the city or are found to have the wrong name on them.  So
> no one has a open definitive set.  City of Ottawa data isn't open enough
> for us.
>
> You may need to resort to Tiles which means something along the lines of
> HOT and finding volunteers to do this.  They will need very clear
> instructions.
>
> Building footprint when done with the building tool in JOSM is usually
> fairly good but we have found new mappers using iD can be problematical in
> HOT mapping.
>
> Cheerio 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

Re: [Talk-ca] New project update

[Kevin Farrugia]

Hi Bjenk,

What type of information are you looking to add about buildings? Some data
belongs in OSM while other attributes might be extraneous. Other people on
this list will also add their opinion on this issue I'm sure. If it's
something being done en masse, it's always best to take an abundance of
caution to not upset people at the errors that might crop up.

If you'd like to break work down into smaller chunks, there are tasking
managers available (including a Canada specific one) that help out with
manual tasks.

-Kevin
On Apr 21, 2016 11:37 AM, "Ellefsen, Bjenk (STATCAN)" <
bjenk.ellef...@canada.ca> wrote:

> Hello everyone,
>
> Basically, what we would like to do is define a project for OSM to collect
> information about non-residential buildings.
> We would like to popose a list of what would be collected. We were
> thinking of identifying specific areas to start with.
>
> Cheers,
>
> Bjenk Ellefsen, PhD
>
> Center for Special Business Projects | Centre des Projets Spéciaux sur les
> entreprises
> Statistics Canada | Statistiques Canada
>
>
>
>
> ___
> 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] Bulk Import of Address Range in GTHA from Metrolinx, Second attemps

[Kevin Farrugia]

Whoa whoa whoa,

I manually imported data from peel open data on my own time. By import I
mean I traced out the ranged and manually typed in the addresses.

Before I get in trouble...
On Feb 12, 2016 7:36 AM, "Stewart C. Russell"  wrote:

> Hi again Mojgan —
>
> > … I noticed that 21 days ago, region of Peel imported the address
> > ranges in the Caledon neighborhood and some parts of Brampton
>
> Just for clarity: Peel imported data into OSM? If so, what is their user
> name, and how long have they been importing without letting anyone know?
>
> Best Wishes,
>  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] Metrolinx: OSM Golden Horseshoe Address Data

[Kevin Farrugia]

Afternoon everyone,
Metrolinx is looking at adding missing address ranges - either those that were 
never added in or those that are in new neighbourhoods.  I believe they're also 
looking for problems where the street name on the highway doesn't match the 
address range street name due to spelling mistakes, different sources, etc. 
-Kevin
Sent from my Samsung Galaxy smartphone. Original message From: 
Adam Martin  Date: 2016-01-12  12:50 PM  (GMT-05:00) 
To: Pierre Choffet  Cc: talk-ca@openstreetmap.org Subject: Re: 
[Talk-ca] Metrolinx: OSM Golden Horseshoe Address Data 
Taking a look around the data in OSM for Toronto, it would appear that the 
address interpolations have been added via import from CanVec already, Pierre. 
Which prompts the question as to what, exactly, did the people from Metrolinx 
mean when they expressed concern about "getting better address ranges than 
individual points". The current data is in address range format. So are these 
inadequate (either that they don't cover the correct spaces, are incomplete or 
missing) or are they looking for addresses to be attached to specific buildings?

Adam 

On Tue, Jan 12, 2016 at 1:55 PM, Pierre Choffet  wrote:

  

  
  
Hello,



I'm not sure this message will help, but just in case: here in
Montreal, we have imported the address layer from CanVec data which
includes the interpolations. Import is never trivial, but given your
needs and the improvement of the service for all users it's probably
a good idea to evaluate this dataset first.



Cheers

Pierre
Le 12/01/2016 08:52, Stewart C. Russell
  a écrit :



  
  Hey,



We had a couple of folks from Metrolinx (the GTHA/Golden
Horseshoe transit agency) at the Toronto Mappy Hour last night.
Their Triplinx route planner — http://www.triplinx.ca/
— consumes OSM data for addresses. They want to find ways to
work with the community to improve addressing in their service
area. They're mostly concerned about getting better address
ranges than individual points.



I don't know what their next steps are, but they seem to be
approaching the community in a different and slightly better way
than most agencies.



cheers,

 Stewart

   

  
  

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




  


___

Talk-ca mailing list

Talk-ca@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk-ca




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

Re: [Talk-ca] Cycling map vs Standard map

[Kevin Farrugia]

Hey Pierre,

It's simply that the cycle tiles are maintained and hosted outside of OSM
so they aren't updated in near real-time like the standard OSM tiles are.

They're taken care of by Andy Allen and you can check out his website at
http://www.thunderforest.com. You could ask him how often the changes are
downloaded and the tiles rerendered.

-Kevin
On Nov 3, 2015 11:07 AM, "Pierre Boucher"  wrote:

> Hi,
> Can someone have and explanation (and a solution) to the fact that for the
> same specific area (small area a few square kilometers) the cycling map is
> not update  to the latest tags.  If you compare the Cycling Map to the 
> Standard
> Map for this area you will see what I mean (I hope so)
>
> http://www.openstreetmap.org/#map=15/45.6271/-73.8443=C
>
> Regards,
>
> * Pierre Boucher (Alias Boff 2  on OSM)*
>
>
> ___
> 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] Looking for competent OSM editors to improve the map on Toronto area and Toronto PATH

[Kevin Farrugia]

Hey everyone,

During the winter/spring I was updating the PATH when I was frequently
taking it to/from home, but I've taken a break since it's nice outside (I
hope that's understandable!).  The PATH is a bit of a beast to update
because it's invisible to imagery and GPS and, in many parts, poorly
signed.  Although the challenge of mapping from memory is part of the fun
for me :)

George  Darren, what are the main things you're looking to have us add?
Is the biggest priority for you the detailed footways, access points, and
the proper connections between the two (elevators, steps, escalators)?  I'm
guessing shops are of secondary importance to the wayfinding/routing
portion of the app?

Thanks,

-Kevin F (Kevo)


On Wed, Aug 12, 2015 at 10:43 AM, James james2...@gmail.com wrote:

 Check out:

 http://www1.toronto.ca/wps/portal/contentonly?vgnextoid=1a66e03bb8d1e310VgnVCM1071d60f89RCRD
 It's their open data portal which also includes the building address
 shapefile(not sure how accurate this is, I know Ottawa's has about 30%
 errors (overlapping duplicate nodes, misplaced nodes))
 Address shape file(can be open in JOSM with opendata plugin):

 http://www1.toronto.ca/wps/portal/contentonly?vgnextoid=91415f9cd70bb210VgnVCM103dd60f89RCRDvgnextchannel=1a66e03bb8d1e310VgnVCM1071d60f89RCRD

 But in the data portal there's all sort of information, paths, etc

 On Wed, Aug 12, 2015 at 9:34 AM, George Silva georger.si...@gmail.com
 wrote:

 Hello everyone,

 I have a few employers who are dedicating part of their funding to
 improve the map on Toronto and Toronto PATH, specially. This is a funded
 effort.

 I've tried to make some edits, but it's too hard for me, being a
 foreigner and not being on Toronto.

 The main thing here is to improve entrances and footways in that area.

 More details, please contact Darren Jones, at
 dar...@crosspathsolutions.com

 Thanks

 --
 George R. C. Silva
 Sigma Geosistemas LTDA
 
 http://www.sigmageosistemas.com.br/

 ___
 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] Highway 400A

[Kevin Farrugia]

There's some conflicting stuff about this when I look into it: the last
traffic volume report (2010) from MTO refers to the section as 400A (
http://www.ontario.ca/data/traffic-volume), but MNR road data labels it as
Highway 11 (the MNR Ontario Road Network dataset is the source for GeoBase
roads in Ontario).

Keeping it as is would keep it correct based on MTO docs, but changing it
based on the signage would improve usability and navigation since there
aren't any 400A signs, only Hwy 11 direction signs (example:
http://www.mapillary.com/map/im/xLVIFS_6hnuS_cQ-owysww).

Anyone else have any thoughts?

-Kevin


On Wed, Jul 15, 2015 at 9:15 PM, Andrew MacKinnon andrew...@gmail.com
wrote:

 The south end of Highway 11 at the Highway 11/400 junction between
 Highway 400 and Penetanguishene Road, just north of Barrie is
 currently tagged as Highway 400A in OSM. Is this still Highway 400A? I
 thought that this became Highway 11 after the Mike Harris downloading
 downloaded the section of Highway 11 south of there (most of which is
 Yonge Street).

 ___
 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] Ref tags in Ontario

[Kevin Farrugia]

(Sorry I have to re-email this Daniel - I thought I pressed reply all :P)

It was discussed in February in this thread:
https://lists.openstreetmap.org/pipermail/talk-ca/2015-February/006404.html

Andrewpmk (almost entirely him) and I reversed all of the ON prefixes to
the 400-Series highways, but provincial highways and regional/county roads
still retain their prefixes.  Personally I don't think there should be any
prefix for rendering or navigation purposes, but I guess it depends on
whether you think county or regional road prefixes should be there for
navigation or rendering purposes.

-Kevin (Kevo)

-Kevin Farrugia
kevinfarru...@gmail.com

On Fri, Jun 26, 2015 at 7:36 AM, Daniel Begin jfd...@hotmail.com wrote:

 AFAIK, it has never been discussed at least on this forum. I consider it
 as an error or even vandalism since it does not conform to acceptable rules
 (1)



 A similar behavior has been seen a couple of months ago where
 user:OntarioEditor added a prefix to ref tag for most primary/secondary
 roads in Quebec. I contacted him but never had an answer. The question was
 asked on this list by another user about such behavior. Unfortunately, I
 did not see any specific answer and his/her edits are still all over the
 place.



 Someone has more information? Comments?



 Daniel





 (1) http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct



 *From:* James Mast [mailto:rickmastfa...@hotmail.com]
 *Sent:* June-25-15 23:56
 *To:* talk-ca@openstreetmap.org
 *Subject:* [Talk-ca] Ref tags in Ontario



 I've been noticing that a user has been adding the prefix of 'ON' to the
 ref tags on ways recently in Ontario.  Are you starting to do that now, or
 is this user in error with the current tagging practices?

 -James

 ___
 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] Mapping Toronto's PATH entrances and ways to them

[Kevin Farrugia]

Hey George,

I'll work towards improving the way the connections are, but because of the
large size of the network, the fact that it's invisible in imagery  GPS is
useless, and I can only remember so much, it might take some time to make
it perfect.  It's a bit of a wild west of connections down there and there
can be many connections to the surface contained within one city block (8+
in some cases) with a mix of stairs, escalators, and elevators with varying
levels of access based around the time of day.

1. Entrances are only mapped sometimes. Currently on OSM it seems that the
underground PATH connects directly with the above ground network rather
than having an elevator or stairway between the level change.  In the
latest updates I've made I've added in escalators, elevators, and stairs
and connected them to the PATH (level=-1) or the ground level network with
an entrance node included on its intersection with the building.  One thing
I've also noticed is that the PATH footways are marked using layer=-1, not
level=-1 - I don't know if this makes a difference to OSRM.

2. I've been linking the entrances with indoor footways that connect to the
PATH via elevators and escalators/stairs and then linking the other side of
the entrance node to the sidewalks or roads so that it should be able to
route between the two networks.

If you have any suggestions or comments please tell us.

Thanks for the heads up,
Kevin (Kevo)


-Kevin Farrugia
kevinfarru...@gmail.com

On Thu, May 28, 2015 at 4:08 PM, George Silva georger.si...@gmail.com
wrote:

 Hello Everyone! Good afternoon!

 I'm working on a project that uses OpenStreetMap to do some routing. I'm
 using the OSRM router as a service.

 We identified a problem with the routing, and the problem does not lie in
 the router itself. Some routes we try to execute in our software, go
 underground, into the PATH tunnels. When I try to route between two points
 inside the PATH, all goes well and the router does it's job just fine.

 When I'm above ground and try a route that goes underground a few things
 can happen:

 1. OSRM gives me the car route and then traces a direct line to the point;
 2. OSRM routes using the PATH;

 The second only happens when the PATH is connected to the street graph.

 So, we will be applying a two step routing, to the entrances of the PATH,
 and from there, to the underground locations, when necessary. When it's
 above ground  above ground, we'll just use a simple routing scheme.

 My questions are:

 1. How are the entrances mapped? Is there any specific tag on OSM that
 marks them as entrances or that the level is changing (from 0 to -1, for
 example)?

 2. All of these entrances should be connected to the main graph, otherwise
 they are unreachable from a street or a sidewalk. How can those be mapped?

 I'm sorry about the lengthy email, but I want to contribute and I do not
 want to step on any toes.

 Thanks

 --
 George R. C. Silva
 Sigma Geosistemas LTDA
 
 http://www.sigmageosistemas.com.br/

 ___
 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: [OSM-legal-talk] Attribution Requirements

[Kevin Farrugia]

On my mobile browser the attribution is between the Questions  Feedback links and the Get Mozilla Updates box near the bottom of the page.It reads "Maps © byMapBoxandOpenStreetMapcontributors"-Kevin  From: Simon PooleSent: Tuesday, January 14, 2014 3:12 PMTo: Martin Koppenhoefer; Licensing and other legal discussions.Reply To: Licensing and other legal discussions.Subject: Re: [OSM-legal-talk] Attribution Requirements
  

  
  

Am 14.01.2014 14:28, schrieb Martin
  Koppenhoefer:


  

  2014/1/14 Simon Poole si...@poole.ch

  I don't actually get a map (tested with three different
  mobile browsers), now I don't think we want to take our
  requirements so far that we want OSM attribution on
  "everything" :-)
  
  
  
  it is one click away:

  


That it likely simply a glitch, the desktop version still has a
large map at the top of the screen, attribution and all.

Simon 
  



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

Re: [Talk-ca] [Imports] The great UUID debate (Was Re: 092G area)

[Kevin Farrugia]

I'd have to disagree.  While there are many areas of Canada that will change
little, if at all, from current data, it would be incredibly short sighted
and lazy to not implement UUIDs at the initial import phase.  Considering
the bulk of the work is done with a script, it only makes sense to include
the extra bit of data.  The road may not move, but if more detailed data
comes out for a street (such as better block numbering, # of lanes for a
road, cover type, last paved, etc.), it would be easier to add this data to
existing data based on UUID.  If there is no UUID, but the road exists, then
we just have the script do what it already does - match the imported segment
to the segment on the map based on its current location.

If I recall correctly from earlier mail in this list (from before the
import), we discussed this and the US Tiger import was brought up because
they didn't include UUIDs and therefore couldn't really update it as well or
at all.  My memory could be wrong about this though.

-Kevin (Kevo)


On Wed, Oct 14, 2009 at 12:16 PM, Michael Barabanov 
michael.baraba...@gmail.com wrote:

 While this can indeed happen in many cases, Canada is so huge that I
 expect large areas to be left as is, and not have this problem.  Even for
 densely populated
 areas like Vancouver, the rate of changes isn't all that high right now.

 Michael.

 On Wed, Oct 14, 2009 at 05:03:27PM +0100, Andy Allan (
 gravityst...@gmail.com) wrote:
  Will it? I keep hearing that but don't really believe it. It would be
  hard enough merging changes if the data was not converted, has a 1:1
  correspondence in geometries and hadn't been editing in the meantime.
  But given that people will split ways, make multipolygons, and a
  certain %age of uuids will either disappear or end up on the wrong
  features (combine, split, combine) then I don't see them as useful
  *enough* to try to preserve them for years on end.
 
  It always seems like a nice idea, but I've yet to see it work in
  practice in OSM. I expect updates to require matching based on
  position and attributes (name etc) as opposed to the exceptionally
  fragile preservation of uuids.
 
  Any counter examples that I'm not aware of?
 
  Cheers,
  Andy
 
  On Wed, Oct 14, 2009 at 1:09 PM, Kate Chapman k...@maploser.com wrote:
   I also think UUID is important in the case of imported data. It will
   ease the update of datasets that we bring in.
  
   Kate Chapman
  
  
   On Oct 14, 2009, at 7:48 AM, Richard Weait rich...@weait.com wrote:
  
   Sam removed that context, then spun this new thread and widened
   distribution!  Here's some context, Sam thinks uuids are uninteresting
   and not useful in imported data.  Michael, below, thinks uuids are
   useful.  Now the rest of the conversation in context.
  
   On Wed, Oct 14, 2009 at 12:06 AM, Michael Barabanov
   michael.baraba...@gmail.com wrote:
   Hi Sam,
  
   I'm not talking about keeping CODE=2270010. That's indeed not
   terribly
   useful. But UUIDs allow us to later
   match the imported features to potentially more complete Canvec
   datasets.
   Example: imagine next Canvec data comes in that also has name= for
   each
   park. If we keep UUIDs in imported data, it's trivial to write a
   script
   to implement a join between the two feature set based on UUID and
   update
   the OSM with park names.
  
   We decided to keep UUID for NRN segments for similar reasons.
  
   On Wed, Oct 14, 2009 at 12:39 AM, Sam Vekemans
   acrosscanadatra...@gmail.com wrote:
   Ok,
   as long as by 'us' you mean 'not me' :-)
   'cause i dont know how to 'trivially' use UUID as a tool like that.
  
   Have you tested that?
  
   I can put a note on the readme.txt file, and on the wiki about it.
  
   Do we have a seconder for this change? (its a BIG change)
  
   A seconder, Sam? Here is a short list of those from talk-ca who
   believe that a uuid is a good idea in a Canadian import:
   You -
 http://lists.openstreetmap.org/pipermail/legal-talk/2009-March/002322.html
   Steve S -
 http://lists.openstreetmap.org/pipermail/talk-ca/2009-February/000705.html
   Michel -
 http://lists.openstreetmap.org/pipermail/talk-ca/2009-January/000612.html
   Austin -
 http://lists.openstreetmap.org/pipermail/talk-ca/2009-June/001223.html
   James -
 http://lists.openstreetmap.org/pipermail/talk-ca/2009-June/001138.html
   me -
 http://lists.openstreetmap.org/pipermail/talk-ca/2009-June/001293.html
  
   ___
   Imports mailing list
   impo...@openstreetmap.org
   http://lists.openstreetmap.org/listinfo/imports
  
   ___
   Imports mailing list
   impo...@openstreetmap.org
   http://lists.openstreetmap.org/listinfo/imports
  
 
  ___
  Imports mailing list
  impo...@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/imports

 ___
 Talk-ca mailing list
 

Re: [Talk-ca] municipal government GIS data

[Kevin Farrugia]

Teranet is a corporation that is the sole provider to the electronic Ontario 
land registry data. I doubt you'll get it free from the Region or from Teranet 
since both make money off of releasing the data. Even the university I go 
(Waterloo) to has very strict rules to not distribute data for either of these 
when we use it.

Still try if you'd like, but it's just my warning on the likelihood, 
Kevin 
--Original Message--
From: James A. Treacy
Sender: talk-ca-boun...@openstreetmap.org
To: William Rieck
Cc: talk-ca
Subject: Re: [Talk-ca] municipal government GIS data
Sent: 7 Oct 2009 3:03 PM

On Wed, Oct 07, 2009 at 01:38:01PM -0400, William Rieck wrote:
 I've noticed Waterloo region has extensive GIS data available on their
 website with respect to land use, property lines, building locations, etc. I
 would guess this would be a common scenario across Canada.
 
 My question, What is the status of the availability of this data for use in
 OSM, or is this still an open question that needs to be followed?

From the license on http://maps.region.waterloo.on.ca/locator/locator.htm

 Licence Restrictions.
 Unless otherwise specified you, the user, may not copy, modify, distribute,
 transmit, display, reproduce, publish, licence, create derivative works from ,
 link to or frame in another web site, use on any other web site, transfer or
 sell the site products in whole or in part either voluntarily or by operation 
 of
 law. The foregoing prohibition expressly includes, but is not limited to, the
 practice of screen scraping, database scraping or any such practice or 
 activity;
 the purpose of which is to obtain data or portions thereof, portions of
 databases from the Locator, in any manner or any quantities not expressly
 authorized.
 
 Parcel (property) information is obtained by the Regional Municipality of
 Waterloo from TERANET Incorporated and is subject to copyright (©) 
 infringement
 laws.

This obviously precludes us from using the data from the web site.

I suspect that the company, TERANET, got the original data from
the region and simply put it into a reasonable form for use on
the internet. I wouldn't be surprised if the region pays them for
accessing their own data (our data really, as our taxes are supporting
this). What we need to do is see if we can get the original data so it
can be added to Openstreetmap.

As an aside:
One thing I notice is that school board property is not displayed
distinctly. I hope there is a source for this as it would be very
useful. 

-- 
James Treacy
tre...@debian.org

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


--
Kevin Farrugia
kevinfarru...@gmail.com
Sent with BlackBerry
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] ACQTECH vs. Valdate vs. OSM User imput for CanVec HD

[Kevin Farrugia]

I think he's aware that we can't use Google Earth, nor did he ever say to.
He was just saying that his GPS tracks met up with the actual path when
overlayed on the Google imagery, meaning that his tracks are probably more
accurate.

About the waterways - I think many of the waterways (smaller ones) were just
traces of aerial imagery onto the topo maps.  Waterways are too much of a
pain to do by GPS on such a large scale so I couldn't see them being too
accurate, unless you get a municipality's watershed layers which I've found
to be very accurate and detailed, but those aren't available to the public
or under the CC so it doesn't matter anyways.  For all we know the federal
data could have been aerial--paper topo--digitized, meaning it could be
very innacurate.  I don't know what the metadata says since I'm at work and
can't (shouldn't) access it, so I don't know if it says in there what the
source is.  I think a user who knows the area should be the one who decides
what should happen to the waterway or at least compare the bot loaded data
with the aerial imagery that's already available to decide which is nearest
to the actual location.

-Kevin (Kevo)

p.s. sorry for sending twice sam, i always forget to press reply all.



 On Thu, Mar 12, 2009 at 1:16 PM, Sam Vekemans 
 acrosscanadatra...@gmail.com wrote:

 Hi,Ya we (the OSM community) dont use Google Earth (because the map isn't
 free, you cant take a printed map of Google Earth/Google Maps and print it
 in Books. .. you can with OpenStreetMap.org

 By submitting your original GPX tracks to OSM, you then help build the
 larger map of the world, the more original GPS tracks that get added to the
 area, the more likely and easier it is to accurately tell what map features
 are more accurate.

 The map that your making (yes, it is useful) however, the OpenCycleMap
 currently available, is also available to download as a garmin map from
 Cloudmade
 http://downloads.cloudmade.com/north_america/canada#breadcrumbs


  the OpenHikingMap is currently in progress which takes the OSM map
 features and tones down the highways so then all the trails stand out more.
  Also, all the things relevant to Hiking will also be shown.

 http://wiki.openstreetmap.org/wiki/Hiking_Map

 Here's that the area of discussion looks like on the cyclemap layer

 http://www.openstreetmap.org/?lat=49.58793lon=-114.5186zoom=17layers=00B0FTF

 But of course, if your not into contributing to OSM directly, im sure
 Simon would be able to help out again, and import the latest version of your
 .mp map when it's ready :)

 Cheers,
 Sam Vekemans
 Across Canada Trails

 On Thu, Mar 12, 2009 at 9:53 AM, Calgary Trail Maps 
 calgarytrailm...@shaw.ca wrote:

  The current OSM data is from my maps, which are based on my tracks,
 other than the ATV bridge which someone else added.  You can see them
 clearly in Google Earth.  I'm working on cleaning this area up for my next
 release and I'll clean it up a bit more.

 John

  --
 *From:* samvekem...@gmail.com [mailto:samvekem...@gmail.com] *On Behalf
 Of *Sam Vekemans
 *Sent:* March 12, 2009 10:35 AM
 *To:* si...@mungewell.org
 *Cc:* Calgary Area Trail Maps; Talk-CA OpenStreetMap; Jean-Sébastien;
 Dale Atkin; Richard Degelder
 *Subject:* Re: ACQTECH vs. Valdate vs. OSM User imput for CanVec HD

  Hi Simon,

 So for the canvec data, it was recorded back in 1979 when the earth was
 flat .. lol :-)
 it also says that the technique is vector data . ... it also says the
 planimeteric accuracy is 19 that would be 'meters' ... so your statement
 of '15 meters' off makes the canvec data also 'right' in it's own sence.
 If your GPS had a better accuracy, then best guess is all you can do.

 And John,
 Thanks, would u be able to upload all your GPX tracks to OSM? If not, i
 can upload that for you, on your request.

 Using JOSM, i just download all the local area GPS Traces, and i only see
 1 track (Simon's)

 And everyone,

 Well, i think when it says GPS as the source, would be from a
 'trimble differencial unit (but not sure) .. and so, when canvec says it's
 a 7 Field completion then we could says it's as accurate as any mapper
 account.

 And so, looking at the contour lines on the Cyclemap, it looks pritty
 good.

 Anyway,
 I fixed the script so it reads as a river thats because it's a
 Watercourse, non isolated for the Watercourse, isolated thats when i
 list it as a stream and for all the other and unknown I list it as a
 stream so then they can be manually upgraded.
 So for some of them that are labeled... like York Creek it's hard to
 say what it is.

 I could change it so that Watercourse, non isolated is listed as a
 stream would that be better?

 Thanks,
 Sam

 P.S.
 I now need to go over the whole set again and fix up the wiki charts.
 Hopefully in the next few days it will be better. ... but of course, im
 always looking for errors.  anyway i published the rules.txt file and added
 the 'date-time stamp' from notepad 

Re: [Talk-ca] GeoBase Import - Another idea

[Kevin Farrugia]

On Wed, Dec 17, 2008 at 6:04 PM, Sam Vekemans
acrosscanadatra...@gmail.comwrote:

 Hi here's another 2 cents in the bucket.
  ... IMO were better off working from the ground up, and getting local
 areas to ask builders/road planners to post the updates, as soon
 as construction is finished rather than wait for information to be
 passed along the government channels.

 So importing all the data as nodes rather than as ways, for all of Canada,
 we can have the updates imported as nodes.. and not WAYS. . this way, it
 keeps it optional if OpenStreetMap users decide to use it, it's available.
 (for address ranges... we can use a line which is the 1st line of 4 for the
 residential area) .. showing up as a dash-dot-dash line.)

 And by importing everything to the areas with very little data (and in
 agreement with local area mappers) a decision would be made on how much data
 should be imported.  (as shape/lines  points of interest).

 and by working on the list (im still working on the CanVec feature list)
 and the GeoBase list we can see the Matches that need to be made.


I thought that we were just going to stick with Geobase data because CanVec
data is split into tiles while Geobase is continuous and everything or most
features will eventually be imported into Geobase anyways -- as per Michael
Mepham's email on December 15.  It sounds much more beneficial to use
geobase over CanVec data from reading that email.



 So by not concerning ourselves with how these lines/areas  should be
 imported, as long as it gets shown up as a series of nodes, with
 its references listed we should be happy with that. (and yes, the basic list
 is needed)

 As.. afterall, once the 1st round of data is imported, we can already begin
 to approach each local area municipal planning department, and as them, if
 they can provide a copy of the latest developments which have been approved,
 as they happen.

 once momentum builds, more and more local area residence (regular people,
 using the map for whatever purpose), will be contributing to the project, as
 they see fit.

 Once a new geobase import comes around, it all gets shown as nodes... and
 so, the local area residences, as essentially draw on the map (connecting
 the dots), just as wood stakes are put in the ground, to show where the new
 roads (land use) will be.

 I hope this makes sence.

 Sam Vekemans
 Across Canada Trails


I don't think approaching planning departments individually would be the
greatest idea because of the vast amount of time and coordination it would
take to set that up and sustain it for the long run.  The update time of 6
months for the GeoBase data, in my opinion, is perfect because a massive
dataset is updated at one time rather than in patches and it all has some
sort of a minimum standard to it since it's coming from one datasource.
There could also be problems with things matching up between two cities,
etc.

I don't really know if the import should turn everything into nodes rather
than lines, seems like much more trouble to me than just having the lines
imported.

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

Re: [Talk-ca] StatsCan Road Network

[Kevin Farrugia]

Would the StatsCan Data be available to us though (to input into OSM based
on our license)?  After reading the license agreement it sounds a bit iffy
because of the acknowledgement required even if it is released under an
unrestricted use license agreement, but I don't know what exactly is allowed
at OSM. Here's an excerpt from the license agreement for the road network:

*3.0 Licence grant*

3.1 Subject to this Agreement, the Licensor hereby grants to the Licensee a
non-exclusive, world-wide, non-assignable, royalty-free right and licence to
exercise such of the Licensor's Licensed Rights and such of the Licensor's
Intellectual Property Rights in the Data as is necessary to use, reproduce,
extract, modify, translate, further develop, distribute the Data,
manufacture or cause to be manufactured and sell or license or cause to be
sold or licensed Derived Products, and to sub-licence any or all of such
rights, PROVIDED:

(i) all reproductions of the Data shall carry the notices and metadata
information set out in section 4 hereof and the provisions contained in
sections 5, to be amended in such circumstances by replacing the term
Licensor as found in the aforementioned provisions with the Licensor's
applied title or any such designation as the Licensor may indicate; and
(ii) all distribution of the Data or licensing by the Licensee of Derived
Products containing the Data, and any sub-licence by the Licensee of its
rights hereunder, shall be evidenced in writing, shall be on the same terms
and conditions as contained herein and shall specifically include the
provisions contained in sections 4, 5 and 6.2 hereof, to be amended in the
circumstances by replacing in such agreements the term Licensor as found
in the aforementioned provisions with the Licensor's applied title or any
such designation as the Licensor may indicate.
3.2 The Intellectual Property Rights arising from any Modifications or from
the manufacture of Derived Products, effected by or for the Licensee, shall
vest in the Licensee or in such person as the Licensee shall decide.
*
4.0 Acknowledgement of source and incorporation of metadata*

4.1 The Licensee shall include the following notice where any of the Data is
contained within Derived Products,

* Source: Geography Division, Statistics Canada, 2008 Road Network File,
92-500-XWE, 92-500-XWF
The incorporation of data sourced from Statistics Canada within this product
shall not be construed as constituting an endorsement by Statistics Canada
of such product *

or any other notice deemed appropriate by the Licensor.

4.2 The Licensee shall reproduce, include and maintain the following notice
on all reproductions of the Licensor's Data produced pursuant to Section 3
above:

Reproduced with the permission of Statistics Canada
 4.3 The Licensee shall incorporate in all reproduction and downstream
distribution of the Data all metadata included by the Licensor in the
provision of the Data.

Too bad there wasn't a common UID across all of the government databases
though, because if there was we would be able to merge the address
attributes into the GeoBase/CanVec road network, and address location and
network routing would be possible in the future.

-Kevin Farrugia
(Kevo)


On Thu, Dec 11, 2008 at 12:43 PM, Brent Fraser bfra...@geoanalytic.comwrote:

 StatsCan has road network data available too:

 http://www.statcan.gc.ca/bsolc/olc-cel/olc-cel?catno=92-500-Xlang=eng

 Not as much geometric detail, and less positional accuracy than CanVec, but
 it does have address ranges.

 E.G. Attributes for a road (4th ave SW)in Calgary:

 RB_UID=135363
 NAME=4
 TYPE=AVE
 DIRECTION=SW
 ADDR_FM_LE=707
 ADDR_TO_LE=707
 ADDR_FM_RG=700
 ADDR_TO_RG=744


 Brent Fraser
 GeoAnalytic Inc.

 ___
 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] Why import all of Geobase/Canvec?

[Kevin Farrugia]

I like that choice of features that should be imported into OSM.  They're
standard for pretty much any road map that people use, besides the hydrology
network, but web maps like Google have rivers  creeks without making it
look messy so we could get away with it.  The water features will especially
be useful in the Canadian Shield where there are thousands and thousands of
lakes, only low res imagery available, and not many people to map the areas
(I'm sure it'll also be an excellent complement for hiking/off road trails
too).

-Kevin Farrugia
(Kevo)


On Thu, Dec 11, 2008 at 11:36 PM, Corey Burger corey.bur...@gmail.comwrote:

 I am very much in favour of importing all of Geobase, but only when
 the db can let users do selective pulls. So for right now, I think we
 should import:

 -the transportation network
 -the hydrology network exluding watershed boundaries
 -political boundaries
 -park/landuse boundaries
 -coastlines
 -water features

 We should not upload
 -elevation data
 -anything else

 For reference, opencyclemap and all the various elevation driven
 mapping stuffs are adding in the elevation data after the pull from
 OSM.

 Corey7

 ___
 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