Re: [Talk-ca] Talk-ca Digest, Vol 140, Issue 11

[keith hartley]

a@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/talk-ca
> >
> >
> > ___
> > Talk-ca mailing list
> > Talk-ca@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
> --
>
> Message: 2
> Date: Thu, 3 Oct 2019 11:54:44 -0400
> From: john whelan 
> To: Justin Tracey 
> Cc: Talk-CA OpenStreetMap , Kevin Farrugia
> 
> Subject: Re: [Talk-ca] Postcodes in Canada
> Message-ID:
> <
> caj-ex1f+ubsdr5oq3ooy1o6umxyej5dwjcf4gov1kqdnra6...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Canadian Postal Codes in urban areas are blocks of roughly 50 buildings
> which makes them extremely interesting to use for GIS studies.  Average
> income etc.
>
> Both in the UK and Canada many people would rather type in a 6 character
> code than a street address with city when looking for directions to a
> location.  In the UK postcodes where restricted to a street which meant
> when computer storage was expensive we used something called a prem code
> which was the building number followed by the postcode and generated the
> full address when required.  Canadian postcodes can spam different streets
> especially in areas served by supermail boxes.
>
> If I use  the example of my own address.  The house was built in the City
> of Cumberland, but my postal address was Navan.  Then Canada Post changed
> the postal address to Orleans which is interesting as Orleans does not
> exist as a municipality.  Apparentyl there are one or two other places in
> Canada that Canada Post doesn't use the municipality name in the postal
> address.  Currently it is in the City of Ottawa so some mail gets addressed
> Orleans and some Ottawa.  I had an elderly aunt who always addressed my
> Christmas card to Navan and included the postcode until she died and each
> year the post office would attach a sticker saying the postal address was
> wrong.  The post code remains the same over all the changes.
>
> So yes a postcode can change but from time to time they are more stable
> than the official postal address.
>
> As long as one address contains the postcode then Nominatim will find it
> which means it can be used for directions.  You might be 30 buildings away
> but you are in the right general area so I think adding them as part of a
> street address is of value.
>
> Cheerio John
>
>
>
> On Thu, 3 Oct 2019 at 11:24, Justin Tracey  wrote:
>
> > In the US, ZIP Codes (the US postal code equivalent) are frequently
> > emphasized to not correspond to geographic locations, but sets of
> > addresses. Of course they frequently cluster according to geography (and
> > the prefixes are indeed assigned to states and regions within the
> > state), and are often used as stand-ins, but you can't make assumptions
> > about continuity or proximity for the addresses they correspond with.
> > Even though I can't find it explicitly worded that way (i.e., "post
> > codes are address sets, not locations"), it seems to be the same
> > situation here. Given that, the most "correct" thing to do would be
> > tagging postal codes in addresses, and not as distinct entities.
> >
> > The Canada Post website has a tool to lookup the postal code for a
> > particular address, so if it were released, wouldn't the data they use
> > to supply that information be good enough for this? It doesn't quite
> > solve people trying to navigate "to" a particular postal code, but it
> > seems like that's an ambiguous request anyway.
> >
> >  - Justin
> >
> >
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20191003/6175e7e4/attachment-0001.html
> >
>
> --
>
> Message: 3
> Date: Thu, 3 Oct 2019 12:53:22 -0400
> From: "Alouette955" 
> To: "Talk-CA OpenStreetMap" 
> Subject: [Talk-ca] Pertinence de lcn=yes pour le Québec
> Message-ID: <23E127B36E5B4153AC238E746E2817E5@ToshibaCL>
> Content-Type: text/plain; charset="utf-8"
>
> Bonjour,
>
> J’extrais et isole ici le sujet “lcn=yes” et vous remarquerez le
> changement d’objet de la conversation.
>
> Le message original couvrant les autres sujets se trouve ici:
> https://lists.openstreetmap.org/pipermail/talk-ca/2019-October/009443.html
>
> Afin de bien mesurer l’ampleur j’ai sorti ces données concernant
> l’utilisation du lcn=yes dans les chemins (ways) et network=lcn dans les
> relations p

