Re: [Talk-ca] Postcodes in Canada

[Kyle Nuttall]

I've found a good resource to use is a business website. Particularly a store 
with multiple locations, a mall directory, or a BIA. They have several postal 
codes that are associated with their respective addresses.

Unfortunately it does require manual work (or you could pair a scrapper with a 
geocoder to do the tedious part) but given there is no available datasets we're 
licenced to use currently, it's the only public resource I know of where you 
can get pockets of postal codes.

As more and more get added, the zones will begin to reflect their true shape 
more accurately and it'll be easier to extrapolate.

I know it's not the best answer but any bit helps I suppose.

On Oct. 2, 2019 21:33, John Whelan  wrote:
I had long discussions with Canada Post about postcodes years ago.  I was 
working with Treasury Board standards group at the time looking at addressing 
standards and I'm very aware of the limitations.

Rural post codes are very definitely an issue and not all postcodes used by 
Stats Canada and other government departments for example are physical 
locations.

Open Data would be nice but realistically it isn't going to happen in the short 
term.

Having said that what is doable is spotting postcodes that do exist but are not 
in OpenStreetMap then tagging a building with an address that includes a 
postcode in that postcode.

For example  if K4A 1M7 exists in the map then it would be reasonable to assume 
that K4A 1M6 - 1M1 should also exist so could be looked for.

Cobourg is an example where there are far fewer postcodes than one might like 
to see.

Cheerio John



Kevin Farrugia wrote on 2019-10-02 8:53 PM:
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 
mailto:james2...@gmail.com>> 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, 
mailto:ja...@piorkowski.ca>> 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 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Kyle Nuttall]

The pilot project that took place in Ottawa for all these building imports is 
what got me hooked into OSM in the first place. I would make only very minor 
changes here and there. I even attempted to draw building footprints but got 
burnt out after only doing a single street, which was very discouraging for me 
to continue.

When I saw the entire neighbourhood get flooded with new buildings that weren't 
there before, I was entirely intrigued and actually got on board with the 
locals to help with the process. I've been hooked since and have been to many 
meetups afterwards. Helping out with projects completely unrelated to the 
initial building import.

I'm entirely of the belief that it is much more encouraging for a new user to 
make a minor change (eg. changing `building=yes` to `building=detached`) than 
it is to add every single minor detail to each object from scratch (visiting 
the location, drawing the building footprints manually, adding address data, 
etc.). It's just overwhelming for a new user.

It is very much a cat-and-mouse type scenario with community driven projects 
like OSM. Apparently the issue with this import is the lack of community 
involvement but I can for sure tell you that this import will help flourish the 
community in the local areas. Especially if they only need to add or change 
minor tags than if they would have had to create all of this data by hand. With 
an import this size there is bound to be some errors that slip through. That's 
where the community comes through to correct these minor things.

This is the whole point of OSM. A user creates an object with as much 
information as they know and the next user comes and adds onto that, and the 
next user adds and/or updates even more. Neither of those users on their own 
could have added as much detail as all of their knowledge combined.

Are we supposed to just wait for a user who can add every single building with 
centimetre precision and every bit of detail simply because we can't? No, of 
course not. We do the best we can and have other users who know more than we do 
build on that.

I fully endorse this import because I would love to see what it does for the 
local communities that apparently need to figure this import out for themselves.

Cheers,
Kyle

On Jan. 18, 2019 05:40, James  wrote:
As Frederik Ramm once said(sorry i'm paraphrasing from memory please don't 
shoot me) There has never been a GO-Nogo for imports, you bring it up on the 
mailing lists with reasonable delay, is there no objections(in this case no one 
was saying anything about it for 2-3 weeks) then email the list that the import 
would start.