Re: [Talk-ca] Carte velo CyclOSM et Référence Route Verte

[Alouette955]

Bonjour,

La modification étant facile à mettre en oeuvre et à renverser le changement de 
RCN à NCN pour la route verte a été effectuée conformément au “tagging 
guideline canadien”. L’apparition de la modification sur la carte cyclable 
pourrait réveiller l’intérêt certains contributeurs et on avisera.

Voir le groupe de modification  https://www.openstreetmap.org/changeset/75251401

La discussion concernant lcn=yes se poursuit dans un autre fil de discussion.

Claude

From: Pierre Béland 
Sent: Tuesday, October 1, 2019 4:09 PM
To: Talk-CA OpenStreetMap 
Cc: Martin Chalifoux ; Alouette955 
Subject: Re: [Talk-ca] Carte velo CyclOSM et Référence Route Verte


Le wiki résume la réflexion à un certain moment donné et il faut être capable 
de le réviser si nécessaire. Tout comme pour le réseau routier, il y a place à 
l'interprétation lorsque nous hiérarchisons un réseau.  Il faut lui donner du 
sens, et puis oui réduire le bruit avec tous les petits segments très locaux. 


1- L’utilisation de lcn=yes


Je suis d'accord qu'il faut limiter l'utilisation des références réseau lcn au 
niveau local. On ne devrait oui ne retenir que ce qui correspond a l'ossature 
principale au niveau local. Mais quels critères retenir. Routes connectées à 
ossature principale ? Avec nom ou no ?.


2- LCN, RCN ou NCN

Le réseau Route Verte parcourt l'ensemble du Québec. Des relations nationales 
telles que la Trans-Canadienne ne fait que fédérer ces réseaux provinciaux et y 
ajouter son label.  Je suis d'accord pour classer la route verte comme niveau 
NCN.  La classification RCN pourrait elle être réservée à des routes plus 
régionales, traversant quelques municipalités par exemple.

3. Abbréviation RV
D'accord pour enlever tiret. Cela est superflu et prend trop de place.

4. TCT

STC En Français TCT en anglais, la meilleure façon d'harmoniser à travers le 
Canada  c'est d'utiliser TC. Cela sera aussi plus court et permettra de mieux 
distinguer route verte lorsque les deux réseaux sont mentionnés.

Je suggère donc d'utiliser TC au Québec. Et nos collègues des autres provinces 
pourront décider à leur tour s'ils souhaitent harmoniser avec TC, plus neutre, 
non relié à une langue particullère.



Pierre 



Le mardi 1 octobre 2019 13 h 22 min 47 s UTC−4, Alouette955 
 a écrit : 


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

Martin soulève 2 problèmes déjà soulignées par le passé qui méritent chacun 
d’être abordé, peut-être dans des “threads” séparés.

1- L’utilisation de lcn=yes

Très peu de relations de type lcn existent au Québec. Ça semble culturel. 
Contrairement à Toronto où les routes sont des entités connues avec une 
signalisation numérotée claire (ça se voit sur la carte cyclable: 
https://osm.org/go/ZX4unwl--?layers=C), au Québec on a des pistes cyclables 
locales qui tout au plus portent le nom de la rue sur laquelle elle sont 
tracées.

Quand j’ai commencé à m’intéresser aux réseaux cyclables j’avoue avoir fait 
preuve de mimétisme ... lcn (Local Cycle Network) était surtout appliqué aux 
chemins et non à des relations. On semblait vouloir indiquer que la piste est 
de responsabilité municipale (locale). J’ai alors pris ça pour la règle.

C’était une erreur et je l’admets. Depuis lors j’utilise lcn=yes pour démontrer 
qu’une piste cyclable assez longue permet de transiter entre les quartiers. Il 
serait préférable de créer des relations plutôt mais nous n’avons pas de 
signalisation municipale sur quoi se baser.

J’aimerais qu’on puisse discuter un correctif. Pourrait-on retirer lcn=yes des 
chemins afin de créer par la suite les routes pertinentes. Gros travail en vue.

2- LCN, RCN ou NCN

Martin souligne que RCN devrait être réservé aux routes provinciales mais la 
“Canada_tagging_guidelines” dit:
  Signed cycling routes are tagged using the Cycle routes#Relations scheme. 
network=lcn is used for routes within an urban agglomeration, network=rcn 
between agglomerations, and network=ncn for routes spanning an entire province 
or more.
Je sais qu’on peut trouver des indications contradictoires sur le wiki. 
Peut-être ne suis-je pas encore tombé sur la règle expliquée par Martin.

J’ai donc considéré rcn les routes qui traversent des agglomérations sur une 
longue distance comme celles indiquées par Martin. Et évidemment lcn celles de 
la responsabilité d’une agglomération comme Montréal, Laval, Québec, etc ...

Doit-on revoir collectivement cette façon de faire?


Claude

 Virus-free. www.avg.com  
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Pertinence de lcn=yes pour le Québec

[Pierre Béland via Talk-ca]

Je trouve sensiblement la même chose- 8 099 chemins
-      90 relations
 Pour ce qui est de la clé lcn=yes sur les chemins, cela me semble aussi 
inutile.  On peut distinguer les réseaux plus importants (niveau local ou 
autre) en créant une relation regroupant divers segments.
Sans doute plusieurs contributeurs ne font que suivre la liste sans intervenir. 
Bonne occasion de commenter même brièvement ou indiquer simplement votre accord 
avec ceci.
Pour les révisions Route Verte peu nombreuses, je pense qu'il est possible de 
procéder dès maintenant.
Pour les révisions lcn sur les chemins, je suggère d'attendre une semaine ou 
deux pour donner le temps à d'autres contributeurs de réagir.
Pierre 

 

Le jeudi 3 octobre 2019 12 h 53 min 48 s UTC−4, Alouette955 
 a écrit :  
 
 Bonjour, J’extrais et isole ici le sujet “lcn=yes” et vous remarquerez le 
changement d’objet de la conversation. Le message original couvrant les autres 
sujets se trouve ici: 
https://lists.openstreetmap.org/pipermail/talk-ca/2019-October/009443.html Afin 
de bien mesurer l’ampleur j’ai sorti ces données concernant l’utilisation du 
lcn=yes dans les chemins (ways) et network=lcn dans les relations pour le 
Québec. Je crois avoir bien circonscrit les données au Québec dans 
overpass-turbo. Si quelqu’un veut vérifier ces chiffres pour corroborer ma 
démarche. J’ai trouvé:   
   -  8106 chemins avec l’attribut lcn=yes présumé non pertinent puisque cet 
attribut serait réservé aux routes dans des relations. Ces attributs dans les 
chemins devraient alors être systématiquement enlevés. Une vérification 
régulière de la situation pourrait ensuite être faite pour éviter qu’il ne 
réapparaisse de la part de contributeurs non informés.   
  
   -  90 relations avec network=lcn. Il resterait à vérifier la pertinence des 
ces 90 relations après avoir défini ce qui est une route lcn pour le Québec 
puis, sur une certaine période, créer les relations qui correspondraient aux 
routes absentes.
 Ceci touche le travail passé de dizaines sinon centaines de contributeurs qui 
ont cartographié les pistes cyclables et déployé l’usage de lcn=yes. Comment 
les joindre pour avoir leur avis et implanter une nouvelle façon de faire?  Et 
comme le disait Pierre quels critères retenir pour définir ce qu’est une route 
lcn surtout avec la diversité des façons de faire dans les municipalités. En 
l’absence d’une structure provinciale pour avoir cette discussion est-ce qu’une 
discussion à 3 est  satisfaisante. Claude P.S. L’avis des autres contributeurs 
aux réseaux cyclables du Québec présents sur cette liste serait apprécié. From: 
Pierre Béland Sent: Tuesday, October 1, 2019 4:09 PMTo: Talk-CA OpenStreetMap 
Cc: Martin Chalifoux ; Alouette955 Subject: Re: [Talk-ca] Carte velo CyclOSM et 
Référence Route Verte  Le wiki résume la réflexion à un certain moment donné et 
il faut être capable de le réviser si nécessaire. Tout comme pour le réseau 
routier, il y a place à l'interprétation lorsque nous hiérarchisons un réseau.  
Il faut lui donner du sens, et puis oui réduire le bruit avec tous les petits 
segments très locaux. 
 1- L’utilisation de lcn=yes
Je suis d'accord qu'il faut limiter l'utilisation des références réseau lcn au 
niveau local. On ne devrait oui ne retenir que ce qui correspond a l'ossature 
principale au niveau local. Mais quels critères retenir. Routes connectées à 
ossature principale ? Avec nom ou no ?.
 ___
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] Pertinence de lcn=yes pour le Québec