On Fri., Jan. 18, 2019, 12:59 a.m. Alan Richards 
mailto:alarob...@gmail.com> wrote:
Along the lines of what Jarek said, sometimes silence just means tacit 
acceptance, or that it's not that controversial. There's quite a bit of 
government data here that is supposedly "open" but unavailable for OSM, so I'm 
very glad Stats Can was able to find a way to collect municipal data and 
publish it under one national license. I was surprised myself it hadn't got 
more attention, but I'm firmly onboard with more imports if done with care.
Manually adding buildings - especially residential neighborhoods, is about the 
most boring task I can think of, yet it does add a lot to the map.

I'll admit I hadn't looked at the data quality myself, but I just did review 
several task squares around BC and they look pretty good. Houses were all in 
the right place, accurate, and generally as much or even more detailed than I 
typically see. Issues seemed to be mostly the larger commercial buildings being 
overly large or missing detail, but in general these are the buildings most 
likely to be already mapped. To a large degree, it's up the individual importer 
to do some quality control, review against existing object, satellite, etc. If 
we have specific issues we can and should address them, but if the data is 
largely good then I see no need to abort or revert.

alarobric

On Thu, Jan 17, 2019 at 7:41 PM Jarek Piórkowski 
mailto:ja...@piorkowski.ca>> wrote:
On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea
mailto:stevea...@softworkers.com>> wrote:
> Thanks, Jarek.  Considering I am a proponent of "perfection must not be the 
> enemy of good" (regarding OSM data entry), I think data which are "darn good, 
> though not perfect" DO deserve to enter into OSM.  Sometimes "darn good" 
> might be 85%, 95% "good," as then we'll get it to 99% and then 100% over 
> time.  But if the focus on "how" isn't sharp enough to get it to 85% (or so) 
> during initial entry, go back and start over to get that number up.  85% 
> sounds arbitrary, I know, but think of it as "a solid B" which might be 
> "passes the class for now" without failing.  And it's good we develop a 
> "meanwhile strategy" to take it to 99% and then 100% in the (near- or at most 
> mid-term) future.  This isn't outrageously difficult, though it does take 
> 

Re: [Talk-ca] [Imports] Ottawa, Canada Tree Import

[Kyle Nuttall]

After some data analysis (cheers Denis) we've found about 200 trees that are 
conflicting with buildings. These will obviously need to be handled manually 
which should be an easy task for the local mappers.

The wiki page has been updated accordingly.

Hopefully we've resolved most of the issues as we'd like to get this started by 
Friday.

Happy Canada 150 weekend
Kyle
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Ottawa, Canada Tree Import

[Kyle Nuttall]

A friendly hello to everyone,


With the recent approval of the Ottawa ODL, I've had a keen eye on the City of 
Ottawa tree dataset after seeing a project showing all the fruit-bearing trees 
in the city.

http://data.ottawa.ca/dataset/tree-inventory-street-trees

The dataset provided has all the common names for the species of tree (eg. 
Colorado Spruce). To make it a little more comprehensive, I've added the Latin 
names for the genus and species for most of the trees myself, along with the 
leaf type and cycle.


I've added a few trees to the map as a preview of the data being imported. (The 
remainder will be added using and import account)

http://www.openstreetmap.org/#map=17/45.47443/-75.45005 (North of Innes, East 
of Trim)

http://www.openstreetmap.org/node/4937732175
 (One specific node example)



More details are provided in the wiki.

https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Trees



Would love to hear some feedback and hopefully there are no issues to be found.


Cheers,

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

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

[Kyle Nuttall]

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

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

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

Cheers,
Kyle

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


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

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

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

 Stewart

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

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

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

[Kyle Nuttall]

It seems like with direct permission for the building footprint data the 
licencing issue becomes irrelevant.

However, determining the compatibility of the license is still important so we 
can avoid having these types of discussions for all the other bits of data the 
city provides. But this one in question seems to have the go ahead from the 
City of Ottawa directly.

It's also to my understanding that the spirit of OSM is to contribute data to 
the map, which seems to be precisely what this import is trying to accomplish.

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