[Alouette955]

Bonjour,

J’extrais et isole ici le sujet “lcn=yes” et vous remarquerez le changement 
d’objet de la conversation.

Le message original couvrant les autres sujets se trouve ici: 
https://lists.openstreetmap.org/pipermail/talk-ca/2019-October/009443.html

Afin de bien mesurer l’ampleur j’ai sorti ces données concernant l’utilisation 
du lcn=yes dans les chemins (ways) et network=lcn dans les relations pour le 
Québec.

Je crois avoir bien circonscrit les données au Québec dans overpass-turbo. Si 
quelqu’un veut vérifier ces chiffres pour corroborer ma démarche.

J’ai trouvé:
  a.. 8106 chemins avec l’attribut lcn=yes présumé non pertinent puisque cet 
attribut serait réservé aux routes dans des relations. Ces attributs dans les 
chemins devraient alors être systématiquement enlevés. Une vérification 
régulière de la situation pourrait ensuite être faite pour éviter qu’il ne 
réapparaisse de la part de contributeurs non informés.
   
  b.. 90 relations avec network=lcn. Il resterait à vérifier la pertinence des 
ces 90 relations après avoir défini ce qui est une route lcn pour le Québec 
puis, sur une certaine période, créer les relations qui correspondraient aux 
routes absentes.

Ceci touche le travail passé de dizaines sinon centaines de contributeurs qui 
ont cartographié les pistes cyclables et déployé l’usage de lcn=yes.

Comment les joindre pour avoir leur avis et implanter une nouvelle façon de 
faire? 

Et comme le disait Pierre quels critères retenir pour définir ce qu’est une 
route lcn surtout avec la diversité des façons de faire dans les municipalités.

En l’absence d’une structure provinciale pour avoir cette discussion est-ce 
qu’une discussion à 3 est  satisfaisante.

Claude

P.S. L’avis des autres contributeurs aux réseaux cyclables du Québec présents 
sur cette liste serait apprécié.

From: Pierre Béland 
Sent: Tuesday, October 1, 2019 4:09 PM
To: Talk-CA OpenStreetMap 
Cc: Martin Chalifoux ; Alouette955 
Subject: Re: [Talk-ca] Carte velo CyclOSM et Référence Route Verte


Le wiki résume la réflexion à un certain moment donné et il faut être capable 
de le réviser si nécessaire. Tout comme pour le réseau routier, il y a place à 
l'interprétation lorsque nous hiérarchisons un réseau.  Il faut lui donner du 
sens, et puis oui réduire le bruit avec tous les petits segments très locaux. 


1- L’utilisation de lcn=yes


Je suis d'accord qu'il faut limiter l'utilisation des références réseau lcn au 
niveau local. On ne devrait oui ne retenir que ce qui correspond a l'ossature 
principale au niveau local. Mais quels critères retenir. Routes connectées à 
ossature principale ? Avec nom ou no ?.


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

Re: [Talk-ca] Postcodes in Canada

[john whelan]

Canadian Postal Codes in urban areas are blocks of roughly 50 buildings
which makes them extremely interesting to use for GIS studies.  Average
income etc.

Both in the UK and Canada many people would rather type in a 6 character
code than a street address with city when looking for directions to a
location.  In the UK postcodes where restricted to a street which meant
when computer storage was expensive we used something called a prem code
which was the building number followed by the postcode and generated the
full address when required.  Canadian postcodes can spam different streets
especially in areas served by supermail boxes.

If I use  the example of my own address.  The house was built in the City
of Cumberland, but my postal address was Navan.  Then Canada Post changed
the postal address to Orleans which is interesting as Orleans does not
exist as a municipality.  Apparentyl there are one or two other places in
Canada that Canada Post doesn't use the municipality name in the postal
address.  Currently it is in the City of Ottawa so some mail gets addressed
Orleans and some Ottawa.  I had an elderly aunt who always addressed my
Christmas card to Navan and included the postcode until she died and each
year the post office would attach a sticker saying the postal address was
wrong.  The post code remains the same over all the changes.

So yes a postcode can change but from time to time they are more stable
than the official postal address.

As long as one address contains the postcode then Nominatim will find it
which means it can be used for directions.  You might be 30 buildings away
but you are in the right general area so I think adding them as part of a
street address is of value.

Cheerio John



On Thu, 3 Oct 2019 at 11:24, Justin Tracey  wrote:

> In the US, ZIP Codes (the US postal code equivalent) are frequently
> emphasized to not correspond to geographic locations, but sets of
> addresses. Of course they frequently cluster according to geography (and
> the prefixes are indeed assigned to states and regions within the
> state), and are often used as stand-ins, but you can't make assumptions
> about continuity or proximity for the addresses they correspond with.
> Even though I can't find it explicitly worded that way (i.e., "post
> codes are address sets, not locations"), it seems to be the same
> situation here. Given that, the most "correct" thing to do would be
> tagging postal codes in addresses, and not as distinct entities.
>
> The Canada Post website has a tool to lookup the postal code for a
> particular address, so if it were released, wouldn't the data they use
> to supply that information be good enough for this? It doesn't quite
> solve people trying to navigate "to" a particular postal code, but it
> seems like that's an ambiguous request anyway.
>
>  - Justin
>
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Postcodes in Canada

[Justin Tracey]

In the US, ZIP Codes (the US postal code equivalent) are frequently
emphasized to not correspond to geographic locations, but sets of
addresses. Of course they frequently cluster according to geography (and
the prefixes are indeed assigned to states and regions within the
state), and are often used as stand-ins, but you can't make assumptions
about continuity or proximity for the addresses they correspond with.
Even though I can't find it explicitly worded that way (i.e., "post
codes are address sets, not locations"), it seems to be the same
situation here. Given that, the most "correct" thing to do would be
tagging postal codes in addresses, and not as distinct entities.

The Canada Post website has a tool to lookup the postal code for a
particular address, so if it were released, wouldn't the data they use
to supply that information be good enough for this? It doesn't quite
solve people trying to navigate "to" a particular postal code, but it
seems like that's an ambiguous request anyway.

 - Justin

On 2019-10-02 8:53 p.m., Kevin Farrugia wrote:
> 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,
> 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 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
> mailto:jwhelan0...@gmail.com>> wrote:
> >
> > 

Re: [Talk-ca] Postcodes in Canada

[James]

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

Not necessarily. The first three characters are province, region
indicators. The last three are based on Canada Post's routes/delivery
zones. They create new ones all the time and probably not sequentially so
people need to subscribe to their shitty 5000$/year service

On Thu., Oct. 3, 2019, 12:23 a.m. Kyle Nuttall, 
wrote:

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