Re: [Talk-ca] Removing "WikiProject" prefix

[Begin Daniel]

+1

Sent from Galaxy S7


From: john whelan 
Sent: Saturday, July 20, 2019 2:15:44 PM
To: dcapillae 
Cc: Talk-CA OpenStreetMap 
Subject: Re: [Talk-ca] Removing "WikiProject" prefix

Sounds wonderful, but that is a purely personal comment.

Cheerio John

On Sat, Jul 20, 2019, 2:13 PM dcapillae, 
mailto:dcapil...@gmail.com>> wrote:
Hi,

I am Daniel, from Spain. I would like to change the name of the wiki
pages related to the Canada mapping project to remove the "Wikiproject"
prefix following the pages name conventions [1].

The name of the pages related to the Canada mapping project would be
"Canada" (name of place) instead of "Wikiproject Canada", as recommended
by the wiki conventions. It is a change that I have already made in
United States [2], Spain [3], and all Spanish speaking countries in the
OSM Wiki [4], consulting with their communities beforehand. Hard work
but good results.

I could make the necessary changes, no problem, and also add the
"Country" template [5] to the Canada project page, although this change
is optional.

Some questions from your OSMCanada Slack group:

1.-  What affect does it have on the wiki to be frank?

Really, not much. Instead of "WikiProject Canada" the pages change to
"Canada" (place name) to make direct reference to the country object of
the mapping project, following the wiki conventions. The rest will
remain the same (no changes).

2.- Will there be a redirect to Canada page?

Of course. You can search for "Canada" directly in the wiki. And if
someone shares a link to "WikiProject Canada", it will link directly to
the Canada mapping project ("Canada" page in the wiki).

3.- Is it going to break old links to it?

No, not at all. The redirects will be automatic.


I have posted a message on the wiki about this subject [6]. Please,
comment there if you want to send me your opinions.


Thank you for your attention. Greetings from Spain!

Regards,

Daniel


[1]
https://wiki.openstreetmap.org/wiki/Wiki_organisation#Pages_naming_convention

[2] https://wiki.openstreetmap.org/wiki/United_States

[3] https://wiki.openstreetmap.org/wiki/Spain

[4] https://wiki.openstreetmap.org/wiki/Category:Spanish_speaking_countries

[5] https://wiki.openstreetmap.org/wiki/Template:Country

[6]
https://wiki.openstreetmap.org/wiki/Talk:WikiProject_Canada#Removing_.22WikiProject.22_prefix

___
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] Inauguration pont Samuel de Champlain

[Begin Daniel]

Bravo à tous ceux qui arrivent  à maintenir à jour le réseau routier de 
Montréal (pont Champlain, échangeur Turcot, ...) !

Sent from Galaxy S7


From: Pierre Béland via Talk-ca 
Sent: Saturday, June 22, 2019 6:24:58 PM
To: talk-ca; Alouette955
Subject: Re: [Talk-ca] Inauguration pont Samuel de Champlain

Claude

Étant donné que pont déja fermé direction Montréal, J'ai fait les 
modifications. J'ai validé affichage et nouveau pont bien affiché direction  
Montréal. La navigation routière sera sans doute révisée dans les prochaines 
heures.

Tu peux de ton coté modifier les relation de bus direction Montréal.


Pierre


Le samedi 22 juin 2019 08 h 06 min 49 s UTC−4, Pierre Béland 
 a écrit :


Bonjour Claude

Je suis à préparer les modifications pour le côté allant vers Montréal.  Je 
t'indiquerai lorsque complété.


Pierre


Le vendredi 21 juin 2019 13 h 16 min 28 s UTC−4, Alouette955 
 a écrit :


Bonjour,

L’inauguration du pont Samuel de Champlain sur 2 fins de semaine exigera les 
adaptations nécessaires aux données OSM.

Quelqu’un s’y est-il préparé? (je suppose que oui puisque les chemins “en 
construction” existent déjà).

Pour ma part j’aimerais savoir à quel moment ce sera fait puisque cette 
opération n’inclura probablement pas le déménagement des relations de lignes de 
bus de l’ancien au nouveau pont. Je voudrais m’en occuper en autant qu’on 
m’informe du moment où tout sera “connecté” correctement.

Merci,

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

[Begin Daniel]

Tim, Pierre and all,
I have just published the documentation about orthogonalizing building 
footprints on Github. People can then easily access it as it evolves. I have 
made the code available with the test dataset proposed by Jarek. 

So far, I have documented the different concepts behind the approach I use. The 
next step is to detail the different algorithm used to process the building 
footprints.

Running FME requires a licence. However, since the application could eventually 
be translated in an open-source code, the repository could be used for both FME 
and an open-source code.

The repository will also be used to show results on expected problematic 
footprints people would like to see processed, like the test area proposed by 
Jarek.

Thanks,
Daniel

https://github.com/jfd553/OrthogonalizingBuildingFootprint

-Original Message-
From: Begin Daniel [mailto:jfd...@hotmail.com] 
Sent: Wednesday, May 01, 2019 15:13
To: Tim Elrick; talk-ca@openstreetmap.org; Begin Daniel; Pierre Béland
Subject: RE: [Talk-ca] Importing buildings in Canada

Bonjour Tim,
Je ne sais pas si Pierre souhaite fusionner les approches, mais il démontre un 
intérêt à programmer. Pour ma part, je n’aime pas beaucoup programmer (python, 
scripts SQL, etc.), mais j’aime bien développer des processus (d’où 
l’utilisation de FME). 

Je vais rendre à terme la documentation du processus (de l’algorithme) et des 
exemples sur Github. Par la suite, ceux qui sont intéressés à développer 
l’application en open source seront les bienvenus et je serai heureux de 
répondre aux questions et d’en discuter :-)

Daniel 

-Original Message-
From: Tim Elrick [mailto:o...@elrick.de] 
Sent: Tuesday, April 30, 2019 13:30
To: talk-ca@openstreetmap.org; Begin Daniel; Pierre Béland
Subject: Re: [Talk-ca] Importing buildings in Canada

Bonjour Daniel,

C'est une bonne nouvelle ! Pierre et moi avons déjà commencé à en parler 
dans des messages privés, et Pierre y a déjà beaucoup réfléchi - en 
partie d'un ancien projet, si je comprends bien. Il a également déjà 
publié ses approches précédentes sur github il y a quelques jours.

Voyons comment nous pouvons fusionner tes approches et celles de Pierre 
pour en tirer le meilleur parti pour le processus d'importation. Ce 
serait bien si nous pouvions trouver des méthodes d'orthogonalisation et 
  de simplification pour toutes les données OSM nouvellement importées 
(et peut-être même déjà existantes).

Tim

On 2019-04-30 12:07, Begin Daniel wrote:
Based on previous comments I improved the application and everything
seems right now. I’ll start publishing results/documentation in
following days J

We may then start developing an “open source” version of the application.

Daniel

*From:*john whelan [mailto:jwhelan0...@gmail.com]
*Sent:* Saturday, April 27, 2019 16:41
*To:* Talk-CA OpenStreetMap
*Cc:* Alasia, Alessandro (STATCAN)
*Subject:* [Talk-ca] Importing buildings in Canada

We now have three sources of data with the correct licensing.

I'm proposing that I amend both the import plan and the import mailing
list to include the three alternative sources.

I'm tempted by the idea of splitting the country up into regions of some
sort.

We have a couple of groups currently who I think would like to import
what is available in Alberta and Manitoba.  Are we asking them to hold
off until Pierre and company have come up with a cleansing routine?

Thoughts ladies and gentlemen please.

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

[Begin Daniel]

Bonjour Tim,
Je ne sais pas si Pierre souhaite fusionner les approches, mais il démontre un 
intérêt à programmer. Pour ma part, je n’aime pas beaucoup programmer (python, 
scripts SQL, etc.), mais j’aime bien développer des processus (d’où 
l’utilisation de FME). 

Je vais rendre à terme la documentation du processus (de l’algorithme) et des 
exemples sur Github. Par la suite, ceux qui sont intéressés à développer 
l’application en open source seront les bienvenus et je serai heureux de 
répondre aux questions et d’en discuter :-)

Daniel 

-Original Message-
From: Tim Elrick [mailto:o...@elrick.de] 
Sent: Tuesday, April 30, 2019 13:30
To: talk-ca@openstreetmap.org; Begin Daniel; Pierre Béland
Subject: Re: [Talk-ca] Importing buildings in Canada

Bonjour Daniel,

C'est une bonne nouvelle ! Pierre et moi avons déjà commencé à en parler 
dans des messages privés, et Pierre y a déjà beaucoup réfléchi - en 
partie d'un ancien projet, si je comprends bien. Il a également déjà 
publié ses approches précédentes sur github il y a quelques jours.

Voyons comment nous pouvons fusionner tes approches et celles de Pierre 
pour en tirer le meilleur parti pour le processus d'importation. Ce 
serait bien si nous pouvions trouver des méthodes d'orthogonalisation et 
  de simplification pour toutes les données OSM nouvellement importées 
(et peut-être même déjà existantes).

Tim

On 2019-04-30 12:07, Begin Daniel wrote:
Based on previous comments I improved the application and everything
seems right now. I’ll start publishing results/documentation in
following days J

We may then start developing an “open source” version of the application.

Daniel

*From:*john whelan [mailto:jwhelan0...@gmail.com]
*Sent:* Saturday, April 27, 2019 16:41
*To:* Talk-CA OpenStreetMap
*Cc:* Alasia, Alessandro (STATCAN)
*Subject:* [Talk-ca] Importing buildings in Canada

We now have three sources of data with the correct licensing.

I'm proposing that I amend both the import plan and the import mailing
list to include the three alternative sources.

I'm tempted by the idea of splitting the country up into regions of some
sort.

We have a couple of groups currently who I think would like to import
what is available in Alberta and Manitoba.  Are we asking them to hold
off until Pierre and company have come up with a cleansing routine?

Thoughts ladies and gentlemen please.

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

[Begin Daniel]

Based on previous comments I improved the application and everything seems 
right now. I’ll start publishing results/documentation in following days ☺
We may then start developing an “open source” version of the application.
Daniel

From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: Saturday, April 27, 2019 16:41
To: Talk-CA OpenStreetMap
Cc: Alasia, Alessandro (STATCAN)
Subject: [Talk-ca] Importing buildings in Canada

We now have three sources of data with the correct licensing.

I'm proposing that I amend both the import plan and the import mailing list to 
include the three alternative sources.

I'm tempted by the idea of splitting the country up into regions of some sort.

We have a couple of groups currently who I think would like to import what is 
available in Alberta and Manitoba.  Are we asking them to hold off until Pierre 
and company have come up with a cleansing routine?

Thoughts ladies and gentlemen please.

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

Re: [Talk-ca] Building Import

[Begin Daniel]

Buildings where there is no available municipal data

Sent from Galaxy S7


From: John Whelan 
Sent: Thursday, March 28, 2019 9:32:32 AM
To: Begin Daniel
Cc: Talk-ca; keith hartley
Subject: Re: [Talk-ca] Building Import

Are you talking about the older CANVEC data or the data that Stats has released 
which is really municipal data?

Thanks John

Begin Daniel wrote on 2019-03-28 8:31 AM:
Someone has compared Bing and Canvec data in rural areas?

Sent from Galaxy S7


From: OSM Volunteer stevea 
<mailto:stevea...@softworkers.com>
Sent: Wednesday, March 27, 2019 11:52:02 PM
To: Talk-ca
Cc: keith hartley
Subject: Re: [Talk-ca] Building Import

Ah, good dialog ensues.  Municipality by municipality, in conjunction with BOTH 
the StatsCan and Bing data, the right things are getting noticed, the right 
things are getting human-realized at what the next steps are to do.  It gets 
better.

Yay.  Stitch it together.  One municipality at a time.  One province at a time. 
 Pretty soon, after a few revisions of data and back-and-forths between 
municipalities and province-wide data checking, you've got something.  There, 
you go.

SteveA

> On Mar 27, 2019, at 8:23 PM, keith hartley 
> <mailto:keith.a.hart...@gmail.com> wrote:
>
> The patchwork of municipalities is at least useful, before we didn't have a 
> framework for adding this data, but at least we do now thanks to the umbrella 
> license @ Stats Canada. We're a big country with very few, but very skilled 
> OSM mappers (IE gecho111 mapped all of regina's building footprints! ).
>
> I like the concept of the Bing data, but they may have to do another few 
> tries, or maybe retain their Neural network. - Is there anywhere where the 
> Bing data looks nice? I found burbs in Winnipeg not bad, but there's some 
> really weird elements when the source data is too simple (buildings in the 
> middle of fields) or too complex (urban cores)
>
> On Wed, Mar 27, 2019 at 6:29 AM John Whelan 
> <mailto:jwhelan0...@gmail.com> wrote:
> The Stats Canada data comes from the municipalities.  Unfortunately there are 
> over 3,000 in Canada so yes ideally each would be treated separately in 
> reality each municipality doesn't have a group of skilled OSM mappers who are 
> capable of setting up an import plan and doing the work although there is 
> nothing to stop them doing so.
>
> Cheerio John


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



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


--
Sent from 
Postbox<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[Begin Daniel]

Someone has compared Bing and Canvec data in rural areas?

Sent from Galaxy S7


From: OSM Volunteer stevea 
Sent: Wednesday, March 27, 2019 11:52:02 PM
To: Talk-ca
Cc: keith hartley
Subject: Re: [Talk-ca] Building Import

Ah, good dialog ensues.  Municipality by municipality, in conjunction with BOTH 
the StatsCan and Bing data, the right things are getting noticed, the right 
things are getting human-realized at what the next steps are to do.  It gets 
better.

Yay.  Stitch it together.  One municipality at a time.  One province at a time. 
 Pretty soon, after a few revisions of data and back-and-forths between 
municipalities and province-wide data checking, you've got something.  There, 
you go.

SteveA

> On Mar 27, 2019, at 8:23 PM, keith hartley  wrote:
>
> The patchwork of municipalities is at least useful, before we didn't have a 
> framework for adding this data, but at least we do now thanks to the umbrella 
> license @ Stats Canada. We're a big country with very few, but very skilled 
> OSM mappers (IE gecho111 mapped all of regina's building footprints! ).
>
> I like the concept of the Bing data, but they may have to do another few 
> tries, or maybe retain their Neural network. - Is there anywhere where the 
> Bing data looks nice? I found burbs in Winnipeg not bad, but there's some 
> really weird elements when the source data is too simple (buildings in the 
> middle of fields) or too complex (urban cores)
>
> On Wed, Mar 27, 2019 at 6:29 AM John Whelan  wrote:
> The Stats Canada data comes from the municipalities.  Unfortunately there are 
> over 3,000 in Canada so yes ideally each would be treated separately in 
> reality each municipality doesn't have a group of skilled OSM mappers who are 
> capable of setting up an import plan and doing the work although there is 
> nothing to stop them doing so.
>
> 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] Building Import

[Begin Daniel]

Tim pose une question réaliste...
Qu’est-ce qui se passe si un jour OSM ne m’intéresse plus ?

J’utilise FME parce que le développement se fait de façon 100 fois plus rapide 
pour tester des idées (je n’aime pas la programmation standard - je fais trop 
d’erreurs d’inattention dans les détails ;-)

Alors, une fois que le processus sera mis au point sur FME, ça me fera plaisir 
d’en décomposer chaque étape avec vous et de rendre le tout public. On pourra 
faire ça hors liste :-)

Daniel

-Original Message-
From: Tim Elrick [mailto:o...@elrick.de] 
Sent: Wednesday, March 27, 2019 10:33
To: Pierre Béland; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

Bonjour Pierre, Daniel, John et tous,

Je ne doute pas de l'expertise de Daniel. Il n'y a rien de mal à 
utiliser des outils propriétaires lors de l'utilisation des données OSM. 
Cependant, lors de la création des données OSM, nous devons viser le 
processus le plus transparent possible (comme indiqué sur la question de 
l'importation si souvent sur cette liste). D'après ce que j'ai vu, 
l'outil et la chaîne de processus de Daniel fonctionnent très bien. Et 
je suis heureux qu'il contribue son temps et ses idées sur l'importation 
de bâtiments. Mais si Daniel n'est plus là ? Ou nous voulons importer ou 
même nettoyer des données existantes qui ne l'intéressent pas ? Je me 
souviens juste du sort des beaux outils d'histoire de l'OSM de Peter 
(MazderMind) [1] créés il y a quelques années, mais qu'il ne pouvait 
plus maintenir pour des raisons inconnues de moi. Dans son cas, ce n'est 
pas mal car tout est documenté sur github.

Donc, je pense que ce serait bien si nous pouvions traduire les 
algorithmes que Daniel utilise (avec les documents dans le wiki) en un 
outil open source. Cela ne veut pas dire que Daniel doit arrêter ce 
qu'il fait.

Daniel, ce serait bien si toi et moi (et Pierre?) pouvions faire un 
exposé sur la façon d'y arriver - hors liste car je pense que le grain 
de sable n'est pas d'intérêt pour la liste - bien sûr, nous le 
documenterons plus tard dans le wiki.

Qu'est-ce que vous en pensez ?

Tim

[1] 
https://wiki.openstreetmap.org/wiki/User:MaZderMind/Reading_OSM_History_dumps

On 2019-03-26 23:08, Pierre Béland wrote:
Cette discussion sur gis.stackexchange donne le lien vers OpenCarto sur
Sourceforge et vers un document décrivant la méthode.
https://gis.stackexchange.com/questions/25263/is-there-any-open-source-building-squaring-tool

Avec les fonctions PostGIS, à voir comment ST_ShortestLine ou fonction
similaire permettrait de réviser les coordonnées de chaque point du
polygone.
http://postgis.net/docs/ST_ShortestLine.html

Pierre





Le mardi 26 mars 2019 21 h 49 min 17 s HAE, Pierre Béland via Talk-ca
 a écrit :


Bonjour Tim

Mon outil d'analyse Qualité dont les données sont publiées sur
OpenDataLabRDC est basé sur PostgreSQL-Postgis.   Je suis à nettoyer /
documenter le code et prévoit le publier sur github.  J'ai commencé à
regarder les outils possibles, mais peu de documentation disponible. On
parle par exemple de OpenCarto, mais l'info n'est plus disponible. A
voir si possible à l'aide de Grass.
https://gis.stackexchange.com/questions/15612/is-it-possible-to-simplify-orthogonal-polygons-with-opencarto-java-library


Pierre

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

Re: [Talk-ca] FW: Building Import

[Begin Daniel]

Screenshots? A good idea for having everyone seeing the results over 
complicated polygons (I will try keep objective in my selection ;-)

I am working to get it right on multiple adjacent polygons. I'll make the 
results available after I got them.

Daniel

-Original Message-
From: Jarek Piórkowski [mailto:ja...@piorkowski.ca] 
Sent: Tuesday, March 26, 2019 17:19
To: Begin Daniel; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] FW: Building Import

Hi Daniel,

If you are interested, some more potentially complicated areas around
Golden Horseshoe for testing. Each is roughly one screen on z16. I
don't know some of these as much, you might want to post results as
data files or screenshots for others to also look at to increase
buy-in.

- Spadina Chinatown and Kensington Market in Toronto, small buildings
tight in against each other, many semi-detached or attached, and some
larger ex-industrial buildings: 43.6569,-79.3868,43.6477,-79.4086
- University of Waterloo, with smaller attached residence buildings
that might have somewhat complicated shapes, as well as large
interconnected school buildings: 43.4740,-80.5362,43.4648,-80.5580
- downtown Kitchener, using a variety of grid alignments and some
buildings that might not be square: 43.4562,-80.4782,43.4470,-80.5000
- downtown Hamilton also has streets that aren't at right angles:
43.2619,-79.8572,43.2527,-79.8790
- St. Catharines might also be not square: 43.1640,-79.2322,43.1547,-79.2540
- Unionville, older area of Markham: 43.8717,-79.2993,43.8625,-79.3211

You will notice a trend of downtowns with non-square grids. I'm sure
others will be happy to contribute more examples of areas with
geometries they'd consider tricky. Bigger buildings might be more
likely to not be square if they're built out to max out the available
lot. I imagine only-slightly-non-square grids will be most
challenging...

--Jarek

On Tue, 26 Mar 2019 at 16:49, Begin Daniel  wrote:
>
> As usual, missed the reply all …
>
>
>
> From: jfd...@hotmail.com
> Sent: Tuesday, March 26, 2019 16:26
> To: 'John Whelan'
> Subject: RE: [Talk-ca] Building Import
>
>
>
> It is really kind to consider my background ;-)
>
> You are right regarding the "black box" approach; this is why a large 
> approval from the community is required before I go further.
>
>
>
> Daniel
>
>
>
> From: John Whelan [mailto:jwhelan0...@gmail.com]
> Sent: Tuesday, March 26, 2019 16:04
> To: Begin Daniel
> Cc: Jarek Piórkowski; talk-ca@openstreetmap.org; keith hartley; Alessandro 
> (STATCAN)
> Subject: Re: [Talk-ca] Building Import
>
>
>
> I think my concerns are to do with the "black box" approach.  Knowing your 
> background I trust your work but others might not.
>
> On a technical side I get the impression that cites with buildings that are 
> close to each other are problematical.  I assume that small locations with a 
> population of say under 125,000 this is an insignificant problem?
>
> The other issue is I'd like to either see buy in from Nate or at least some 
> Toronto mappers to get an indication that something will happen at the end of 
> the day as it is a fair chunk of Daniel's time to work out how do the 
> preprocessing.
>
> I think some BC mappers expressed some doubts as well so perhaps they would 
> like to think about if they are happy or would prefer BC to be outside of the 
> import project and express their views.
>
> Out of interest if it does move ahead are we including the Microsoft data for 
> areas where we do not have data from Stats Canada?  If so we will need to 
> amend the project plan.
>
> My personal view is realistically I think having building information even if 
> its a meter or two out is better than not having the building outlines.
>
> What would be nice is if we could have some indication from places such as 
> Manitoba, Alberta, Saskatchewan, Quebec excluding Montreal, Ontario excluding 
> Toronto and the other provinces and territories whether they are happy with 
> importing the buildings either from Stats or Microsoft.
>
> I seem to recall Keith is in Manitoba, so any views other than it wasn't 
> present in the first release from Stats?
>
> Note to Alessandro this is just background stuff.
>
> Thanks
>
> Cheerio John
>
> Begin Daniel wrote on 2019-03-26 3:29 PM:
>
> Jarek,
>
> The area you proposed in quite interesting and will force me to look further 
> at buildings with sharing edges, a concern Pierre also had. I'll be back soon 
> with your area processed.
>
> Daniel
>
>
>
> -Original Message-
>
> From: Begin Daniel [mailto:jfd...@hotmail.com]
>
> Sent: Tuesday, March 26, 2019 14:34
>
> To: Jarek Piórkowski; talk-ca@openstreetmap.org
>
> Subject: Re: [Talk-ca] Buildin

[Talk-ca] FW: Building Import

[Begin Daniel]

As usual, missed the reply all …

From: jfd...@hotmail.com
Sent: Tuesday, March 26, 2019 16:26
To: 'John Whelan'
Subject: RE: [Talk-ca] Building Import

It is really kind to consider my background ;-)
You are right regarding the "black box" approach; this is why a large approval 
from the community is required before I go further.

Daniel

From: John Whelan [mailto:jwhelan0...@gmail.com]
Sent: Tuesday, March 26, 2019 16:04
To: Begin Daniel
Cc: Jarek Piórkowski; talk-ca@openstreetmap.org; keith hartley; Alessandro 
(STATCAN)
Subject: Re: [Talk-ca] Building Import

I think my concerns are to do with the "black box" approach.  Knowing your 
background I trust your work but others might not.

On a technical side I get the impression that cites with buildings that are 
close to each other are problematical.  I assume that small locations with a 
population of say under 125,000 this is an insignificant problem?

The other issue is I'd like to either see buy in from Nate or at least some 
Toronto mappers to get an indication that something will happen at the end of 
the day as it is a fair chunk of Daniel's time to work out how do the 
preprocessing.

I think some BC mappers expressed some doubts as well so perhaps they would 
like to think about if they are happy or would prefer BC to be outside of the 
import project and express their views.

Out of interest if it does move ahead are we including the Microsoft data for 
areas where we do not have data from Stats Canada?  If so we will need to amend 
the project plan.

My personal view is realistically I think having building information even if 
its a meter or two out is better than not having the building outlines.

What would be nice is if we could have some indication from places such as 
Manitoba, Alberta, Saskatchewan, Quebec excluding Montreal, Ontario excluding 
Toronto and the other provinces and territories whether they are happy with 
importing the buildings either from Stats or Microsoft.

I seem to recall Keith is in Manitoba, so any views other than it wasn't 
present in the first release from Stats?

Note to Alessandro this is just background stuff.

Thanks

Cheerio John

Begin Daniel wrote on 2019-03-26 3:29 PM:

Jarek,

The area you proposed in quite interesting and will force me to look further at 
buildings with sharing edges, a concern Pierre also had. I'll be back soon with 
your area processed.

Daniel



-Original Message-

From: Begin Daniel [mailto:jfd...@hotmail.com]

Sent: Tuesday, March 26, 2019 14:34

To: Jarek Piórkowski; 
talk-ca@openstreetmap.org<mailto:talk-ca@openstreetmap.org>

Subject: Re: [Talk-ca] Building Import



Jarek,

Since it is a one-time process, I expect to be able to process the files if the 
community feels comfortable with it. In the meantime, people are welcome to 
send me the bounding box of an area they would like to examine.



Daniel



-Original Message-

From: Jarek Piórkowski [mailto:ja...@piorkowski.ca]

Sent: Tuesday, March 26, 2019 13:46

To: Begin Daniel; talk-ca@openstreetmap.org<mailto:talk-ca@openstreetmap.org>

Subject: Re: [Talk-ca] Building Import



On Tue, 26 Mar 2019 at 13:10, Begin Daniel 
<mailto:jfd...@hotmail.com> wrote:

There is actually no standard “code” available since I use FME 
(www.safe.com<http://www.safe.com>). It is a proprietary ETL application and 
all operations are done using “transformers” 
(https://www.safe.com/transformers/). I can provide you with the workbench I 
developed (a bunch of linked transformers) but you need a license to run it. 
This is why I tried to describe the operations I run on the data in the wiki.



As you did, people may send me coordinates (bounding box) of an area they know 
well. I’ll process the area and send the results back in OSM format. Please, be 
reasonable on the amount of data to process ;-)

Thanks Daniel. Let me know how it looks then!



Coming from an open-source background, the process is unusual to me,

and I have questions about scalability - will you be able to process

and provide updated data files for all of Canada then? - but if others

are comfortable with it then I won't object.



Some general thoughts regarding tooling as raised upthread:



I was initially excited to see building footprints data as they help

two quite distinct purposes:



1. they provide a mostly-automatic source of geometries for the

millions of single-family houses that wouldn't be mapped in the next

decade otherwise



2. they might provide a corrected and fairly accurate source of

geometries in heavily-built-up areas, where GPS signal is not that

reliable and it can be really difficult to get sufficiently accurate

geometries from imagery, whether because it's not sufficiently

high-resolution, two sets of imagery with conflicting offsets (Bing

and Esri are the two best sets in Toronto, and they're off by about

1-2 m on north-south axis from each other - that's not something I

Re: [Talk-ca] Building Import

[Begin Daniel]

Jarek, 
The area you proposed in quite interesting and will force me to look further at 
buildings with sharing edges, a concern Pierre also had. I'll be back soon with 
your area processed.
Daniel

-Original Message-
From: Begin Daniel [mailto:jfd...@hotmail.com] 
Sent: Tuesday, March 26, 2019 14:34
To: Jarek Piórkowski; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

Jarek, 
Since it is a one-time process, I expect to be able to process the files if the 
community feels comfortable with it. In the meantime, people are welcome to 
send me the bounding box of an area they would like to examine.

Daniel

-Original Message-
From: Jarek Piórkowski [mailto:ja...@piorkowski.ca] 
Sent: Tuesday, March 26, 2019 13:46
To: Begin Daniel; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

On Tue, 26 Mar 2019 at 13:10, Begin Daniel  wrote:
> There is actually no standard “code” available since I use FME 
> (www.safe.com). It is a proprietary ETL application and all operations are 
> done using “transformers” (https://www.safe.com/transformers/). I can provide 
> you with the workbench I developed (a bunch of linked transformers) but you 
> need a license to run it. This is why I tried to describe the operations I 
> run on the data in the wiki.
>
> As you did, people may send me coordinates (bounding box) of an area they 
> know well. I’ll process the area and send the results back in OSM format. 
> Please, be reasonable on the amount of data to process ;-)

Thanks Daniel. Let me know how it looks then!

Coming from an open-source background, the process is unusual to me,
and I have questions about scalability - will you be able to process
and provide updated data files for all of Canada then? - but if others
are comfortable with it then I won't object.

Some general thoughts regarding tooling as raised upthread:

I was initially excited to see building footprints data as they help
two quite distinct purposes:

1. they provide a mostly-automatic source of geometries for the
millions of single-family houses that wouldn't be mapped in the next
decade otherwise

2. they might provide a corrected and fairly accurate source of
geometries in heavily-built-up areas, where GPS signal is not that
reliable and it can be really difficult to get sufficiently accurate
geometries from imagery, whether because it's not sufficiently
high-resolution, two sets of imagery with conflicting offsets (Bing
and Esri are the two best sets in Toronto, and they're off by about
1-2 m on north-south axis from each other - that's not something I can
check with a consumer-grade GPS so I'm left guessing as to which is
true), or non-vertical imagery (I can count the floors on supposedly
top-down imagery in some cases).

From what I saw, imports in the GTHA initially focused on the first
case, and I think the Tasking Manager setup was mostly sufficient for
those - where there is nothing currently on the map, or a few simple
2D geometries, a 4 sq km area can feasibly be done in under an hour.

However, as raised by others, I would really want the working squares
in Old Toronto for example to be no more than 500 m x 500 m, or no
more than 1 km x 1 km in St. Catharines. I would _love_ to have the
geometries to manually compare and adjust the 3D buildings already
existing in the area, but it will be much slower.

--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] Building Import

[Begin Daniel]

Jarek, 
Since it is a one-time process, I expect to be able to process the files if the 
community feels comfortable with it. In the meantime, people are welcome to 
send me the bounding box of an area they would like to examine.

Daniel

-Original Message-
From: Jarek Piórkowski [mailto:ja...@piorkowski.ca] 
Sent: Tuesday, March 26, 2019 13:46
To: Begin Daniel; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

On Tue, 26 Mar 2019 at 13:10, Begin Daniel  wrote:
> There is actually no standard “code” available since I use FME 
> (www.safe.com). It is a proprietary ETL application and all operations are 
> done using “transformers” (https://www.safe.com/transformers/). I can provide 
> you with the workbench I developed (a bunch of linked transformers) but you 
> need a license to run it. This is why I tried to describe the operations I 
> run on the data in the wiki.
>
> As you did, people may send me coordinates (bounding box) of an area they 
> know well. I’ll process the area and send the results back in OSM format. 
> Please, be reasonable on the amount of data to process ;-)

Thanks Daniel. Let me know how it looks then!

Coming from an open-source background, the process is unusual to me,
and I have questions about scalability - will you be able to process
and provide updated data files for all of Canada then? - but if others
are comfortable with it then I won't object.

Some general thoughts regarding tooling as raised upthread:

I was initially excited to see building footprints data as they help
two quite distinct purposes:

1. they provide a mostly-automatic source of geometries for the
millions of single-family houses that wouldn't be mapped in the next
decade otherwise

2. they might provide a corrected and fairly accurate source of
geometries in heavily-built-up areas, where GPS signal is not that
reliable and it can be really difficult to get sufficiently accurate
geometries from imagery, whether because it's not sufficiently
high-resolution, two sets of imagery with conflicting offsets (Bing
and Esri are the two best sets in Toronto, and they're off by about
1-2 m on north-south axis from each other - that's not something I can
check with a consumer-grade GPS so I'm left guessing as to which is
true), or non-vertical imagery (I can count the floors on supposedly
top-down imagery in some cases).

From what I saw, imports in the GTHA initially focused on the first
case, and I think the Tasking Manager setup was mostly sufficient for
those - where there is nothing currently on the map, or a few simple
2D geometries, a 4 sq km area can feasibly be done in under an hour.

However, as raised by others, I would really want the working squares
in Old Toronto for example to be no more than 500 m x 500 m, or no
more than 1 km x 1 km in St. Catharines. I would _love_ to have the
geometries to manually compare and adjust the 3D buildings already
existing in the area, but it will be much slower.

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

Re: [Talk-ca] Building Import

[Begin Daniel]

Hi Jarek, 
There is actually no standard “code” available since I use FME (www.safe.com). 
It is a proprietary ETL application and all operations are done using 
“transformers” (https://www.safe.com/transformers/). I can provide you with the 
workbench I developed (a bunch of linked transformers) but you need a license 
to run it. This is why I tried to describe the operations I run on the data in 
the wiki. 

As you did, people may send me coordinates (bounding box) of an area they know 
well. I’ll process the area and send the results back in OSM format. Please, be 
reasonable on the amount of data to process ;-)

Cheers,
Daniel

-Original Message-
From: Jarek Piórkowski [mailto:ja...@piorkowski.ca] 
Sent: Tuesday, March 26, 2019 12:15
To: Begin Daniel; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

On Tue, 26 Mar 2019 at 11:58, Begin Daniel  wrote:
> a first version of the cleaning tool is now functional.
>
> At this point, the tool is built to remove extra vertices, orthogonalize 
> building footprints (when possible) and identify overlapped geometries. 
> Details about the application are found in Canada Building Import discussion 
> page …
>
> https://wiki.openstreetmap.org/wiki/Talk:Canada_Building_Import#Quality_Assurance_details
>
> So far, Tim has looked at the result for Montréal (Import data) and Pierre 
> for Toronto (OSM data). I understand from their comments that the tool 
> generally does its job well. However, both whish to see more functionality 
> added to the application (editing automation).
>
> Before going further, I would like to know if the community is at ease with 
> the Pierre and Tim assessment, and is ready to go further in the import 
> process discussion. I ask that because going further with editing automation 
> will definitely be more complex, without any guarantee about the results.

Hi Daniel,

Thank you for your work on this.

Are you able to share the application or code in any way? I did not
see any links in the talk page. It is really not possible to say much
without looking at what the code does with some of the buildings with
geometries I'm familiar with.

Alternatively shall we send you over an area we're familiar with and
you could send over the results of the tool? But I am concerned that
would scale really poorly.

To give a concrete example, I would be curious about the output of the
tool for area 43.6450,-79.4071,43.6358,-79.4289 - I know that the
geometries already in OSM for the area are partially inaccurate or
overly simplified, so I'm curious how the processed import data looks.

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

Re: [Talk-ca] Building Import

[Begin Daniel]

Hi all,
a first version of the cleaning tool is now functional.
At this point, the tool is built to remove extra vertices, orthogonalize 
building footprints (when possible) and identify overlapped geometries. Details 
about the application are found in Canada Building Import discussion page ...
https://wiki.openstreetmap.org/wiki/Talk:Canada_Building_Import#Quality_Assurance_details
So far, Tim has looked at the result for Montréal (Import data) and Pierre for 
Toronto (OSM data). I understand from their comments that the tool generally 
does its job well. However, both whish to see more functionality added to the 
application (editing automation).
Before going further, I would like to know if the community is at ease with the 
Pierre and Tim assessment, and is ready to go further in the import process 
discussion. I ask that because going further with editing automation will 
definitely be more complex, without any guarantee about the results.
If we agree to go further, I can try to improve the application but at least 
the data could be pre-processed.

Daniel

From: Nate Wessel [mailto:bike...@gmail.com]
Sent: Thursday, March 21, 2019 13:49
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import


Daniel,

This is exciting news! After much talk on this list, it seems we may have some 
actual progress toward fixing the various data quality issues. Would you mind 
sharing some of your code, or a description of your workflow here or on GitHub 
or the like so we can take a look?

One thing you didn't mention which I think will be really critical, especially 
in central Toronto: We need to remove buildings from the import dataset that 
may already be mapped in OSM. That is, buildings that overlap with existing 
buildings. For this import to make any sense in Central Toronto, we need 
conflation to move slowly, and in smaller, more manageable steps. Buildings 
that are already mapped should be checked manually at a later time in batches 
that a skilled human can manage in less than an hour. The tasking manager as 
it's currently set up would have all of downtown conflated by hand in one task 
by a single mapper - a recipe for disaster I'm sure, given how detailed the map 
is in that area.

Cheers,
Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com<http://natewessel.com>
On 3/19/19 12:58 PM, Begin Daniel wrote:
Hi all,
As mentioned a few weeks ago, I have almost completed the development of a 
clean-up tool for the data to be imported.
So far, it removes nonessential vertices, orthogonalizes building corners when 
reasonable and ensures walls' alignment within given tolerances. Building 
footprints that can't be processed completely are flagged accordingly, so they 
could be examined thoroughly at import time.
Eventually, It should be easy to remove overlapping buildings (potentially 
generated from a 3d mapping), but I doubt that splitting terrace into 
individual buildings can be done automatically.
The tool uses some parameters that need to be adjusted. I would like that those 
who are interested in this aspect of the import send me benchmark data that 
could be problematic. I will process them to adjust parameters and/or the tool, 
and I will send back the results to the sender for a thorough examination.
I should soon document the process in the "Canada Building Import" wiki page 
(in a pre-processing section).

Thought? Comments?

Daniel




___

Talk-ca mailing list

Talk-ca@openstreetmap.org<mailto: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] FW: Building Import

[Begin Daniel]

Oups, I still miss the "reply all" button

From: jfd...@hotmail.com
Sent: Thursday, March 21, 2019 14:36
To: 'Nate Wessel'
Subject: RE: [Talk-ca] Building Import

Hi all,
Concerning the pre-processing, let's try/check first the "orthogonalization" 
component then, if there is a consensus on the validity of the result, we can 
build on it :)

Daniel

From: Nate Wessel [mailto:bike...@gmail.com]
Sent: Thursday, March 21, 2019 14:30
To: John Whelan
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import


I've specifically and repeatedly requested that the tasking manager be taken 
down while this project is reworked... though that doesn't pertain directly to 
the email I just sent.
Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com<http://natewessel.com>
On 3/21/19 2:02 PM, John Whelan wrote:
Nate are you requesting something specific on the Canadian task manager for 
Toronto at this time or would you prefer to look through Daniel's work first?

Thanks

Cheerio John

Nate Wessel wrote on 2019-03-21 1:49 PM:

Daniel,

This is exciting news! After much talk on this list, it seems we may have some 
actual progress toward fixing the various data quality issues. Would you mind 
sharing some of your code, or a description of your workflow here or on GitHub 
or the like so we can take a look?

One thing you didn't mention which I think will be really critical, especially 
in central Toronto: We need to remove buildings from the import dataset that 
may already be mapped in OSM. That is, buildings that overlap with existing 
buildings. For this import to make any sense in Central Toronto, we need 
conflation to move slowly, and in smaller, more manageable steps. Buildings 
that are already mapped should be checked manually at a later time in batches 
that a skilled human can manage in less than an hour. The tasking manager as 
it's currently set up would have all of downtown conflated by hand in one task 
by a single mapper - a recipe for disaster I'm sure, given how detailed the map 
is in that area.

Cheers,
Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com<http://natewessel.com>
On 3/19/19 12:58 PM, Begin Daniel wrote:
Hi all,
As mentioned a few weeks ago, I have almost completed the development of a 
clean-up tool for the data to be imported.
So far, it removes nonessential vertices, orthogonalizes building corners when 
reasonable and ensures walls' alignment within given tolerances. Building 
footprints that can't be processed completely are flagged accordingly, so they 
could be examined thoroughly at import time.
Eventually, It should be easy to remove overlapping buildings (potentially 
generated from a 3d mapping), but I doubt that splitting terrace into 
individual buildings can be done automatically.
The tool uses some parameters that need to be adjusted. I would like that those 
who are interested in this aspect of the import send me benchmark data that 
could be problematic. I will process them to adjust parameters and/or the tool, 
and I will send back the results to the sender for a thorough examination.
I should soon document the process in the "Canada Building Import" wiki page 
(in a pre-processing section).

Thought? Comments?

Daniel



___

Talk-ca mailing list

Talk-ca@openstreetmap.org<mailto:Talk-ca@openstreetmap.org>

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

___

Talk-ca mailing list

Talk-ca@openstreetmap.org<mailto:Talk-ca@openstreetmap.org>

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

--
Sent from 
Postbox<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[Begin Daniel]

I expect Pierre, Tim and others to send me any data they believe would be 
problematic. If I send them my own test dataset, it may not cover the cases 
they are interested in. ☺

Daniel

From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: Tuesday, March 19, 2019 13:32
To: Begin Daniel
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

It would make logical sense to preprocess all the data but then you end up with 
two sources.  The Open Data original and the preprocessed data source.

From a logical point of view it would make sense to use the Microsoft data to 
fill in the gaps.  So add it into the preprocessed data.

Then you get to reality.  To make it work across Canada you need to get 
agreement and that I think will be the most difficult part.

Step one I think is ask Pierre nicely to review a sample and see if it meets 
his "quality" expectations.

Step two would be check with Tim in Montreal for his thoughts.

If they are both in agreement that it is acceptable then we see if we can get 
some sort of acceptance across the country possibly blacking out certain areas.

If we can we'll need to go back to the import mailing list and say we wish to 
combine two sources and amend the plan accordingly.

Otherwise it is up to whoever sorts out an import plan / import for a 
particular area to consider its use.

Cheerio John

On Tue, 19 Mar 2019 at 12:59, Begin Daniel 
mailto:jfd...@hotmail.com>> wrote:
Hi all,
As mentioned a few weeks ago, I have almost completed the development of a 
clean-up tool for the data to be imported.
So far, it removes nonessential vertices, orthogonalizes building corners when 
reasonable and ensures walls’ alignment within given tolerances. Building 
footprints that can’t be processed completely are flagged accordingly, so they 
could be examined thoroughly at import time.
Eventually, It should be easy to remove overlapping buildings (potentially 
generated from a 3d mapping), but I doubt that splitting terrace into 
individual buildings can be done automatically.
The tool uses some parameters that need to be adjusted. I would like that those 
who are interested in this aspect of the import send me benchmark data that 
could be problematic. I will process them to adjust parameters and/or the tool, 
and I will send back the results to the sender for a thorough examination.
I should soon document the process in the “Canada Building Import” wiki page 
(in a pre-processing section).

Thought? Comments?

Daniel

___
Talk-ca mailing list
Talk-ca@openstreetmap.org<mailto: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] Microsoft has released its building outlines for Canada

[Begin Daniel]

+1

Sent from Galaxy S7


From: Tim Elrick 
Sent: Tuesday, March 5, 2019 7:09:11 PM
To: James; Begin Daniel
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Microsoft has released its building outlines for Canada

Hi Daniel and James,

Sounds good, Daniel. Looking forward to see your tool. However, the Open
Building Database data for Montreal looks pretty good in terms of number
of nodes and orthogonalization. I am still working on how to break up
the building blocks, however, with much less time on my hand than you
seem to have. I will keep you posted as soon as I had some success.

Thanks, James, for your kind offer. If we decide to import, which we
will discuss on the local list first, we then will provide an import
plan and will get back to for the technical implementation of providing
the tiles on the tasking manager.

I suggest, we continue this conversation on the Montréal list
(challenging my French capabilities).

Tim

On 2019-03-04 19:48, James wrote:
I could serve the output using the microdataservice and the osncanada
task manager(multiple tasks)

https://github.com/osmottawa/micro-data-service

On Mon., Mar. 4, 2019, 7:16 p.m. Begin Daniel, mailto:jfd...@hotmail.com>> wrote:

 Tim, 

 I have plenty of free time and I am interested in this import. I am
 about to complete a pre-processing tool that seems to
 “orthogonalize” building footprints pretty well using FME (safe
 software). I plan to present/discuss its functionalities next week
 on this list (vertex filtering, ensuring right angles, sorting
 building according to processing results, etc.). I have not examined
 how to break up building blocks into single units yet but I am
 interested to include it in the pre-processing tool if it is
 possible.

 __ __

 Daniel

 __ __

 *From:*Tim Elrick [mailto:o...@elrick.de <mailto:o...@elrick.de>]
 *Sent:* Saturday, March 02, 2019 19:58
 *To:* talk-ca@openstreetmap.org <mailto:talk-ca@openstreetmap.org>
 *Subject:* Re: [Talk-ca] Microsoft has released its building
 outlines for Canada

 __ __

 Hi Steve,

 __ __

 As for Montreal: We will create an import plan on the wiki as soon
 as we have expanded the discussion about the Montreal import from
 our local face-to-face group to the Montreal OSM list and agreed on
 importing. Before we do this, we wanted to test the feasibility of
 the pre-processing first, as it involves quite some postgis coding
 to break up the building blocks into single buildings. Only
 thereafter, we will suggest an import (or not), depending on the
 feasibility of extracting single buildings. Otherwise we will follow
 the hand-drawn approach as usual (and as it is done on a daily basis
 at the moment by a couple of OSMappers).

 __ __

 The Microsoft data set might still be useful for remote areas. Let's
 explore this altogether.

 __ __

 Cheers,

 Tim

 __ __


 On 2019-03-02 19:17, OSM Volunteer stevea wrote:

 On Mar 2, 2019, at 3:47 PM, John Whelan
<mailto:jwhelan0...@gmail.com>  wrote:

 Two years ago a group of Toronto mappers submitted the City of
Toronto Open Data license to the LWG to see if it was acceptable.  I
assume they meant to import things such as building outlines.  I also
assumed as I think others did that this meant Toronto mappers were happy
to import the City of Toronto's data especially as it was discussed on
talk-ca first.

 Historical info is appreciated for context, however, the LWG found
Canada-wide city-by-city submissions for ODbL-compliance burdensome,
given LWG's limited bandwidth.  Assuming about events in the past is
unhelpful, first because it is assuming (seldom helpful) and second,
these events are in the past.  How Toronto imported (building) data
can't really help us first understand and second improve from what we
learn until we know what we learned.  That isn't presented here, but it
could be.

 __  __

 More recently Nate who currently lives in Toronto feels that
this should be discussed once more in Toronto to work out what is
desired etc.

 I agree with Nate.  Perhaps first in Toronto, perhaps wider in
talk-ca.  "Once more" seems limiting, though it's possible it could
suffice.

 __  __

 Tim I think is organising Montreal open data import.

 Please consider adding this (and links to user: wiki or Talk pages)
to the active Import wiki.  Generate communication using our media!

 __  __

 I note that Nate and Tim have different ideas about what should
be imported.  One is happy with bay windows and I think the other feels
they should be removed.

 More discussion often yields consensus, especially as it "goes
wide" (or as wide as is practical).

 __  __

   

Re: [Talk-ca] Microsoft has released its building outlines for Canada

[Begin Daniel]

Tim,
I have plenty of free time and I am interested in this import. I am about to 
complete a pre-processing tool that seems to “orthogonalize” building 
footprints pretty well using FME (safe software). I plan to present/discuss its 
functionalities next week on this list (vertex filtering, ensuring right 
angles, sorting building according to processing results, etc.). I have not 
examined how to break up building blocks into single units yet but I am 
interested to include it in the pre-processing tool if it is possible.

Daniel

From: Tim Elrick [mailto:o...@elrick.de]
Sent: Saturday, March 02, 2019 19:58
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Microsoft has released its building outlines for Canada

Hi Steve,

As for Montreal: We will create an import plan on the wiki as soon as we have 
expanded the discussion about the Montreal import from our local face-to-face 
group to the Montreal OSM list and agreed on importing. Before we do this, we 
wanted to test the feasibility of the pre-processing first, as it involves 
quite some postgis coding to break up the building blocks into single 
buildings. Only thereafter, we will suggest an import (or not), depending on 
the feasibility of extracting single buildings. Otherwise we will follow the 
hand-drawn approach as usual (and as it is done on a daily basis at the moment 
by a couple of OSMappers).

The Microsoft data set might still be useful for remote areas. Let's explore 
this altogether.

Cheers,
Tim


On 2019-03-02 19:17, OSM Volunteer stevea wrote:

On Mar 2, 2019, at 3:47 PM, John Whelan 
 wrote:

Two years ago a group of Toronto mappers submitted the City of Toronto Open 
Data license to the LWG to see if it was acceptable.  I assume they meant to 
import things such as building outlines.  I also assumed as I think others did 
that this meant Toronto mappers were happy to import the City of Toronto's data 
especially as it was discussed on talk-ca first.

Historical info is appreciated for context, however, the LWG found Canada-wide 
city-by-city submissions for ODbL-compliance burdensome, given LWG's limited 
bandwidth.  Assuming about events in the past is unhelpful, first because it is 
assuming (seldom helpful) and second, these events are in the past.  How 
Toronto imported (building) data can't really help us first understand and 
second improve from what we learn until we know what we learned.  That isn't 
presented here, but it could be.



More recently Nate who currently lives in Toronto feels that this should be 
discussed once more in Toronto to work out what is desired etc.

I agree with Nate.  Perhaps first in Toronto, perhaps wider in talk-ca.  "Once 
more" seems limiting, though it's possible it could suffice.



Tim I think is organising Montreal open data import.

Please consider adding this (and links to user: wiki or Talk pages) to the 
active Import wiki.  Generate communication using our media!



I note that Nate and Tim have different ideas about what should be imported.  
One is happy with bay windows and I think the other feels they should be 
removed.

More discussion often yields consensus, especially as it "goes wide" (or as 
wide as is practical).



We also have Pierre who is unhappy because the imported building outlines 
available have too many corners that are not right angles.

More discussion often yields consensus.



The local Ottawa mappers are content with their Open Data import and find the 
data quality acceptable even though Pierre has expressed reservations about it.

More discussion often yields consensus.  Wide area (large cities, 
province-wide, nationwide) imports are not easy to achieve consensus but can 
often reach something approaching one as data are entered, not liked, improved, 
liked better, et cetera.  These are often an interactive, iterative process.



Someone in Manitoba? mentioned there were no building outlines released for 
Manitoba?  I apologise if I have the province name wrong.

It is spelled correctly.  I am not Canadian and I know that; it isn't hard to 
spell-check Manitoba.



So we have a mixture of expectations which is only to be expected in a large 
group.

More discussion often yields consensus.  It might be part "mixture of 
expectations" but I'm sure that everyone will agree that "high quality data 
entering OSM" is expected.  What can be difficult is "what do we mean by high 
quality?" (in addition to establishing and communicating clear goals for the 
importation of the data).



Microsoft's Open Data provides another source of Open Data which might meet 
Pierre's data quality expectations.  They may meet Nate's.  All provinces and 
Territories now have Open Data building outlines available.

OK, thanks for the clarification that a "union" of these datasets (Stats 
Canada-produced building data + Microsoft-produced building data) provide an 
"all provinces and Territories dataset."  That truly is helpful as it makes it 

Re: [Talk-ca] Building Import update

[Begin Daniel]

La discussion en cours va dans la bonne direction, il est nécessaire de 
prétraiter correctement les données avant de les mettre à la disposition du 
gestionnaire de tâches OSM. Nous devons (simplement !-) nous entendre sur ce 
qui doit être fait.
La partie qui m’inquiète est la seconde étape du processus d’importation.
Premièrement, la discussion actuelle semble parfois supposer que les données à 
importer sont plus actuelles/meilleures que la couche OSM. Dans une version 
précédente du wiki (processus d’importation), il était même suggéré de 
supprimer les grappes d’anciens bâtiments (building=yes) et de les remplacer 
par les nouvelles données pour accélérer le processus, sans vérifier si les 
données sont valides?
Ce qui m’amène à ma deuxième préoccupation. Je trouve irrespectueux de 
supprimer le travail des contributeurs précédents simplement pour importer plus 
rapidement de nouvelles données. Procéder de cette façon risque de décourager 
tous ceux qui verront leurs contributions ‘imparfaites’ détruites et remplacées 
par cet import. OSM est aussi une communauté.

Daniel

PS. Google translate makes a good translation of this text.

From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: Sunday, February 03, 2019 19:05
To: Pierre Béland
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Building Import update

I'm not hearing we have a clear consensus on modifying the shape of buildings 
with scripts and the Q button.

My own personal view is it could introduce errors and unless it is very 
obviously wrong when it should get picked up by the importing mapper it should 
be left as is.

Cheerio John

On Sun, 3 Feb 2019 at 18:26, john whelan 
mailto:jwhelan0...@gmail.com>> wrote:
I'm hearing we keep the single import project as such.

I'm hearing that we should preprocess the data first splitting out outlines 
that meet Pierre's right angle checks.  This data can just be imported using 
the current processes.

I'm hearing we should then run the correcting scripts and extract the corrected 
buildings.  This becomes the second stage.  This data should be imported 
separately to the first since it needs to be more closely inspected in case the 
script has caused some deformation.

At the moment I'm not sure if the two scripts above exist.

I'm hearing what is left becomes the third stage which needs to be sorted out 
manually before being made available for import.  Again I see this as a 
separate task since the outlines will have been modified from the original.

Note to James is the above practical?  Do we have the resources to do it?  
Please do not do anything until we have an agreement to proceed.

I'm hearing the existing imported building outlines will be subject to an 
overpass to pick out those building outlines that are not square.

Then the "a miracle occurs" box on the project plan gets these into a JOSM todo 
list and mappers manually sort them out.  I'm not certain how this will happen. 
 I suspect if the overpass query is small enough and the buildings are loaded 
up from an off line source this might work.

To come back to Toronto my feeling is this is best left to the local mappers in 
Toronto to decide how to proceed.  There is/was room for a local coordinator in 
the project plan.  Nate's expectations are different to mine and I think it 
makes sense for the local mappers to decide what they would like to do together 
with Nate and a Toronto mapper set themselves up to coordinate in Toronto.  The 
speed at which the buildings were added has been raised as a concern.  I'm 
unable to think of a way to address this other than a "please take it slowly" 
added to the instructions.

Again this option is available to any other areas who would like to use this 
method.

I feel for Quebec the best thing to do is hold back until we have an agreement 
for the rest of the country since there are Quebec mappers who are not 
following this thread on talk-ca and to be honest we do seem to be evolving on 
a hourly basis so waiting until the dust settles might well be sensible.

Am I missing something apart from my sanity?

Thanks John

On Sun, 3 Feb 2019 at 17:07, Pierre Béland 
mailto:pierz...@yahoo.fr>> wrote:
Je suggère oui, d'abord le script avec 2 fichiers d'output parce qu'ensuite il 
sera beaucoup plus simple d'importer les données déja corrigées. Sinon une 
variable pour distinguer les deux et risque de l'importer dans OSM ? Et je 
pense à un autre aspect. Le script pourrait s'assurer qu'il n'y a pas de 
superpositions entre bâtiments une fois les données corrigées.

L'importation des données orthogonales devrait être grandement facilitée. Selon 
l'exemple d'Ottawa, quelque 75% des bâtiments répondent à ce critère une fois 
les polygones qasi-orthogonaux corrigés. Pour ces données, il s'agirait 
davantage de valider avec l'imagerie et de faire la conflation avec les données 
existantes.

Pour l'importation des données irrégulières, il faudrait oui valider / 
corriger. A ne pas oublier que dans ce 

Re: [Talk-ca] Building Import update

[Begin Daniel]

+1

From: Nate Wessel [mailto:bike...@gmail.com]
Sent: Friday, February 01, 2019 08:54
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import update


John,

IMO, this is a red herring and I think you must recognize that to at least some 
degree. Just like no one suggested we do 3700 import plans, no on has suggested 
that we not add buildings to OSM. The question is how, and if that "how" in 
part is an import, then what data, at what speed, by who, etc?

We're not debating between "import" and "nothing" here. There were tens of 
thousands of carefully hand-mapped buildings in Toronto before you and a couple 
others rode in and quietly changed everything in the course of a week.

I'd like to point out to you the interesting case of Kenton County Kentucky:
https://www.openstreetmap.org/relation/361564

Go ahead and zoom in and take a good look at that data. Poke around the rest of 
Northern Kentucky too while you're at it. Notice how good not only the building 
data is, but landuses, named places, etc. The only substantial import this area 
has ever seen is the TIGER road import of about a decade ago. By the time we 
started our Hamilton County building import (just north of the river), there 
were more than 150,000 buildings added by hand in the region already.

I'm not saying this is the way Toronto/Canada needs to develop, but don't imply 
that it's impossible - it isn't.

Cheers,
Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com
On 2/1/19 7:35 AM, john whelan wrote:
https://www.openstreetmap.org/search?query=arthur%20mark%20drive%20port%20hope%20ontario#map=17/43.96262/-78.27069

https://www.google.ca/maps/@43.9631101,-78.2732195,17.25z

https://www.bing.com/maps?FORM=Z9LH3

Port Hope Ontario is relatively obscure yet both Bing and google have buildings 
and neither company would spend the money dropping them in unless they saw a 
demand.

A small sample but I'm sure that others are quite capable of looking locally 
for themselves.


I'm a shades of grey person so to me there is no absolute need to have 
buildings in OpenStreetMap and I think different end users have different 
expectations.  I seem to recall osmand has a street only map which takes up 
less room on the device.  It's perfectly adequate for some users.

I can make a case for both having them and not having any.  On the not having 
any way up there would be the buildings added by inexperienced mappers using iD 
often in HOT projects.  There are duplicates, strange shapes that bare no 
relation to any imagery, and city blocks marked as a single building.  On the 
having them side would be where can I get a coffee and wifi?

There are many users of the map who would like to see buildings or more 
importantly have building information available in an electronic form.

For Ottawa I think I can safely say the local mappers are happy with the 
imported buildings.  In OpenStreetMap there will always be a range of points of 
view.

As you say it is for the local mappers to decide what they would like to do.  
In this case is it difficult to define the local mappers.

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

[Begin Daniel]

It seems that talk-ca works this way - long periods of silence, then a burst of 
emails because something went wrong! I just realized that this massive import 
of buildings started a few weeks ago and I'm surprised.

I was trying to stay informed about the project because I was worried about how 
the import would deal with the thousands of buildings I have modified (or 
deleted) over the years.

I then tend to agree with Steve, Andrew and Nate. Something happened too fast 
or went wrong. There is so much to discuss about how to proceed, how to deal 
with existing buildings, how to deal with buildings that do not seem to exist 
on images, etc. I would have liked to participate in the discussion. All of 
this may have been dealt with the import project of Ottawa, however, as this 
particular project did not interest me, I did not follow the discussions. I was 
expecting the new import project to be documented and discussed by itself, even 
if it eventually ends-up as a copy paste of Ottawa import's procedures.

Communication and clear statements are required to make such large import a 
success and a buy-in of all the community. I think this is why following the 
import guideline is important.

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

Re: [Talk-ca] Stats Canada new building outlines Open Data do we wish to import it?

[Begin Daniel]

I would agree to one import plan with an appropriate validation mechanism. I am 
concerned that the buildings they provide in rural areas come from Canvec. Over 
the years I have deleted/modified thousands of them (Canvec buildings) and I 
would not like to see all of them coming back.

Daniel

From: James [mailto:james2...@gmail.com]
Sent: Friday, November 2, 2018 16:07
To: john whelan
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Stats Canada new building outlines Open Data do we wish 
to import it?

From my initial glance at the data...seems pretty good and accurate(again I 
didn't check all the cities nor do I expect them all to be having same level of 
accuracy)

The two I've been eye balling are Kingston and Rimouski which seem to be very 
accurate at first assessment. If we do want to import them, a formal draft up 
will have to be done though

On Fri., Nov. 2, 2018, 3:53 p.m. john whelan 
mailto:jwhelan0...@gmail.com> wrote:
This is just a formal post to get a feel.

In Ottawa the building outlines were of high quality and I feel have enriched 
the map.

If we do should we consider it one project across the country or leave it to 
the local chapters to make the decision?

I'm thinking that Montreal, Toronto, Vancouver certainly have local groups of 
mappers.  There maybe others.

The other thing to consider is there are remote locations that may not have a 
group of local mappers so taking a country wide stance would not leave these 
locations in limbo.

Taking the decision across the country would mean only one import plan and 
approval and after the Ottawa experience with OpenStreetMap import red tape it 
might be easier than a dozen or so different import plans.

I'm not thinking of the mechanics of the import yet.  That is a different issue.

If you could reply saying you think its a good idea or shouldn't be touched 
with a barge pole also if you could indicate country wide or leave it to the 
local groups to make the decision I would be grateful.

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

[Begin Daniel]

Andrew, Je ne crois pas que le fait que ces ‘contributeurs’ soient Roumains, 
Javanais ou Américains soit à considérer. Ils nous ont consultés avant de faire 
la modification et c’est parfait. Cependant, je suis entièrement en accord avec 
ta réponse - laissez ça à la communauté canadienne!

(I do not believe that the fact these ‘contributors’ are Romanians, Javanese or 
Americans is to be considered. They consulted us before making the change and 
it's perfect. However, I fully agree with your answer - leave that to the 
Canadian community!-)

Sent from Mail for Windows 10


From: Andrew Lester 
Sent: Monday, March 26, 2018 1:35:56 PM
To: Olivia Robu - (p)
Cc: talk-ca
Subject: Re: [Talk-ca] Trans-Canada Highway research

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

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

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

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

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

Andrew
Victoria, BC, Canada


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

Hello,
The Telenav Map team has done some research on the status of the ways and 
relations of Trans-Canada Highway.
Here are some conclusions from this research:

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

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

Re: [Talk-ca] Severed Dick

[Begin Daniel]

Terrible names indeed! 
Google provides pictures of those terrible bike trails but as I am not a BC 
resident, I can't be sure they are actually named that way :-)
Daniel

-Original Message-
From: Frederik Ramm [mailto:frede...@remote.org] 
Sent: Wednesday, 25 October, 2017 11:04
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] Severed Dick

Hi,

   noticed a few funny trail names in this region near Vancouver:

https://www.openstreetmap.org/#map=16/49.3365/-122.9791

Quote possible they really *are* called "Severed Dick", "Shorn Scrotum", and 
"Cunt Buster", in which case they're of course totally legit to have on the 
map, however I've come across some made-up names like that in the past too. 
Maybe someone can check.

Bye
Frederik

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

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

Re: [Talk-ca] Multipolygon problems

[Begin Daniel]

That is helpful!
Thank Jochen

Daniel

-Original Message-
From: Jochen Topf [mailto:joc...@remote.org] 
Sent: Monday, 17 July, 2017 10:27
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Multipolygon problems

On Sat, Jul 01, 2017 at 09:52:48AM +0200, Jochen Topf wrote:
> > How difficult would it be to add this to OSM inspector? Not 
> > everybody has Postgres running, and is able to use osm2pgsql. Yes, 
> > there is documentation, but it requires some technical skills. Also, 
> > it would be very convenient to have this updated daily.
> 
> It is not that difficult to add to the OSM Inspector and if I have the 
> time I'll work on that together with the Geofabrik people.

There is a new layer with this data now in the OSMI:
http://tools.geofabrik.de/osmi/?view=areas=-64.28033=53.72207=8=same_tags_on_outer_ring

You have to zoom in to at least zoom level 8 to see something.

Jochen
--
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

___
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] Multipolygon problems

[Begin Daniel]

Bonjour all

Concerning Canvec data and multipolygon relations,

The problem of multipolygon relations having the feature tag also associated 
with the outer ring may appear over all multipolygon relations (water, wood, 
whatever…) and on all currently available version of the Canvec product (6-10).

However, using the example provided by Stewart, I have not been able to 
reproduce the problem with the latest version of FME so the writer must have 
been corrected since. According to FME’s documentation “the multipolygon 
relation that is written out follows the rules and examples described in 
http://wiki.openstreetmap.org/wiki/Relation:multipolygon.”

Consequently, if a new version of Canvec is ever made available, I expect it 
should respect the OSM schema, at least on this aspect. In any case, one must 
conform to the general imports rules and to what has been said about Canvec 
data on this list.

Cheers,
Daniel
From: Begin Daniel [mailto:jfd...@hotmail.com]
Sent: Monday, 3 July, 2017 16:00
To: Alan Richards; Stewart C. Russell
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Multipolygon problems

Thanks everyone,
Stewart sent me an example I can use ☺
Daniel

From: Begin Daniel [mailto:jfd...@hotmail.com]
Sent: Monday, 3 July, 2017 09:53
To: Alan Richards; Stewart C. Russell
Cc: talk-ca@openstreetmap.org<mailto:talk-ca@openstreetmap.org>
Subject: Re: [Talk-ca] Multipolygon problems

If someone could provide me with an example of a relatively small, untouched 
multipolygon imported directly from Canvec having the problem, I could make 
some tests and sent it to FME to have their translator corrected if I can 
reproduce the problem.

Daniel

From: Alan Richards [mailto:alarob...@gmail.com]
Sent: Monday, 3 July, 2017 00:51
To: Stewart C. Russell
Cc: talk-ca@openstreetmap.org<mailto:talk-ca@openstreetmap.org>
Subject: Re: [Talk-ca] Multipolygon problems

Thanks for a good workflow - I cleared up 8 so far pretty quickly around Hope, 
BC. There's a bunch in a cluster around Merritt too. I'm guessing it's certain 
imports or import authors vs others that makes the difference.

alarobric

On Sun, Jul 2, 2017 at 3:40 PM, Stewart C. Russell 
<scr...@gmail.com<mailto:scr...@gmail.com>> wrote:
On 2017-07-02 04:41 PM, Begin Daniel wrote:
>
> However, since the same translator was used for all the polygons, the
> problem should also appear on water bodies, etc. The problem may have
> been related to the complexity of the polygons to convert.

Hi Daniel - yes, I'm seeing a bunch of water relations with the same
problem, such as on the Grand River
<https://www.openstreetmap.org/relation/576317> and also parts of the
Speed near Guelph. Some of these data were imported from Canvec 10.

> I also found that JOSM had similar problems with tag transfers a few
> years ago (1). Maybe some of the problems found result from merging
> nearby wooded areas?
>
> Daniel
>
> (1) https://josm.openstreetmap.de/ticket/9832.

Interesting, but I'm seeing a lot of the problem water relations
worldwide (well, Scotland and Germany) where JOSM wasn't involved. So
while the JOSM issue might have contributed a little, there were other
factors in play. Indeed, I've even seen changesets (such as 5735148 from
Sep 2010) where the editor had to duplicate the relation tag in the
outer way to get the inner features to render!

cheers,
 Stewart

___
Talk-ca mailing list
Talk-ca@openstreetmap.org<mailto: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] Multipolygon problems

[Begin Daniel]

Thanks everyone,
Stewart sent me an example I can use ☺
Daniel

From: Begin Daniel [mailto:jfd...@hotmail.com]
Sent: Monday, 3 July, 2017 09:53
To: Alan Richards; Stewart C. Russell
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Multipolygon problems

If someone could provide me with an example of a relatively small, untouched 
multipolygon imported directly from Canvec having the problem, I could make 
some tests and sent it to FME to have their translator corrected if I can 
reproduce the problem.

Daniel

From: Alan Richards [mailto:alarob...@gmail.com]
Sent: Monday, 3 July, 2017 00:51
To: Stewart C. Russell
Cc: talk-ca@openstreetmap.org<mailto:talk-ca@openstreetmap.org>
Subject: Re: [Talk-ca] Multipolygon problems

Thanks for a good workflow - I cleared up 8 so far pretty quickly around Hope, 
BC. There's a bunch in a cluster around Merritt too. I'm guessing it's certain 
imports or import authors vs others that makes the difference.

alarobric

On Sun, Jul 2, 2017 at 3:40 PM, Stewart C. Russell 
<scr...@gmail.com<mailto:scr...@gmail.com>> wrote:
On 2017-07-02 04:41 PM, Begin Daniel wrote:
>
> However, since the same translator was used for all the polygons, the
> problem should also appear on water bodies, etc. The problem may have
> been related to the complexity of the polygons to convert.

Hi Daniel - yes, I'm seeing a bunch of water relations with the same
problem, such as on the Grand River
<https://www.openstreetmap.org/relation/576317> and also parts of the
Speed near Guelph. Some of these data were imported from Canvec 10.

> I also found that JOSM had similar problems with tag transfers a few
> years ago (1). Maybe some of the problems found result from merging
> nearby wooded areas?
>
> Daniel
>
> (1) https://josm.openstreetmap.de/ticket/9832.

Interesting, but I'm seeing a lot of the problem water relations
worldwide (well, Scotland and Germany) where JOSM wasn't involved. So
while the JOSM issue might have contributed a little, there were other
factors in play. Indeed, I've even seen changesets (such as 5735148 from
Sep 2010) where the editor had to duplicate the relation tag in the
outer way to get the inner features to render!

cheers,
 Stewart

___
Talk-ca mailing list
Talk-ca@openstreetmap.org<mailto: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] Multipolygon problems

[Begin Daniel]

If someone could provide me with an example of a relatively small, untouched 
multipolygon imported directly from Canvec having the problem, I could make 
some tests and sent it to FME to have their translator corrected if I can 
reproduce the problem.

Daniel

From: Alan Richards [mailto:alarob...@gmail.com]
Sent: Monday, 3 July, 2017 00:51
To: Stewart C. Russell
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Multipolygon problems

Thanks for a good workflow - I cleared up 8 so far pretty quickly around Hope, 
BC. There's a bunch in a cluster around Merritt too. I'm guessing it's certain 
imports or import authors vs others that makes the difference.

alarobric

On Sun, Jul 2, 2017 at 3:40 PM, Stewart C. Russell 
<scr...@gmail.com<mailto:scr...@gmail.com>> wrote:
On 2017-07-02 04:41 PM, Begin Daniel wrote:
>
> However, since the same translator was used for all the polygons, the
> problem should also appear on water bodies, etc. The problem may have
> been related to the complexity of the polygons to convert.

Hi Daniel - yes, I'm seeing a bunch of water relations with the same
problem, such as on the Grand River
<https://www.openstreetmap.org/relation/576317> and also parts of the
Speed near Guelph. Some of these data were imported from Canvec 10.

> I also found that JOSM had similar problems with tag transfers a few
> years ago (1). Maybe some of the problems found result from merging
> nearby wooded areas?
>
> Daniel
>
> (1) https://josm.openstreetmap.de/ticket/9832.

Interesting, but I'm seeing a lot of the problem water relations
worldwide (well, Scotland and Germany) where JOSM wasn't involved. So
while the JOSM issue might have contributed a little, there were other
factors in play. Indeed, I've even seen changesets (such as 5735148 from
Sep 2010) where the editor had to duplicate the relation tag in the
outer way to get the inner features to render!

cheers,
 Stewart

___
Talk-ca mailing list
Talk-ca@openstreetmap.org<mailto: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] Multipolygon problems

[Begin Daniel]

I have checked for the origin of the problem with old documentation about the 
Canvec2osm process. It seems the proprietary translator (FME) used to convert 
the data to OSM may have generated the problem. 

However, since the same translator was used for all the polygons, the problem 
should also appear on water bodies, etc. The problem may have been related to 
the complexity of the polygons to convert. 

I also found that JOSM had similar problems with tag transfers a few years ago 
(1). Maybe some of the problems found result from merging nearby wooded areas?

Daniel

(1) https://josm.openstreetmap.de/ticket/9832. 

-Original Message-
From: Stewart C. Russell [mailto:scr...@gmail.com] 
Sent: Saturday, 1 July, 2017 17:43
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Multipolygon problems

Hi James,

> Canvec 10.0 doesnt have the issues of double tagging, just overlapping

I've found a whole bunch of Canvec 10 data with this problem west of Sudbury. I 
think it may still be an issue with later versions.

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

[Begin Daniel]

Bjenk, I was on the same impression that CSD did (used to) not always match 
municipal limits because of their objective (census) since in some case it 
would not make sense to do so for statistical purpose…

Daniel

From: Bjenk Ellefsen [mailto:bjenk.ellef...@gmail.com]
Sent: Tuesday, 7 March, 2017 09:20
To: James
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Municipal boundaries

Just to make sure we are talking about the same thing: Census Divisions are 
higher level and more regional boundaries. CSDs are municipal boundaries (in 
OSM, level 8).  
http://www.statcan.gc.ca/eng/subjects/standard/sgc/2011/sgc-intro
Can you give me an example of city limits that don't match a CSD or is not in 
the SGC? Usually, the standard for municipal boundaries are the CSDs. At least, 
as far as I know, this is the standard geography. When referring to actual city 
limits, which geographical classification is it referring to?
Sorry for the questions, I am trying to understand what is the classification 
used if its not the CSDs.

On Tue, Mar 7, 2017 at 9:11 AM, James 
> wrote:
Bernie, I've also noticed that StatsCan boundaries seem to be a generalization 
of an area vs the actual city limits

On Tue, Mar 7, 2017 at 9:02 AM, Bernie Connors 
> wrote:
Bjenk,

  In NB there are issues with some census boundaries not matching with our 
administrative boundaries. The issue I am aware of was with the county 
boundaries. The census data that is analogous to our county boundaries included 
some significant deviations to prevent a municipality from being bisected by a 
county boundary. Please be careful that there is not a similar issue with the 
CSD boundaries. NB municipal boundaries can be downloaded from the GeoNB Data 
Catalogue For comparison to the CSD data.

Bernie.

Sent from my BlackBerry 10 smartphone on the Bell network.
From: Bjenk Ellefsen
Sent: Tuesday, March 7, 2017 9:51 AM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Municipal boundaries


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] Community Conduct

[Begin Daniel]

Thank John

From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: Thursday, 22 December, 2016 19:00
To: James
Cc: Paul Norman; Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Community Conduct

> no one maps Gatineau(seriously, maybe cause it's the French side?)
Tact my son tact, look the word up in the dictionary or you'll have Pierre 
descending on Ottawa demanding double Lattes.
Cheerio John

On 22 December 2016 at 18:40, James 
> wrote:
Paul, I am aware of conflicts may occur, but seeing as no one maps 
Gatineau(seriously, maybe cause it's the French side?) I'm not that scared to 
go on a mapping session all day long. In Toronto or Ottawa is a different 
story, in which I would commit more often.

On Thu, Dec 22, 2016 at 6:35 PM, Paul Norman 
> wrote:
On 12/22/2016 3:21 PM, James wrote:

As pnorman has said in the past( 
https://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007260.html):

 Uploaded in small enough parts that the changesets make sense. This means 
never uploading more than 50k objects at once, and typically fewer than 10k.


I try to keep my changes under 10k, but with buildings, nodes multiply quickly 
as there are minimum 4 per building(rare usually average 6-10 depending on 
complexity)

The numbers quoted are in the context of an import where the concerns are the 
ability to revert, working with the changeset in other tools, not leaving stray 
nodes in the database, not splitting one upload over multiple changesets, and 
not having a broken upload. I wouldn't recommend exceeding them for any work, 
but a non-import is out of the scope of the CanVec post linked.

Personally, I'd get worried about conflicts, lost work, and want to upload well 
before 1k changes, let alone 10k. Those often aren't a problem with an import, 
or if they are they can be easier to solve, but with normal mapping solving 
them often requires more thought.

___
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] [Imports] [Import] Ottawa Buildings & Addresses [Statistics Canada project]

[Begin Daniel]

Well, only very large buildings can be found as polygons in the Canvec product.
Furthermore, NRCan did not update the Canvec buildings layer for more than 20 
years (the oldest is 1944), with only a few exceptions…

Daniel

From: James [mailto:james2...@gmail.com]
Sent: Saturday, 22 October, 2016 10:54
To: Stewart C. Russell
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] [Imports] [Import] Ottawa Buildings & Addresses 
[Statistics Canada project]

http://ftp.geogratis.gc.ca/pub/nrcan_rncan/vector/canvec/shp/ManMade/
50K man made just seems to be nodes of where buildings are located, instead of 
outlines.
Judging by :
http://atlas.gc.ca/toporama/en/index.html
They have a few buildings in CanVEC, but not all of them. Seems like massive 
buildings like schools and malls, residential buildings are out.

On Sat, Oct 22, 2016 at 10:00 AM, Stewart C. Russell 
> wrote:
On 2016-10-21 11:41 PM, James wrote:
> Sounds like it, but the data handed to us didnt have sidewalks and
> roads, driveways etc. Ottawa may have exported data from this file

Yes, for sure.

I've now had more of a chance to look at the data (thanks, Ottawa, for
providing no docs at all ...). I'm pretty sure that the data at
http://data.ottawa.ca/dataset/cad-topographic-data is the source of what
the Ottawa group were given.

In the 31 gigabytes of converted files, about 8-10 of the 177 total
layers might be of interest. But:

* The files are in some kind of MTM projection, but I don't know the
datum. Some munis still love their NAD27, so getting this right is crucial.

* These were digitized 2010-2011 at the latest. Since municipalities
share data with NRCan, aren't these outlines already available in a
recent iteration of CanVec in a much more useful (i.e., anything but
DWG) format?

My notes on the files, so far:
https://gist.github.com/scruss/e7f85da2e7943cb1a1d13772fbe144d3#file-ottawabfomapdata-md

(feel free to use/modify/etc)

If anyone wants 31 GB of converted DXFs, let me know. It took Teigha
several hours on a quad core with SSDs to convert this, so I'm not going
to delete it lightly.

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

Re: [Talk-ca] Telenav mapping turn restrictions

[Begin Daniel]

Go with the recommended scheme as described on the wiki.
Daniel

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

Hi all,

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

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

Best,
Martijn

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

Re: [Talk-ca] ODbL vs CC-BY

[Begin Daniel]

Merci Charles, you make my day!
Daniel

-Original Message-
From: Charles Basenga Kiyanda [mailto:perso...@charleskiyanda.com] 
Sent: Thursday, 6 October, 2016 15:02
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] ODbL vs CC-BY

I would rather look here:


http://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility


CC-by-4.0 is still under review, but all other CC-by-x.x licences have a 
problem with attribution:

"is ODbL compatible if rights holder(s) explicitly states in writing that 
credit on the Contributors <http://wiki.openstreetmap.org/wiki/Contributors> 
page is sufficient to fulfil attribution requirements including downstream use 
in works derived from OSM "

Montreal was also releasing under a CC-by-x and the problem was fixed by 
getting confirmation from the city that "the mode of attribution of 
openstreetmap by linking to the import sources contribution page is enough to 
satisfy their requirement for attribution under CC-by." We then kept that email 
very preciously and posted it everywhere we could find to make sure it doesn't 
get lost/forgotten.

If CC-by-4.0 has a specific clause regarding technical protection measures 
(TPM, think encryption, hashing to prevent further people from modifying the 
database) extra from previous versions of CC-by, you'd need to get a waiver 
from the source contributor on that point as well.
This being said, the Odbl summary states:

"/Keep open:/ If you redistribute the database, or an adapted version of it, 
then you may use technological measures that restrict the work (such as DRM) as 
long as you also redistribute a version without such measures."

[From http://opendatacommons.org/licenses/odbl/summary/]

Technically, it clashes with the following in CC-by-4.0:

"No downstream restrictions. You may not offer or impose any additional or 
different terms or conditions on, or apply any Effective Technological Measures 
to, the Licensed Material if doing so restricts exercise of the Licensed Rights 
by any recipient of the Licensed Material."

If one wants to be particularly pedantic (which I guess you should be with 
licenses), then yes those two paragraphs conflict. CC-by-4.0 says "you can't 
encrypt the data" and Odbl says "You can encrypt the data if you make an 
unencrypted version available". The fact that you have to (under Odbl) make an 
unencrypted/unencumbered version available somewhere kind of makes the point 
moot, but you always have the possibility someone would make the unencumbered 
version available somewhere at "the end of the internet" only and kind of be 
conspicuous about where it actually is located.


To be absolutely shielded, I would ask the city to confirm:

"A) The attribution on the import page satisfies our attribution requirement; 
and B) the requirement, under Odbl, to make a version of the data with no 
technological protection measures satisfies our restriction on TPM."


Then post that email everywhere and keep a paper copy safe somewhere.


Cheers,


Charles (I am an engineer and definitely not a lawyer.)






On 10/05/2016 10:08 AM, Begin Daniel wrote:
>
> I was looking at open data that are available in my neighbourhood and 
> I found interesting contents under CC-BY 4.0 license.
>
>  
>
> According to the above web site, the CC-BY 4.0 is not compatible with 
> the OSM license (ODbL) because the CC-BY 4.0 license “prohibits 
> technical protection measures while ODC-ODbL does not contain any such 
> stipulation”
>
> http://clipol.org/licences/70?tab=licence_compatibility
>
>  
>
> Does someone on this list can explain what it means and how it applies 
> to OSM?
>
>  
>
> Thank
>
> Daniel
>
>  
>
>  
>
> Protection measures are, for instance, digital rights management 
> software that restricts the ability of those who receive a CC-licensed 
> work to exercise rights granted under the license.
>
>  
>
>
>
> ___
> 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] ODbL vs CC-BY

[Begin Daniel]

I was looking at open data that are available in my neighbourhood and I found 
interesting contents under CC-BY 4.0 license.

According to the above web site, the CC-BY 4.0 is not compatible with the OSM 
license (ODbL) because the CC-BY 4.0 license "prohibits technical protection 
measures while ODC-ODbL does not contain any such stipulation"
http://clipol.org/licences/70?tab=licence_compatibility

Does someone on this list can explain what it means and how it applies to OSM?

Thank
Daniel


Protection measures are, for instance, digital rights management software that 
restricts the ability of those who receive a CC-licensed work to exercise 
rights granted under the license.

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

Re: [Talk-ca] Erreurs créées par des non-locaux

[Begin Daniel]

Simply said,
Looks like the original ways were linked to other ones by someone from Telenav 
(according to reasonable image interpretation) but they should not according to 
actual feature on the ground. The user is asking the changeset to be reverted, 
especially since the Bing imagery identified as source does not allow that 
interpretation.

Daniel

PS: Above is an understandable Google Translate of user’s main concerns 
extracted from his emails …

438953406 path (north of Lake Blanche)
There are chalets if you come from the west (Chemin du Ruisseau) and houses
if you come from the west (Chemin Bastin). In between, there is nothing.
(I was there yesterday and I affirm)

438953407 path (south of Lake White)
There are chalets if you come from the west (Lake Road to the White) and
houses if you come from the west (Oneida Way). In between, there is nothing.
(I was there yesterday and I affirm)

TeleNav has included the following comment in its group
changes "added ways [Bing]"
To my knowledge, there is no Bing imagery in this area.

This change is also part of 4168708 group that deserves to be overthrown


From: Mihai Iepure [mailto:mihai.iep...@telenav.com]
Sent: Tuesday, 20 September, 2016 03:46
To: talk-ca
Subject: Re: [Talk-ca] Erreurs créées par des non-locaux

Hi everyone,

My name is Mihai, I’m a map analyst at Telenav.
As far as my French goes, in the last emails there have been some discussions 
regarding some of our edits in Canada, especially with changeset #41680708, 
ways 438953406 and 438953407. I can confirm that we’ve been doing edits using 
our ImproveOSM tool, using the source=improve_osm_tn k/v pair.

I have a request, can someone write a short summary in English of the last 
emails in order to have a better understanding of the issue and how we can 
address this?

Thanks,
Mihai

From: Pierre Béland [mailto:pierz...@yahoo.fr]
Sent: Tuesday, September 20, 2016 12:00 AM
To: dega >; talk-ca 
>
Subject: Re: [Talk-ca] Erreurs créées par des non-locaux

Dega,

Bon je poursuis lecture a rebours de tes courriels. Oui il y a une façon simple 
d'avoir une image d'une zone à un instant précis. Voici une requête Overpass. 
Il faut zoomer sur la zone a analyser et modifier la date. Puis on clique pour 
exécuter.

[date:"2016-05-06T00:00:00Z"];
(
  node({{bbox}});
  way({{bbox}});
  relation({{bbox}});
);
out meta;
>;
out meta;


La requête suivante permet elle  d'analyser l'historique de OSM et de voir les 
chemins ajoutés depuis aout 2016 contenant la clé source=improve_osm_tn. On 
peut en repérer plusieurs autour de Mont-Tremblant.

[out:xml]
[timeout:90]
[adiff:"2016-08-01T00:00:00Z","2016-09-19T00:00:00Z"];
way["source"="improve_osm_tn"];
 /*nodes des chemins*/
 (._;>;);
 /*output*/
 out meta;

Pierre


De : dega >
À : talk-ca >
Envoyé le : lundi 19 Septembre 2016 14h33
Objet : Re: [Talk-ca] Erreurs créées par des non-locaux


Je viens de découvrir qu'un problème identique s'est produit sur le Chemin de
la Presqu'Ile (au nord du Lac Cornu, chemin 438953404). Le chemin a été
prolongé jusqu'au Chemin Chaloux, ce qui ne correspond pas à la réalité.
J'aimerais bien connaître la méthodologie de biancah_telenav.

Ce changement fait aussi partie du groupe 4168708 qui mérite d'être renversé.

Est-ce qu quelqu'un connaît une façon de visualiser la carte à une date
donnée?
Est-ce qu'il existe une archive des tuiles OSM?

dega

Le 19 septembre 2016, 14:12:57 dega a écrit :
> Une personne dont le surnom  est biancah_telenav a récemment effectué des
> modifications qui réduisent la qualité de notre carte. Il s'agit des deux
> ensembles de modifications suivants:
> - groupe 41680708 sur le chemin 438953406 (au nord du lac de La Blanche)
> - groupe 41680708 sur le chemin 438953407 (au sud du Lac de la Blanche)
> Cette personne est "novice" (inscrite depuis moins de 2 mois) mais a fait
> plus de 700 modifications.  J'oserais dire qu'elle est de la région de
> Detroit. Il est temps que quelqu'un lui dise que la qualité est plus
> importante que la quantité.
> Je suis allé vérifier "de visu" et j'affirme que les 2 prolongements de
> chemins qui ont été faits par biancah_telenav n'existent pas.
> Je considère que ces 2 erreurs sont graves car, un jour, quelqu'un utilisera
> la carte OSM pour longer le Lac de la Blanche et ce quelqu'un se retrouvera
> dans un  précipice.
> Je demande à ceux qui savent faire à ce que ce groupe de modifications soit
> renversé.
> Bonne semaine à tous!
>
> dega


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

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

Re: [Talk-ca] Canvec attributes (roads)

[Begin Daniel]

Martjin, 
You can get current information about how old/accurate the data are using the 
above link.

http://geogratis.gc.ca/api/en/nrcan-rncan/ess-sst/-/(urn:iso:series)geobase-national-road-network-nrn?sort-field=relevance

To get the answer you need to look at the metadata: 
You select the area you are interested in (click)
You need to view the full metadata (formatted NAP) (click)
Look for the above tags under "dataQualityInfo" 
"DQ_AbsoluteExternalPositionalAccuracy"
You will find 1:N Distance values that describe how accurate the data are. 
"EX_TemporalExtent"
You will find 1:N timePosition values that describe how old the data are.

The same should apply for the other layers (NHN, NRWN...), even if the 
distribution units may differ (whole country, watershed ...)

Daniel

-----Original Message-
From: Begin Daniel [mailto:jfd...@hotmail.com] 
Sent: Tuesday, 13 September, 2016 07:53
To: Martijn van Exel; Stewart C. Russell; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec attributes (roads)

Bonjour Martijn
AFAIK, here is a summary about how old and accurate is Canvec/GeoBase. 

Transport Layers? 
The roads are updated every 1-2 years for most of the provinces, 5-10 for 
others. 
Railways were updated 4-5 years ago over all the Canadian landmass.

Other layers
Water features are 5-40+ years old depending on the 
province/territory/latitude; Forest areas are 5-40+ years old depending on the 
province/territory/latitude [1]. 
The rest is 25-40+ years old.

About the accuracy, the road network is about 10m (90%). The rest is usually 
better than 30m (90%) but you may find offsets between layers.

Daniel

[1] About forest areas, the latest GeoBase data results from images 
classification made about 5 years ago that gave the clumsy result Paul Ramsay 
recently shown on this list. The latest Canvec OSM tiles (2012?) had a mixture 
of old map data/new GeoBase data.

-Original Message-
From: Martijn van Exel [mailto:m...@rtijn.org]
Sent: Monday, 12 September, 2016 23:06
To: Stewart C. Russell; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec attributes (roads)

On 09/12/2016 06:50 PM, Stewart C. Russell wrote:
> On 2016-09-12 04:08 PM, Martijn van Exel wrote:
>> Aren't these files grouped by feature type? So if we look at roads we 
>> wouldn't also necessarily need to look at land use boundaries etc.?
>
> Canvec - the product supplied by NRCan to the general public - always 
> was split by feature type. It's the OSM tiles, of structure decided 
> long ago, that lump everything together.
>
> It's also available as effectively seamless FGDBs if you want to avoid 
> the cleanup required after using tiled data. The FGDBs retain the 
> critically important survey dates and accuracies - so you can easily 
> see how much data's 40 years old and has ±75 m positional accuracy.
>

Good to know.
Are any of the transport related datasets that old or that inaccurate?

I created an initial Canvec road network translation file for ogr2osm, so you 
can convert the Canvec shapefiles to OSM format easily (if you know how to work 
ogr2osm - let me know if you need help, but Paul Norman is the expert here!)

It is located at
https://github.com/mvexel/canvec-ogr2osm-translation/blob/master/canvec2016.py
and I hope for many forks and improvements. Right now it does a basic job of 
translating the road classes to OSM types, and the most obvious attributes to 
the corresponding OSM tags.

Let me know what you all think.

Martijn

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

Re: [Talk-ca] Canvec attributes (roads)

[Begin Daniel]

Bonjour Martijn
AFAIK, here is a summary about how old and accurate is Canvec/GeoBase. 

Transport Layers? 
The roads are updated every 1-2 years for most of the provinces, 5-10 for 
others. 
Railways were updated 4-5 years ago over all the Canadian landmass.

Other layers
Water features are 5-40+ years old depending on the province/territory/latitude;
Forest areas are 5-40+ years old depending on the province/territory/latitude 
[1]. 
The rest is 25-40+ years old.

About the accuracy, the road network is about 10m (90%). The rest is usually 
better than 30m (90%) but you may find offsets between layers.

Daniel

[1] About forest areas, the latest GeoBase data results from images 
classification made about 5 years ago that gave the clumsy result Paul Ramsay 
recently shown on this list. The latest Canvec OSM tiles (2012?) had a mixture 
of old map data/new GeoBase data.

-Original Message-
From: Martijn van Exel [mailto:m...@rtijn.org] 
Sent: Monday, 12 September, 2016 23:06
To: Stewart C. Russell; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec attributes (roads)

On 09/12/2016 06:50 PM, Stewart C. Russell wrote:
> On 2016-09-12 04:08 PM, Martijn van Exel wrote:
>> Aren't these files grouped by feature type? So if we look at roads we 
>> wouldn't also necessarily need to look at land use boundaries etc.?
>
> Canvec - the product supplied by NRCan to the general public - always 
> was split by feature type. It's the OSM tiles, of structure decided 
> long ago, that lump everything together.
>
> It's also available as effectively seamless FGDBs if you want to avoid 
> the cleanup required after using tiled data. The FGDBs retain the 
> critically important survey dates and accuracies - so you can easily 
> see how much data's 40 years old and has ±75 m positional accuracy.
>

Good to know.
Are any of the transport related datasets that old or that inaccurate?

I created an initial Canvec road network translation file for ogr2osm, so you 
can convert the Canvec shapefiles to OSM format easily (if you know how to work 
ogr2osm - let me know if you need help, but Paul Norman is the expert here!)

It is located at
https://github.com/mvexel/canvec-ogr2osm-translation/blob/master/canvec2016.py
and I hope for many forks and improvements. Right now it does a basic job of 
translating the road classes to OSM types, and the most obvious attributes to 
the corresponding OSM tags.

Let me know what you all think.

Martijn

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

Re: [Talk-ca] CanVec Reverts

[Begin Daniel]

Hum 
First discussions about importing NRCan data can be find here...
https://lists.openstreetmap.org/pipermail/talk-ca/2008-November/000228.html

They are talking about importing GeoBase - which is exactly the same content 
that is found in Canvec since Canvec is the merging of GeoBase layers.

If you look at the date (November 2008), the import mailing list even did not 
exist.

We can go that way but I do not think it the point here. We must talk about 
deleting data that was imported in good faith, without leaving the community 
enough time to correct them. 

Daniel

-Original Message-
From: Michael Reichert [mailto:naka...@gmx.net] 
Sent: Thursday, 1 September, 2016 15:41
To: James
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] CanVec Reverts

Hi James,

Am 2016-09-01 um 15:04 schrieb James:
> To blatantly toss discussions of the
> past whether to import CanVec or not into OSM and *that was approved*, 
> …

Could you point me to the discussion at the Imports mailing list? (link to the 
archive of the mailing list)

I am not against importing CanVec data, I am just against importing CanVec data 
in a bad way.

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

Re: [Talk-ca] Forests/Land Use, was: Canvec reverts

[Begin Daniel]

P: OSM is very much an "add only" project, since the social consequences of 
incorrectly deleting things seem so high.

What I do perceive in the current thread is that deleting something not perfect 
without replacing it with something better hurts, not that it is not acceptable 
to delete something.

Daniel

From: Paul Ramsey [mailto:pram...@cleverelephant.ca]
Sent: Thursday, 1 September, 2016 13:05
To: Begin Daniel
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Forests/Land Use, was: Canvec reverts


On Thu, Sep 1, 2016 at 8:49 AM, Begin Daniel 
<jfd...@hotmail.com<mailto:jfd...@hotmail.com>> wrote:
What is very cool with OSM is that you can edit the data. Urban polygon is 
wrong? Modify it! The definition is obscure in the Wiki? Change it! But yes, 
the learning curve is often steep, and you may need to discuss with someone 
else…

"Just fix it" is not quite the answer. The point the original poster made, 
which I concur with, is that the very existence of these shapes makes working 
with the "important" data difficult. In terms of forest and land use polygons, 
every vertex I move there is a vertex I'm not going to move on something 
"important".  (And the vertex density of the forests/land use are another 
reason that working around/with them is painful and energy-sapping.)

As discussed in the other thread, the shear volume of Canada means I'm never in 
1M years going to "fix" the forests. As it stands, I mostly ignore them. Too 
many vertexes to move, for too little net benefit, so there's forests running 
through the new subdivisions of Prince George. At least the roads are there and 
hopefully correctly named now.

 (I would, however, love to just delete the urban "land use" polygons, but who 
know if that's "allowed" or not. Absent a strong personality like the person 
who caused this thread, it seems like OSM is very much an "add only" project, 
since the social consequences of incorrectly deleting things seem so high. 
Nobody wants to be "that guy".)

ATB,

P



From: Paul Ramsey 
[mailto:pram...@cleverelephant.ca<mailto:pram...@cleverelephant.ca>]
Sent: Thursday, 1 September, 2016 11:17
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] Forests/Land Use, was: Canvec reverts

I'm "glad" to see someone else w/ this issue. It's glancingly related to the 
canvec import issue, since the land use polygons are a source of some of the 
issues the reverter is complaining about (malformed multipolygons / boundary 
overlaps).

In my own work in my old home town of Prince George, I've constantly wanted to 
just plain delete the "urban area" land use polygon (which doesn't seem to 
correspond in any way to the actual urban area of the present) and the forest 
polygons (which have the same problem).

Unlike buildings and roads and water, land use is pretty sloppy: where does the 
"urban area" end? Is this a "forest" or just a bunch of trees? Since anyone 
making a real multi-scale map will fine some other source of land-use (like 
classified landsat) and since people trying to map at high-res are finding the 
forests add little value and much impedance, why don't we ... burn down all the 
forests (and the urban areas too)?

P

On Thu, Sep 1, 2016 at 6:54 AM, Loïc Haméon 
<hame...@gmail.com<mailto:hame...@gmail.com>> wrote:

On a final note, though, I certainly would approve of any effort to reduce the 
size of the upload chunks and the assorted polygons. For new mappers like me, 
those create daunting challenges when trying to make incremental improvements 
to an area. Shortly after joining the OSM community I was back in my home town 
of Saint-Félicien, in a fairly remote region that hasn't had tons of local 
mapping done. Some of the inhabited areas I aimed to improve were covered by 
Canvec forest multipolygons, and I ended up giving up on them until I could get 
some more experience as I absolutely did not understand what the hell was going 
on

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

Re: [Talk-ca] broken forests in eastern Canada

[Begin Daniel]

You are right about Canadian government open data; I was referring at the 
Canvec data in OSM format most of us used.
Daniel

-Original Message-
From: Stewart C. Russell [mailto:scr...@gmail.com] 
Sent: Thursday, 1 September, 2016 11:53
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] broken forests in eastern Canada

On 2016-09-01 09:05 AM, Begin Daniel wrote:
> 
> - Run a better version of the preprocessor on the Canvec raw data and 
> reimport them again? Not possible. Canvec data has been produced and 
> renew between 2010 and 2012 by our national mapping agency (NRCan).
> The product is now static (no updates) but NRCan graciously keeps it 
> available to us...

Canvec - the Government of Canada product - isn't static. It's supplied under 
an OSM-friendly licence. In its current version, it's supplied in a (mostly) 
seamless format. This would avoid the tile issue.
http://open.canada.ca/data/en/dataset/23387971-b6d3-4ded-a40b-c8e832b4ea08

Michael: your metric of upload features per minute is arbitrary and capricious. 
These data are the best that the Canadian OSM community had at the time. Please 
respect that while we work out if/when/how we can do something better. Deleting 
map data for arbitrary reasons is vandalism.

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

Re: [Talk-ca] Forests/Land Use, was: Canvec reverts

[Begin Daniel]

Why don't we ... burn down all the forests (and the urban areas too)?
Been in Fort-McMurray lately? (Ok it is a bad joke)

Seriously, these discussions about what should be mapped or not, what is 
valuable content or not are raging since the beginning of OSM. More recently, 
discussions around the value of hand crafted map compared to imported data are 
also dividing the community. Those are all ‘normal events’ in a collective work 
and they will not stop. Best thing to do is sharing your concerns, as you just 
did. These are seeds that may grow up, or not.

What is very cool with OSM is that you can edit the data. Urban polygon is 
wrong? Modify it! The definition is obscure in the Wiki? Change it! But yes, 
the learning curve is often steep, and you may need to discuss with someone 
else…

Best regard,
Daniel

From: Paul Ramsey [mailto:pram...@cleverelephant.ca]
Sent: Thursday, 1 September, 2016 11:17
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] Forests/Land Use, was: Canvec reverts

I'm "glad" to see someone else w/ this issue. It's glancingly related to the 
canvec import issue, since the land use polygons are a source of some of the 
issues the reverter is complaining about (malformed multipolygons / boundary 
overlaps).

In my own work in my old home town of Prince George, I've constantly wanted to 
just plain delete the "urban area" land use polygon (which doesn't seem to 
correspond in any way to the actual urban area of the present) and the forest 
polygons (which have the same problem).

Unlike buildings and roads and water, land use is pretty sloppy: where does the 
"urban area" end? Is this a "forest" or just a bunch of trees? Since anyone 
making a real multi-scale map will fine some other source of land-use (like 
classified landsat) and since people trying to map at high-res are finding the 
forests add little value and much impedance, why don't we ... burn down all the 
forests (and the urban areas too)?

P

On Thu, Sep 1, 2016 at 6:54 AM, Loïc Haméon 
> wrote:

On a final note, though, I certainly would approve of any effort to reduce the 
size of the upload chunks and the assorted polygons. For new mappers like me, 
those create daunting challenges when trying to make incremental improvements 
to an area. Shortly after joining the OSM community I was back in my home town 
of Saint-Félicien, in a fairly remote region that hasn't had tons of local 
mapping done. Some of the inhabited areas I aimed to improve were covered by 
Canvec forest multipolygons, and I ended up giving up on them until I could get 
some more experience as I absolutely did not understand what the hell was going 
on
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] broken forests in eastern Canada

[Begin Daniel]

I agree with you that Michael is forcing us to improve the quality of our data. 
However, the way he is doing this also matters. Until we are convinced that he 
will not delete what has been done over the years, this thread should keep 
running. Then we will able to discuss about improving the Canvec import process.

About preferring quality over quantity, I think that in the context of this 
discussion, we are rather talking about having something on the map instead of 
nothing.

Best regards,
Daniel

-Original Message-
From: dega [mailto:gade...@gmail.com] 
Sent: Thursday, 1 September, 2016 10:19
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] broken forests in eastern Canada

On September 1st, John Whelan wrote:
> I suggest we formally request that he is prevented from making any 
> changes within Canada and his reversals be reverted.
> The Canvec data was imported with the knowledge and support of the 
> local mappers and I think that's all that matters.
I disagree!
Michael's goal is to force us to improve the quality of our data. He's not a 
vandal.

Personnaly, I also prefer quality over quantity.
Why don't we take a pause to discuss how we can improve the quality of the 
CanVec import process?

dega (a local mapper since 2007)

___
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] broken forests in eastern Canada

[Begin Daniel]

Few comments...
- The people how import the data should know how [multipolygon] work (), +1 
- Run a better version of the preprocessor on the Canvec raw data and reimport 
them again? Not possible. Canvec data has been produced and renew between 2010 
and 2012 by our national mapping agency (NRCan). The product is now static (no 
updates) but NRCan graciously keeps it available to us...
- Replacing the grid by less artificial borders, e.g. roads, rivers, 
powerlines... Some of us have started doing this - including myself. However I 
do not consider it as a real problem since the multipolygon have to be split 
somewhere anyway.
- [Imports] should undergo the manual quality checks I described in my other 
emails and the changeset comments. Agreed, but how many errors will you 
tolerate in a changeset before deleting it?

Daniel

-Original Message-
From: Michael Reichert [mailto:naka...@gmx.net] 
Sent: Thursday, 1 September, 2016 08:40
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] broken forests in eastern Canada

Hi,

Am 01.09.2016 um 01:21 schrieb dega:
> On Aug 31, Daniel Bégin wrote:
>> On the same topic, it has been suggested to split wooded areas in 
>> smaller chunks by using features on the ground as outer limits 
>> (mostly roads, streams, rivers) and get rid of arbitrary rectangles from 
>> Canvec.
>> Is it something we are aiming at?
> 
> The grid is an important source of problems. Here are some examples:
> 1) If a lake is on the grid, it will be split in 2 parts. Each part 
> will have a name tag and and 2 identical names will be displayed on 
> the map, one on each part. This problem exist in thousands of lakes. I 
> even saw a lake with a triplicated name.
> Merging the parts would require modifying 2 or more relations and many 
> importers don't do it (even if they use JOSM) because of the 
> complexity. Some have used a quick fix where they remove names from 
> the parts and put it in a POI. It looks fine but that's bad for database 
> integrity.

If someone does not merge two lakes because it is too "complex", he should 
evaluate if he is the right person to import such data. If an import contains 
much multipolygon relations, the people how import the data should know how 
they work, what can be done wrong, how to edit and how to fix them. :-/

> 2) A addr:interp way may be split in 2 parts. 2 consequences:
> - the interpolation way become useless because it's now 2 different objects.
> - the mid-point becomes 2 superposed nodes. Useless duplication.
> 
> 3) A grid tile has a fixed size. It may be appropriate for unpopulated 
> areas but it is too large for urban areas where editors work at a high 
> zoom level
> (17 and up). It's easy to damage a relation without knowing it.
> 
> But there are other problems (not related to the grid):
> 4) the relations seem to be designed to be stand-alone. Thus the 
> relation borders don't share a way. They use 2 superposed ways. Useless 
> duplication.
> It's very confusing and we frequently alter the wrong way.
> 
> 5) lakes are represented by 2 superposed identical objects, one for 
> the hole and one for the lake. If the hole happen to be on top, the 
> name will not be displayed. It's an unjustifiable complexity for the casual 
> user.
> I've also seen triplicated contour (one for the lake, on for the inner 
> role and one for the outer role)
> 
> Yes, all these quirks can be fixed manually but it's time-consuming 
> and error- prone.

What about reverting the tiles which have all these issues and seem to be 
uploaded with too few checks beforehand, run a better version of the 
preprocessor on the CanVec raw data and reimport them again? (That causes a 
loss of OSM history but an import changeset is not as much valueable than a 
manual changeset)

> Ideally, the contour of a forest must not split any object and it's 
> not possible with a grid.
> The sole advantage of a grid IMHO is to simplify the CanVec exports.

What about replacing the grid by less artificial borders, e.g. roads, rivers, 
powerlines etc. If an area has too few of theses objects, artifical borders 
could be automatically drawn which are optimized to cut as few objects as 
possible into two parts.

> Some years ago I would have proposed that someone write a guide "How 
> to fix a CanVec import". But now I would rather propose that someone 
> write a "How to pre-process a CanVec export before importing it into OSM".

+1

All ongoing changesets which import CanVec data should either use an improved 
version of the preprocessor or should undergo the manual quality checks I 
described in my other emails and the changeset comments.

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

Re: [Talk-ca] CanVec Reverts

[Begin Daniel]

I understand your point. You might be right about the time between changesets 
(even though it may depends on if the users is working with layers), but I 
maintain my points about the time it may take within a changeset.
Daniel

-Original Message-
From: Michael Reichert [mailto:naka...@gmx.net] 
Sent: Thursday, 1 September, 2016 08:37
To: Begin Daniel; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] CanVec Reverts

Hi Daniel,

Am 2016-09-01 um 12:26 schrieb Begin Daniel:
> Furthermore, I hope you will not use you 100 objects per minute to 
> decide whether or not you will delete a changeset. I think this 
> threshold is value doesn't' apply (see below)
> 
> Daniel
> 
> About the100 objects threshold.
> From my experience, if I load a Canvec tile in JOSM, make all the necessary 
> corrections and then import the result to OSM, I throw up to 25K objects to 
> the database within five minutes.  As far as I know, the timestamps attached 
> to the changeset and to the objects is generated by the OSM database when 
> receiving the data. The five minutes it takes to upload the data to the 
> database (5K objects per minute) do not reflect the time I spent editing the 
> data prior to the upload.

That's the base of my calculation I did with Rps333's changesets:

changeset   start   end object count

3951757119:30:5319:32:564311
3951768619:35:3019:41:1211724
3951794419:45:1519:47:274963
3951814719:53:2520:04:5519286

As you see, he took less than three minutes minutes after uploading
39517571 to prepare 39517686. You cannot check such an amount of data very well 
within that time.

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

Re: [Talk-ca] CanVec Reverts

[Begin Daniel]

Thank for contacting the Canadian community Michael, 
You provided us with a short but useful reminder of current rules we should 
apply when importing data (or even just making standard edits).

However, I understand from your last paragraph that you will keep deleting 
changesets. I was hoping your email started a discussion on best practices that 
we could be put in place in our context since adjusting Canvec data to the 
latest rules is a daunting task. I rather feel it is an ultimatum.  

Do your future actions will apply to the imports made a few months, a few years 
ago, which are 'full of errors' and for which nobody seems to care? Are you 
going to check with concerned contributors (old/future imports) if they bother 
or not to see their work deleted before you do it? 

Furthermore, I hope you will not use you 100 objects per minute to decide 
whether or not you will delete a changeset. I think this threshold is value 
doesn't' apply (see below)

Daniel

About the100 objects threshold.
From my experience, if I load a Canvec tile in JOSM, make all the necessary 
corrections and then import the result to OSM, I throw up to 25K objects to the 
database within five minutes.  As far as I know, the timestamps attached to the 
changeset and to the objects is generated by the OSM database when receiving 
the data. The five minutes it takes to upload the data to the database (5K 
objects per minute) do not reflect the time I spent editing the data prior to 
the upload.

-Original Message-
From: Michael Reichert [mailto:naka...@gmx.net] 
Sent: Thursday, 1 September, 2016 01:39
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] CanVec Reverts

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

unfortunately posting via Gmane does not seem to work (the website is down but 
NNTP still works), that's why I have to start a new thread. :-(

Am Tue, 30 Aug 2016 21:41:21 -0500 schrieb Sam Dyck:
> After reading through the changeset discussion, I discovered that one 
> of my imports in Northern Manitoba made Worst of OSM.
> (http://worstofosm.tumblr.com/post/22180046353/dear-
> openstreetmap-isnt-it-strange-how-the). As someone who spends a some 
> time amount of time in some of relatively unpopulated areas of Canada 
> and makes an effort to check the quality of Canvec data (which is 
> usually pretty good), I do agree that it is impossible to do 
> everything to the same level of quality that we would provide in 
> Toronto or Timmins or even small prairie towns.

First of all, it is ok that an import takes a few years and therefore creates 
ugly green rectancles on the map. If an import is "unavoidable"
:-), a manual import is the best thing that can be happen. But if someone 
uploads a changeset without a manual review beforehand, he counteracts the aim 
of a manual import: addind good data to OpenStreetMap. That's what I am mainly 
fighting against. If a users uploads much more than 100 objects per minute [1], 
you can be sure that he has not done any manual review. A manual review by 
myself confirmed this these. I am fighting against such changesets/users.

A good imports must be reviewed *before* it is being uploaded. The review 
contains:
- - Run JOSM validator, fix all warnings and errors. This includes all warnings 
regarding validity of areas. (you can argue if all warnings about "deprecated" 
tagging have to be fixed)
- - Compare the data with available imagery. Is the forest really a forest or 
is another tag more appropiate? Right-click on a Bing tile at JOSM and have a 
look how old/recent the imagery is.
- - Check if CanVec data fits to itself.
http://worstofosm.tumblr.com/post/22180046353/dear-openstreetmap-isnt-
it-strange-how-the
- - Check if there has been any other data before. If yes, adapt the either the 
CanVec data or the old data.
https://wiki.openstreetmap.org/wiki/File:Import-Fails-Powerlines-Not-Ins
ide-Cutting.png
https://www.openstreetmap.org/way/439631732
- - Ways should not overlap with other ways if it is not necessary. The outer 
ring of a lake should also be inner member of the forest multipolygon. Maybe 
the program which created the OSM files should be imprved?
- - Keep the history.
https://wiki.openstreetmap.org/wiki/Good_practice#Keep_the_history

If a tile has been imported without being checked manually and no post-upload 
fixes have been done (i.e. upload without any checks), I will not shrink from 
reverting it. If a tile has been uploaded to OSM without a review and if it has 
not been fixed within a month, it is worthless and can easily be reimported at 
a later time if someone has the time to check and fix it.

For the future, I will abstain from reverting changesets which have been 
imported before September 1, 2016 and whose users are currently doing the fixes 
that should already have been done. But if I come across an imported tile of 
low quality which has not been touched for a few weeks and is full of errors, 
it is just a question of time until it is 

Re: [Talk-ca] broken forests in eastern Canada

[Begin Daniel]

“Whats up with the forests in Canada?” A wiki page is a good idea!

And while talking about forest in eastern Canada…

It would be very helpful to have a plugin in JOSM that deals with Canvec 
water/wooded area integration in multipolygon.  I am not really a developer but 
since the merging operations are repeated over and over again over large 
areas... might it be possible to do something?

On the same topic, it has been suggested to split wooded areas in smaller 
chunks by using features on the ground as outer limits (mostly roads, streams, 
rivers) and get rid of arbitrary rectangles from Canvec. Is it something we are 
aiming at?

Daniel

From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: Wednesday, 31 August, 2016 07:00
To: Sam Dyck
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] broken forests in eastern Canada

> we need to have a "Whats up with the forests in Canada?" page on the wiki to 
> explain our situation and how we've tried to deal with it
Sounds like a plan.
Cheerio John

On 30 August 2016 at 22:41, Sam Dyck 
> wrote:
After reading through the changeset discussion, I discovered that one of my 
imports in Northern Manitoba made Worst of OSM. 
(http://worstofosm.tumblr.com/post/22180046353/dear-openstreetmap-isnt-it-strange-how-the).
 As someone who spends a some time amount of time in some of relatively 
unpopulated areas of Canada and makes an effort to check the quality of Canvec 
data (which is usually pretty good), I do agree that it is impossible to do 
everything to the same level of quality that we would provide in Toronto or 
Timmins or even small prairie towns.

One of the things that seems to bother Nakaner and the WoO people (if I may put 
words in their mouths) is that the boundaries are a bit funky in Canvec. 
Forests, lakes and wetlands spill into each other, and they are often out of 
alignment with the Bing imagery. In some ways this reflects a degree of natural 
ambiguity: if we look at the above Hudson's bay coastline, their is hourly 
variation in coastlines, and even the long term patterns change over time. The 
Manitoba-Nunavut boundary is more or less fixed by so we can't correct it, and 
a glance at satellite imagery shows that the vegetation tends to be spaced off 
of the shoreline.
That being said sometimes there is some weird stuff happening in Canvec data 
that is out of sync with what is on the ground. These should be corrected when 
detected, but are rare enough that they shouldn't be a problem. I confess I 
haven't always been great in following the rules when doing imports (I think 
the last few years I've been fully in compliance), and have sometimes caused 
problems, people on this list have generally understanding. Perhaps we need to 
have a "Whats up with the forests in Canada?" page on the wiki to explain our 
situation and how we've tried to deal with it.

___
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] broken forests in eastern Canada

[Begin Daniel]

No problem,
I am not sure about the best way to deal with wooded areas. Canvec product was 
created with “layers” and merging them manually in a multipolygon is quite 
difficult.

I usually correct everything that is reasonable such as merging water in wooded 
multipolygon, transferring text nodes on corresponding areas, but not sliver 
between wetland-water-wooded areas. Which leave some errors most of the time.

Daniel



From: James [mailto:james2...@gmail.com]
Sent: Tuesday, 30 August, 2016 21:04
To: Begin Daniel
Cc: Talk-CA OpenStreetMap; john whelan; Adam Martin
Subject: RE: [Talk-ca] broken forests in eastern Canada


Sorry I'm a very sarcastic person and have trouble decerning if people are 
sarcastic or not.

Anyways what should we do with canvec tiles? Should we correct as much as 
possible leaving only 0-10 warnings(there are nodes that are tagged as land, 
but there's island names or other relevant info aka depricated tags) or should 
we just correct errors on them before uploading? The major problem in CanVec 
tiles is you have ways stacked on ways that are essentially the same way, but 
belonging to one or more multipolygons.

On Aug 30, 2016 8:55 PM, "Begin Daniel" 
<jfd...@hotmail.com<mailto:jfd...@hotmail.com>> wrote:
No sarcasm at all, why?
Sorry you got that impression ☹

Daniel

From: James [mailto:james2...@gmail.com<mailto:james2...@gmail.com>]
Sent: Tuesday, 30 August, 2016 20:50
To: Begin Daniel
Cc: Talk-CA OpenStreetMap; john whelan; Adam Martin

Subject: Re: [Talk-ca] broken forests in eastern Canada


Not sure if you are sarcastic or serious... but anyways, I'm glad the rest of 
talk-ca feels the same way(sorry for highjacking fix the forest thread even 
though it was kind of related)

On Aug 30, 2016 8:43 PM, "Begin Daniel" 
<jfd...@hotmail.com<mailto:jfd...@hotmail.com>> wrote:
Wow, same ideas, same concerns, provided independently...
That is cool!
Daniel

From: Adam Martin [mailto:s.adam.mar...@gmail.com]
Sent: Tuesday, 30 August, 2016 19:15
To: john whelan

Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] broken forests in eastern Canada

I've contacted him as well. Here's what I sent:

Good day, Nakaner


I am a resident of Canada and a contributor to OSM here. Looking over your 
profile, you have over 5,500 edits across the OSM project, making you a skilled 
mapper. It has come to the attention of the Canadian OSM community recently 
that you have been performing work here and we appreciate that. However, it has 
also come to our attention that much of the work you are doing involves 
reverting the CANVEC data imports that we use here without consultation with 
the local OSM group.

As you know, mapping is an involved process, especially in a country as large 
geographically as Canada. Our population is relatively low, which results in 
large expanses of land being effectively free of human involvement. Since 
mapping effort tend to centre around human activity, this means that large 
parts of Canada can go unmapped for a long time. To combat this, we have made 
use of the CANVEC data graciously made available by the Federal Government 
through the Department of Natural Resources. This information covers most of 
the country in its surveys. It is known to be somewhat inaccurate, but in the 
absence of information in a given area, it is definitely welcome.

Most of the imports that you are flagging for revision have been in place for 
years; in some cases, even before the policy for importation was in place. I'm 
sure that they didn't always meet the guidelines that are now in place within 
the larger OSM community, but the fact remains that the information that they 
represent is invaluable to the Canadian portion of the map and the mappers here.

If you wish to have that data become higher in quality, you are on the same 
side as the Canadian mapping community. We know the limitations of CANVEC and 
are working to allieviate them. Come join our OSM talk list and discuss your 
concerns with us. We are very welcoming to any points of view on the map. This 
allows all of us to come to a mutual understanding and solution to the problems 
with the imported data that you highlight.

Our list is talk-ca@openstreetmap.org<mailto:talk-ca@openstreetmap.org>

Thanks,

Adam



___
Talk-ca mailing list
Talk-ca@openstreetmap.org<mailto: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] broken forests in eastern Canada

[Begin Daniel]

No sarcasm at all, why?
Sorry you got that impression ☹

Daniel

From: James [mailto:james2...@gmail.com]
Sent: Tuesday, 30 August, 2016 20:50
To: Begin Daniel
Cc: Talk-CA OpenStreetMap; john whelan; Adam Martin
Subject: Re: [Talk-ca] broken forests in eastern Canada


Not sure if you are sarcastic or serious... but anyways, I'm glad the rest of 
talk-ca feels the same way(sorry for highjacking fix the forest thread even 
though it was kind of related)

On Aug 30, 2016 8:43 PM, "Begin Daniel" 
<jfd...@hotmail.com<mailto:jfd...@hotmail.com>> wrote:
Wow, same ideas, same concerns, provided independently...
That is cool!
Daniel

From: Adam Martin [mailto:s.adam.mar...@gmail.com]
Sent: Tuesday, 30 August, 2016 19:15
To: john whelan

Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] broken forests in eastern Canada

I've contacted him as well. Here's what I sent:

Good day, Nakaner


I am a resident of Canada and a contributor to OSM here. Looking over your 
profile, you have over 5,500 edits across the OSM project, making you a skilled 
mapper. It has come to the attention of the Canadian OSM community recently 
that you have been performing work here and we appreciate that. However, it has 
also come to our attention that much of the work you are doing involves 
reverting the CANVEC data imports that we use here without consultation with 
the local OSM group.

As you know, mapping is an involved process, especially in a country as large 
geographically as Canada. Our population is relatively low, which results in 
large expanses of land being effectively free of human involvement. Since 
mapping effort tend to centre around human activity, this means that large 
parts of Canada can go unmapped for a long time. To combat this, we have made 
use of the CANVEC data graciously made available by the Federal Government 
through the Department of Natural Resources. This information covers most of 
the country in its surveys. It is known to be somewhat inaccurate, but in the 
absence of information in a given area, it is definitely welcome.

Most of the imports that you are flagging for revision have been in place for 
years; in some cases, even before the policy for importation was in place. I'm 
sure that they didn't always meet the guidelines that are now in place within 
the larger OSM community, but the fact remains that the information that they 
represent is invaluable to the Canadian portion of the map and the mappers here.

If you wish to have that data become higher in quality, you are on the same 
side as the Canadian mapping community. We know the limitations of CANVEC and 
are working to allieviate them. Come join our OSM talk list and discuss your 
concerns with us. We are very welcoming to any points of view on the map. This 
allows all of us to come to a mutual understanding and solution to the problems 
with the imported data that you highlight.

Our list is talk-ca@openstreetmap.org<mailto:talk-ca@openstreetmap.org>

Thanks,

Adam



___
Talk-ca mailing list
Talk-ca@openstreetmap.org<mailto: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] broken forests in eastern Canada

[Begin Daniel]

Wow, same ideas, same concerns, provided independently...
That is cool!
Daniel

From: Adam Martin [mailto:s.adam.mar...@gmail.com]
Sent: Tuesday, 30 August, 2016 19:15
To: john whelan
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] broken forests in eastern Canada

I've contacted him as well. Here's what I sent:

Good day, Nakaner


I am a resident of Canada and a contributor to OSM here. Looking over your 
profile, you have over 5,500 edits across the OSM project, making you a skilled 
mapper. It has come to the attention of the Canadian OSM community recently 
that you have been performing work here and we appreciate that. However, it has 
also come to our attention that much of the work you are doing involves 
reverting the CANVEC data imports that we use here without consultation with 
the local OSM group.

As you know, mapping is an involved process, especially in a country as large 
geographically as Canada. Our population is relatively low, which results in 
large expanses of land being effectively free of human involvement. Since 
mapping effort tend to centre around human activity, this means that large 
parts of Canada can go unmapped for a long time. To combat this, we have made 
use of the CANVEC data graciously made available by the Federal Government 
through the Department of Natural Resources. This information covers most of 
the country in its surveys. It is known to be somewhat inaccurate, but in the 
absence of information in a given area, it is definitely welcome.

Most of the imports that you are flagging for revision have been in place for 
years; in some cases, even before the policy for importation was in place. I'm 
sure that they didn't always meet the guidelines that are now in place within 
the larger OSM community, but the fact remains that the information that they 
represent is invaluable to the Canadian portion of the map and the mappers here.

If you wish to have that data become higher in quality, you are on the same 
side as the Canadian mapping community. We know the limitations of CANVEC and 
are working to allieviate them. Come join our OSM talk list and discuss your 
concerns with us. We are very welcoming to any points of view on the map. This 
allows all of us to come to a mutual understanding and solution to the problems 
with the imported data that you highlight.

Our list is talk-ca@openstreetmap.org

Thanks,

Adam


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

Re: [Talk-ca] broken forests in eastern Canada

[Begin Daniel]

I have contacted the user that is about/has deleted some changesets imported 
from Canvec. I may agree on some of his comments but totally disagree on the 
method he is using to make his point.

I do not know what the DWG will do about this guy but here is the message I 
sent him...
Bonjour Nakaner, I understand that you wish the data in OSM being accurate, 
well-structured and made according to the rules developed by the OSM community. 
However, I would strongly suggest that you discuss your point with the Canadian 
community before deleting any changesets.

Canvec imports are running for more than 6 years and the structure of the data 
was discussed with the Canadian OSM community, including OSMF members, for more 
than a year. The result is a compromise that used to suit most members. The 
rules you are mentioning in the comments you leave where not even written at 
that time.

Most Canadian importers simply keep doing what they used to do years ago. If 
you consider they should not, have a discussion with the whole Canadian 
community. You will then be able to make your point, make everyone aware of 
these rules and understand your concerns.

You will then be able to build a stronger community, not discourage people to 
contribute because they have made errors...

Daniel

From: James [mailto:james2...@gmail.com]
Sent: Tuesday, 30 August, 2016 09:18
To: Adam Martin
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] broken forests in eastern Canada

He's even going to revert my work:
http://www.openstreetmap.org/changeset/41776742
I've forwarded this to the DWG, it's getting rediculous.

On Tue, Aug 30, 2016 at 9:14 AM, Adam Martin 
> wrote:
That's a pretty harsh thing to deal with. Imports are difficult and the time 
needed to get them right is not a small investment. To have someone review this 
work is a valuable service, but I don't think just blanket reverting due to the 
violation of one rule is the solution, especially in context of the lack of 
data in some of those areas. The CANVEC stuff will do until surveys or 
satellite data catches up with those areas.

On Tue, Aug 30, 2016 at 10:35 AM, John Marshall 
> wrote:
Andrew, I hear you! I have been trying to add data around unmapped Northern 
Communities around James Bay and Nunavut. But after someone revert some of my 
work I'm stopping:(

John

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

Re: [Talk-ca] broken forests in eastern Canada

[Begin Daniel]

Bon points Jean-Denis,
Les descriptions techniques aident souvent. Dans les cas où j’ai utilisé cette 
source de données, elle référait souvent aux lotissements mais la carte des 
lotissements (matrice graphique) ne peut être utilisée dans OSM (licences).
L’autorisation expresse du/des Ministère(s) concerné(s) serait parfaite! On 
peut toujours espérer …

Bonne chance Antoine
Daniel

From: Jean-Denis Giguere [mailto:jdenisgigu...@gmail.com]
Sent: Thursday, 25 August, 2016 08:18
To: Antoine Beaupré
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] broken forests in eastern Canada

Bonjour Antoine,

Pour la limite des parcs, les descriptions techniques des délimitations font 
partie des règlements sur l’établissement des parcs nationaux [1]. Il y a là 
des repères susceptibles d'aider à leur cartographie.
Une autre alternative consisterait à transmettre une demande au Ministère des 
Forêts, de la Faune et des Parcs pour obtenir les données géospatiales de leur 
délimitation avec l'autorisation expresse d'intégrer les données dans 
OpenStreetMap.


Salutations cordiales,


Jean-Denis


[1] Voir par exemple, http://legisquebec.gouv.qc.ca/fr/ShowDoc/cr/P-9,%20r.%201

2016-08-16 17:04 GMT-04:00 Antoine Beaupré 
>:
hi everyone (allo tout le monde!!)

one of the most frustrating experiences I have with Openstreetmap in
Canada is this ugly forest display:

http://www.openstreetmap.org/#map=8/45.227/-73.916

Just compare how the forests and parks are mapped between the US and
Canada. On our side of the border, you got huge chunks of square forests
that definitely do not reflect the current reality, whereas down south
you clearly see national parks, forests and no weird square things.

I don't really understand how this happened, but it's been there a long
time. I feel it's some Canvec import that went wrong, but it's been
there for so long that it seems people just forgot about it or moved on.

I looked around in the .qc and .ca wiki pages and couldn't find anything
about it, so I figured I would bring that up here (again?).

Are there any plans to fix this? How would one go around fixing this
anyways?

In particular, I'm curious to hear if people would know how to import
*all* the park limits in Québec. It seems those are better mapped in
Ontario, and I can't imagine those wore drawn by hand..

Thanks for any feedback (and please CC me, I'm not on the list).

A.

--
We will create a civilization of the Mind in Cyberspace. May it be more
humane and fair than the world your governments have made before.
- John Perry Barlow, 1996
A Declaration of Independence of Cyberspace

___
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] broken forests in eastern Canada

[Begin Daniel]

Bonjour Antoine,

Pour ajouter aux commentaires d'Alan et d'Adam.

Pour ce qui est de la forêt...
Comparer la forêt US/Canada est un peu injuste.  En général, la forêt n'est pas 
cartographiée du côté US, et elle a été partiellement importée du côté canadien 
- d'où les vides de forme rectangulaire...
Corriger toute la forêt du côté canadien voudrait dire importer ce qui manque 
via Canvec et ce serait possiblement problématique...
Corriger localement de façon manuel est possible. J'ai déjà corrigé plusieurs 
centaines de Km2 de 'trous' au nord et à l'est de Sainte-Agathe-des-Monts. Les 
trous qui apparaissent encore dans cette zone ont été causés  par la suite par 
des éditeurs qui ne sont pas familiers avec les multipolygon.

Pour ce qui est des parcs nationaux du Québec...
Je ne connais pas de sources de données qui permettent l'import légal des 
limites de parc au Québec. 
J'ai ajouté quelques limites de parc dans OSM (Yamaska, Frontenac. Mégantic et 
Bic). Je connaissais bien ces endroits et je me suis servi  de documents 
touristiques pour guider ma photo-interprétation - on ne doit pas copier les 
cartes. Une fois qu'on a compris le territoire, la démarcation visuelle entre 
les terres protégées/non protégées sur les images est généralement asses 
simple, mais j'ajoute quand même une note pour signifier que les  limites sont 
approximatives. 

Daniel


-Original Message-
From: Antoine Beaupré [mailto:anar...@orangeseeds.org] 
Sent: Tuesday, 16 August, 2016 17:05
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] broken forests in eastern Canada

hi everyone (allo tout le monde!!)

one of the most frustrating experiences I have with Openstreetmap in Canada is 
this ugly forest display:

http://www.openstreetmap.org/#map=8/45.227/-73.916

Just compare how the forests and parks are mapped between the US and Canada. On 
our side of the border, you got huge chunks of square forests that definitely 
do not reflect the current reality, whereas down south you clearly see national 
parks, forests and no weird square things.

I don't really understand how this happened, but it's been there a long time. I 
feel it's some Canvec import that went wrong, but it's been there for so long 
that it seems people just forgot about it or moved on.

I looked around in the .qc and .ca wiki pages and couldn't find anything about 
it, so I figured I would bring that up here (again?).

Are there any plans to fix this? How would one go around fixing this anyways?

In particular, I'm curious to hear if people would know how to import
*all* the park limits in Québec. It seems those are better mapped in Ontario, 
and I can't imagine those wore drawn by hand..

Thanks for any feedback (and please CC me, I'm not on the list).

A.

--
We will create a civilization of the Mind in Cyberspace. May it be more humane 
and fair than the world your governments have made before.
- John Perry Barlow, 1996
A Declaration of Independence of Cyberspace

___
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] OpenStreetMap at the Crossroads – The Map Room

[Begin Daniel]

+1

From: Adam Martin [mailto:s.adam.mar...@gmail.com]
Sent: Friday, 19 August, 2016 12:21
To: Stewart C. Russell
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] OpenStreetMap at the Crossroads – The Map Room


Wait! You mean a robot ... Made a mistake!!?? Say it ain't so!

Sarcasm aside, it's not surprising. The article speaks so highly of the robots 
and the crisis peeps over the crafters and the arm chair people. But it has 
been my experience that unless the importer is skilled and regularly consults 
the locals, the result is invariably bad for the map.

The demotion of craft mappers and arm chair mappers to, effectively, bottom 
feeders does a disservice to the map. I map my local area and arm chair 
locations far away. I do not think those contributions are damaging or niche. 
My local work is for things only a local could know. And my remote stuff is, 
while based on the satellite, things that need refinement (better shaping) or 
things that are missing that seems beneath some mappers (such as service 
roads). No one seems to want to survey this type of thing or to make sure a 
road flows correctly. This is especially true for some of the robot work. 
Things are imported and left that way with no regard for confirming that the 
new data appears reasonable. One place I went over had imported streets that 
were not connected together, so I fixed it from my position thousands of 
kilometers away. As long as one is conscious of the need to defer to the locals 
and preserve information already in place, there is nothing wrong with remote 
mapping.

On Aug 19, 2016 1:02 PM, "Stewart C. Russell" 
> wrote:
This week's weeklyOSM has a bit about an over-zealous robot from Facebook:
Imports

  *   The Data Working Group (DWG) has 
reverted 
Facebook’s undiscussed import of poor quality autorecognized streets in Egypt. 
See also the discussion on 
one of the reverted changesets.
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

Re: [Talk-ca] Sujet à discussion: relation multipolygone (natural:forest)

[Begin Daniel]

Bonjour Dega,
Je ne suis pas certain de comprendre à quoi tu réfères lorsque tu parles d'un 
mode additif pour les zones de forêt (natural=wood). Dans l'exemple que tu 
donnes, il me semble que la forêt n'a simplement pas encore été captée !-)

On peut voir le captage de la forêt  comme un captage d'objets distincts...
Une forêt est un objet avec un identifiant (id). Les lacs qui se trouvent dans 
son périmètre sont également des objets qui ont leur propre identifiant. Les 
trous qu'ils forment dans la forêt sont identifiés via la relation 'inner'. Il 
n'y a alors pas de duplication d'information.

Le problème pour les forêts importées, c'est qu'il y a généralement deux objets 
pour un même lac - un polygone pour le lac, un polygone pour le trou dans la 
forêt. C'est une décision qui a été prise par la communauté OSM de l'époque. 
JOSM identifie ces cas. Il s'agit alors de détruire la composante 'inner' 
originale (qui n'a pas de tag) et de la remplacer par l'objet lac sous- jacent.

Le wiki me semble suffisamment clair pour le captage des forêts (question 2) Il 
n'y a pas de concept de couche additive. . 
http://wiki.openstreetmap.org/wiki/Relation:multipolygon 
http://wiki.openstreetmap.org/wiki/Multipolygon_Examples 


Pour en revenir à tes questions...
1)  ...créer de nouvelles relations? Techniquement, les deux approches 
fonctionnent. Conceptuellement, s'il s'agit de deux objets 'foret' il pourrait 
être préférable d'avoir deux polygones - mais c'est très théorique.
2) ... plus ce sera difficile. En milieu urbain, la gestion des multipolygones 
est certainement complexe (pas seulement pour la forêt!-). L'ajout de 
clairières me semble assez simple, peu importe le nombre de clairières déjà 
existantes, du moins dans JOSM. Je me répète, le concept de couche additive 
n'existe pas dans OSM.

Autres points à considérer: Dans le sud, c'est une bonne idée de fusionner ou 
segmenter les polygones en fonction des objets existants (rivières, routes) 
plutôt que les limites artificielles utilisés dans Canvec. Dans le nord, ça ne 
sera pas possible considérant que certains polygones couvriront alors des 
milliers d'hectares.

Daniel


-Original Message-
From: dega [mailto:gade...@gmail.com] 
Sent: Friday, 5 August, 2016 17:22
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Sujet à discussion: relation multipolygone (natural:forest)

Bonjour à tous
Lorsque les importations NRC ont commencé dans le nord du Québec, il y avait 
surtout des lacs et des chemins. Quelqu'un a eu l'idée de tout combiner dans 
des relations, ce qui procurait l'avantage de permettre de définir la forêt 
come couche de fond. C'est ce qui donne à la carte du Québec une belle teinte 
verte. La carte d'Ontario est semblable.
Mais, si on regarde les cartes des états de New-York ou du Vermont, on est 
forcés de constater que la couche verte de notre carte est beaucoup plus dense 
alors qu'on sait que les forêts de ces territoires sont semblables.
Le problème de nos multipolygones est qu'ils prennent trop de place parce 
qu'ils ont été créés pour occuper tout l'espace. Chaque multipolygone occupe un 
quadrilatère d'environ 0.125 degré par 0.625 degré. C'est la couche de fond sur 
laquelle sont dessinés (superposés) les cours d'eau et les chemins. 
Si on veut représenter une clairière, il faut la soustraire au multipolygone en 
utilisant un rôle "inner". C'est donc une action soustractive. C'est le 
contraire de ce qu'on fait plus au sud.
Voyons un exemple:
http://www.openstreetmap.com/relation/1456132
http://www.openstreetmap.com/relation/1456128
Ce sont 2 zones adjacentes situées sous:
http://www.openstreetmap.com/relation/1468883
La clairière qui longe la ligne électrique n'a pas été prolongée et on perd 
ainsi la possibilité d'apprécier l'étendue du réseau d'Hydro-Québec.

Dans le multipolygone d'en dessous:
http://www.openstreetmap.com/relation/1456144
on a plûtot décidé de gruger le multipolygone.

Donc, on voit 3 approches:
- ne rien faire (et conserver un fond de carte très dense)
- segmenter le multipolygone en 2
- gruger le multipolygone

La 2ième approche est ma préférée.

Mais les choses se compliquent lorsqu'on s'approche d'une région  urbanisée.
Le multipolygone de départ doit être partagé en fonction des éléments
suiivants:
- grands axes routiers (boulevard, autoroute)
- lignes de transport électrique
- routes
- zones déboisées
Je travaille actuellement sur un multipolygone que j'ai partagé en 6 petits 
polygones. (voir http://www.openstreetmap.org/relation/6300465)

Deux questions:
1) j'ai conservé le même numéro de relation, ce qui fait que la relation 
contient tous les éléments du multipolygone original. Y-a-t-il avantage ou 
désavantage à agir ainsi plutôt que de créer des nouvelles relations?
2) Plus je voudrai ajouter des clairières à ce multipolygone, plus ce sera 
difficile. Je me demande si je ne suis pas arrrivé au point où je devrais 
éliminer la relation (et sa couche de fond) 

Re: [Talk-ca] restriction=no_right_turn_on_red causing routing problems in Toronto

[Begin Daniel]

Whatever the tag or its value, we need it.
There are (unfortunately) plenty of such restrictions in my neighbourhood that 
I never mapped because I did not know how to tag them.

Furthermore, and according to Wikipedia [1], there are whole cities where it 
remains illegal to turn right on a red anywhere, like Montreal and New York.

It is a must for routing…
Daniel

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


From: James [mailto:james2...@gmail.com]
Sent: June-28-16 15:46
To: Nathan Wessel
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] restriction=no_right_turn_on_red causing routing 
problems in Toronto


As andrew said might want to file a bug report with them. Do not map for 
presentation/an application. The application needs to conform to the data
On Jun 28, 2016 3:25 PM, "Nathan Wessel" 
> wrote:

The signs are pretty common, but the tag is not as there are only about 80 of 
them in the GTA and 181 worldwide. I'm wondering if there might be a more 
appropriate way to tag these, instead of tagging them as a restriction? Perhaps 
something like "restriction:signal"="no_turn_on_red", so that it doesn't get 
picked up on a search for the 'restriction' key? I don't think the developers 
are likely to bother checking for such an uncommon tag at this point.



I'm routing with OSRM , which is also used on the 
homepage of openstreetmap.org.


-Nate


From: James >
Sent: Tuesday, June 28, 2016 3:19:28 PM
To: Nathan Wessel
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] restriction=no_right_turn_on_red causing routing 
problems in Toronto


What application were you using to route?
On Jun 28, 2016 2:13 PM, "Nathan Wessel" 
> wrote:

Hi all,

I'm hoping to get some advice on what to do with a relatively uncommon turn 
restriction tag currently in use in Toronto and Ottawa.



https://taginfo.openstreetmap.org/tags/restriction=no_right_turn_on_red



There are about 80 of these 'restriction's in the GTA, and I've noticed that 
they are preventing any right turns when I attempt to route using OSRM. I 
posted about this on the restrictions talk page, 
here,
 and someone suggested that because the restriction value starts with 'no_', it 
is, and should be, treated like an absolute restriction which prevents any 
turns from the 'from' way to the 'to' way.



Anyway, I'm hesitant to outright delete these because I presume they contain 
some potentially useful information, but I also need them to stop restricting 
turns so I can use the data for routing. Maybe these should not be 
'restriction's, but something else?



I'd be happy to make the edits if someone can come up with a good suggestion 
here.



Thanks,

Nate Wessel
Jack of all trades, master of geography

1-330-936-2849

Vesalius Design

___
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] aerial imagery for missing roads

[Begin Daniel]

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

Re: [Talk-ca] Fusions ou remplacement de chemins et les attributs originaux

[Begin Daniel]

Bonjour Claude,
Il y a bien une discussion sur la définition de ‘trunk’ pour laquelle il n’y a 
toujours pas de consensus clair, mais il n’y a pas eu d’ambitieux projets de 
redéfinition des routes discutée avec la communauté canadienne.

As-tu communiqué avec le/les auteurs de ces changements?
S’ils restent muets à tes demandes  et agissent sans consulter la communauté 
(talk-ca) ça peut être considéré du vandalisme.

Daniel

From: Alouette955 [mailto:alouette...@gmail.com]
Sent: June-20-16 11:45
To: talk-ca
Subject: [Talk-ca] Fusions ou remplacement de chemins et les attributs originaux

Bonjour,

Depuis plusieurs semaines je vois apparaitre des réseaux cyclables bizarres sur 
la vue cycliste de osm.org.

En examinant de plus près je constate que de nombreuses fusions de chemins 
occasionnent une duplication des tags ou relations cyclables à des portions qui 
n’en sont pas et en d’autres occasions il s’agit de chemins recréés pour 
lesquels on ne transporte pas tous les tags originaux.

J’en ai corrigé ou fait corriger des dizaines lorsque je les vois sur la carte 
cyclable. Par contre ceci peut toucher d’autres tags moins visibles (maxspeed, 
lane, oneway, etc ...).

Y a-t-il actuellement d’ambitieux projets de redéfinition des routes et, si 
oui, que peut-on faire pour sensibiliser les auteurs à tenir compte des tags 
existants. Il est impossible de tous les détecter à l’oeil.

Merci,

Claude

P.S. Malheureusement la vue cyclable met un long moment à se rafraichir et les 
aberrations y demeurent de longues semaines sinon des mois.


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

Re: [Talk-ca] Fort McMurray forest fires

[Begin Daniel]

I did not find any buildings (except those from Canvec and GeoBase) in the 
GCODP.
May Mojgan got it from somewhere else? …
Daniel

From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: May-05-16 14:04
To: Begin Daniel
Cc: James; Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Fort McMurray forest fires

Mojgan recently imported some Stat Can data through the Government of Canada 
Oren Data portal.
Cheerio John

On 5 May 2016 at 13:47, Begin Daniel 
<jfd...@hotmail.com<mailto:jfd...@hotmail.com>> wrote:
As far I can tell from the imagery available (Bing & Mapbox), the data from 
Geobase & Canvec are not up-to-date, neither for roads nor for buildings, and I 
do not see who in Ottawa could have them, StatCan?

Daniel

From: James [mailto:james2...@gmail.com<mailto:james2...@gmail.com>]
Sent: May-05-16 12:42
To: john whelan
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Fort McMurray forest fires

They may have a city GIS team, but is that data publically available? Nope. 
Heck their "server" might even be toast as most of the city is going up in 
flames. Better to have data available, then none at all.

On Thu, May 5, 2016 at 12:36 PM, john whelan 
<jwhelan0...@gmail.com<mailto:jwhelan0...@gmail.com>> wrote:
I'm not so sure of how much value this is.  HOT doesn't activate until it gets 
a request from the ground for that reason.  If it does then we get two tile 
systems over the same area.
Fort McMurray almost certainly has a City GIS system that has details of every 
building, Ottawa certainly does.  The roads and highways are also available in 
CANVEC for firefighters etc.
Cheerio John

On 5 May 2016 at 11:45, James <james2...@gmail.com<mailto:james2...@gmail.com>> 
wrote:
I've created a task on my tasking manager for buildings in Fort McMurray. 
Tracing buildings can help us flag buildings affected by the fire

http://tasks.osmcanada.ca/project/22

On Thu, May 5, 2016 at 11:43 AM, John Marshall 
<rps...@gmail.com<mailto:rps...@gmail.com>> wrote:

I will check with my contacts in my day job if they will release thier imagery.

I know DigitalGlobe are tasking thier satellites over Fort Mac.

John Marshall
On May 5, 2016 11:39, "James" <james2...@gmail.com<mailto:james2...@gmail.com>> 
wrote:
I think we'll have to wait until the fire is put out before we get satelite 
imagery.
What I can do is create a task on tasks.osmcanada.ca<http://tasks.osmcanada.ca> 
for Fort McMurray and we can trace buildings as they are not all there

On Thu, May 5, 2016 at 11:28 AM, Andrew MacKinnon 
<andrew...@gmail.com<mailto:andrew...@gmail.com>> wrote:
As you are probably aware by now, a large portion of Fort McMurray,
Alberta has been destroyed by forest fires.

Is any freely licensed aerial imagery of the affected area available
yet? Will the Humanitarian OpenStreetMap team be creating a project
for Fort McMurray?

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



--
外に遊びに行こう！

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


--
外に遊びに行こう！

___
Talk-ca mailing list
Talk-ca@openstreetmap.org<mailto: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 forest fires

[Begin Daniel]

As far I can tell from the imagery available (Bing & Mapbox), the data from 
Geobase & Canvec are not up-to-date, neither for roads nor for buildings, and I 
do not see who in Ottawa could have them, StatCan?

Daniel

From: James [mailto:james2...@gmail.com]
Sent: May-05-16 12:42
To: john whelan
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Fort McMurray forest fires

They may have a city GIS team, but is that data publically available? Nope. 
Heck their "server" might even be toast as most of the city is going up in 
flames. Better to have data available, then none at all.

On Thu, May 5, 2016 at 12:36 PM, john whelan 
> wrote:
I'm not so sure of how much value this is.  HOT doesn't activate until it gets 
a request from the ground for that reason.  If it does then we get two tile 
systems over the same area.
Fort McMurray almost certainly has a City GIS system that has details of every 
building, Ottawa certainly does.  The roads and highways are also available in 
CANVEC for firefighters etc.
Cheerio John

On 5 May 2016 at 11:45, James > 
wrote:
I've created a task on my tasking manager for buildings in Fort McMurray. 
Tracing buildings can help us flag buildings affected by the fire

http://tasks.osmcanada.ca/project/22

On Thu, May 5, 2016 at 11:43 AM, John Marshall 
> wrote:

I will check with my contacts in my day job if they will release thier imagery.

I know DigitalGlobe are tasking thier satellites over Fort Mac.

John Marshall
On May 5, 2016 11:39, "James" > 
wrote:
I think we'll have to wait until the fire is put out before we get satelite 
imagery.
What I can do is create a task on tasks.osmcanada.ca 
for Fort McMurray and we can trace buildings as they are not all there

On Thu, May 5, 2016 at 11:28 AM, Andrew MacKinnon 
> wrote:
As you are probably aware by now, a large portion of Fort McMurray,
Alberta has been destroyed by forest fires.

Is any freely licensed aerial imagery of the affected area available
yet? Will the Humanitarian OpenStreetMap team be creating a project
for Fort McMurray?

___
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] Attributs des sentiers de vélo de montagne

[Begin Daniel]

Comme pour toute la classification des routes/sentiers dans OSM, il y a une 
gradation (à l’exception de trunk!-)

… path-footway-track…

http://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrack

Il y a un réseau de sentier mtb à Sherbrooke ou les trois tags ci-dessus 
devraient être utilisés successivement sur un même tronçon. La description de 
l’infrastructure physique domine, par la suite on réfère à la fonction 
(footway/cycleway) ou via foot=*/ bicycle=*

Daniel


From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: April-20-16 21:22
To: Bruno Remy
Cc: talk-ca
Subject: Re: [Talk-ca] Attributs des sentiers de vélo de montagne

>petits chemins dans des parcs publics
In Ottawa these are very definitely paths not footways, cycling etc is 
permitted.
Cheerio John

2016-04-20 20:52 GMT-04:00 Bruno Remy 
>:
Bonjour,
Remarque très pertinente, Claude.
Cette recommandation mériterait d'être prise en compte, personnellement je 
l'approuve avec une réserve: il semble que l'attribut highway=path soit 
préférable à highway=track car la nuance entre les deux est dans la notion de 
carrossable/non carrossable:
Puisqu'on entend par carrossable la circulation en véhicule, le terme "track" 
s'applique plus aux chemins suffisament large pour un 4-roues, ceux qui donnent 
l'accès aux pourvoiries, cabanes à sucres,  et autres petits châlets, ou 
chemins agricoles pour la circulation des tracteurs et autres engins agricoles.
À l’inverse, "path" s'applique plus aux petits sentiers étroits pour la rando 
et/ou la circulation en vélo de montagne.
Autre remarque à ce sujet: bien souvent il est confondu les tags "highway=path" 
versus "highway=footway".
"Footway" semble plus adapté à des chemins piétons (plus ou moins courts) en 
zone urbaine (trottoirs, passages piétons, petits chemins dans des parcs 
publics) tandis que "path" désignerait plutôt des sentiers de 
petite/moyenne/longue randonnée en zone non-urbaine (une "trail" pour utiliser 
l'anglicisme canadien francophone).
Bruno




Le 20 avril 2016 à 15:21, Alouette955 
> a écrit :
Bonjour,

Au Québec plusieurs sentiers de vélos de montagnes ont  été créés avec les 
attributs de pistes cyclables:

   - highway=cycleway
   - surface=unpaved

Par exemple:

   http://www.openstreetmap.org/#map=15/45.4864/-74.0544=CN

Selon mes lectures, un sentier de vélo de montagne (MTB = MountainBiking) 
devrait se désigner par:

  - highway = track ou path
  - bicycle = yes ou designated
  - surface = ...

   (ces dernières valeurs plus foot=yes sont parfaitement valables pour une 
piste partagée entre vélo et piéton sans pour autant être un sentier de vélo de 
montagne)

et optionnellement

   - mtb:scale = ...
   - mtb:name = ...
   - mtb:description = ...
   - etc ...

ref.: http://wiki.openstreetmap.org/wiki/Mountain_biking

Outre ces dernières descriptions physiques il n’y a aucune façon des distinguer 
un sentier cyclable partagé par piéton et cyclistes d’une sentier de vélo de 
montagne puisqu’ils ont les mêmes attributs de base.

J’ai constaté qu’en Colombie-Britanique on a ajouté network=mtb 
(http://www.openstreetmap.org/#map=16/49.3545/-123.0513=CN).

route=mtb a, pour sa part, été utilisé sur 5965 chemins et 5486 relations.

mtb=yes a été utilisé 30154 fois sur des chemins mais qui n’est pas 
officiellement approuvé (ni même proposé selon mes lectures).

Je pense qu’il est utile de distinguer les segments de réseaux cyclables des 
segments de vélo de montagne puisque ces derniers ne sont pas destinés aux 
balades en familles du dimanche.

j’aimerais lancer un projet visant à corriger les attributs “vélo de montagne” 
mais auparavant je voudrais qu’on s’entende sur une façon de faire uniforme.

Utilise-t-on les attributs qui semblent se répandre comme network=mtb, 
route=mtb ou mtb=yes?

On peut aussi se forcer pour ajouter des mtb:scale ou mtb:name ou 
mtb:description alors qu’on en a souvent aucune idée des valeurs. Si j’étais 
adepte de vélo de montagne je pourrais probablement déterminer un mtb:scale 
mais ce n’est malheureusement pas le cas.

En terminant je ne veux pas uniquement tagguer pour un rendu, je veux une façon 
de clairement distinguer deux types d’objets.

Quelqu’un a une idée?

Merci

Claude



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



--
Bruno Remy

___
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

[Begin Daniel]

Seems absolutely adequate.

From: Mojgan Jadidi [mailto:mojgan.jad...@gmail.com]
Sent: February-19-16 11:57
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Bulk Import of Address Range in GTHA from Metrolinx

Dear All,

Based on the discussion in our previous emails:

https://lists.openstreetmap.org/pipermail/imports/2016-February/
https://www.mail-archive.com/talk-ca@openstreetmap.org/

We have revised our import process to accommodate the feedback we received. We 
have divided our dataset into 124 sub-regions, and intend to review and upload 
these over the next few weeks. These smaller sub-regions will be manually 
validated before uploading and will also give the community more time to review 
our data, and provide any additional feedback. By dividing our data into sub 
regions, we should avoid the issue where nodes were appearing without ways 
(which were handled in a different changeset by JOSM).

If the community is agreeable to our approach, we hope to begin this process 
sometime next week, but are happy to defer if anyone feels that there are still 
unanswered questions.

Keep in mind that, all regions are revisited and inspected for any issues such 
as duplication, new updates, appropriate geometry of ways along the road, etc.

Your feedback and support is appreciated.

Best regards,
Mojgan

Mojgan (Amaneh) Jadidi, Ph.D.
Intern, Applied Research & Corporate Monitoring
Planning & Policy | Metrolinx | 97 Front Street West, Toronto, ON, M5J 1E6 | T: 
416-202-5844

Postdoctoral Research Fellow
GeoICT Lab | York University | 4700 Keele St, Toronto, ON, M3J 1P3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Talk-ca: Bulk Import of Address Range in GTHA from Metrolinx, Second attemps

[Begin Daniel]

Cool!

-Original Message-
From: Stewart C. Russell [mailto:scr...@gmail.com] 
Sent: February-10-16 08:58
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Talk-ca: Bulk Import of Address Range in GTHA from 
Metrolinx, Second attemps

On 2016-02-09 09:24 AM, Begin Daniel wrote:
> 
> 1 - Stewart is right about questioning the StatsCan license...

Mojgan updated the import wiki page yesterday with a note and link to the 
open.canada.ca Road Network Files - 2015 
<http://open.canada.ca/data/en/dataset/8e089409-8b6e-40a9-a837-51fcb2736b2c>.
This is under the Open Government Licence - Canada terms, and not the StatsCan 
one.

So it looks like my licence concern has gone away.

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

Re: [Talk-ca] Bulk Import of Address Range in GTHA from Metrolinx, Second attemps

[Begin Daniel]

Mojgan wrote: “New detected address ranges are displayed onto 10 meter shifted 
line of OSM road segment.”

For what it's worth…
when implementing the Karlsruhe schema in Canvec data, the interpolation lines 
were located at 20 meters for tertiary and higher road classification, and 15 
meters for lower classification.

These values were requested by the community but for aesthetic purposes only.
Daniel

From: Mojgan Jadidi [mailto:mojgan.jad...@gmail.com]
Sent: February-10-16 09:25
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Bulk Import of Address Range in GTHA from Metrolinx, 
Second attemps

Hi all,
As you can find in our wikipage, we resolve the issue of licensing by using 
Open Government data portal which use Open Government License-Canada accepted 
by OSM. StatCan 2015 road network is part of this portal.

For accuracy and consistency issue, as I mentioned we validate our result with 
imagery data and geosbase road segment geometry following with an extensive 
visual inspection. Our visual inspection is on-going step and never stops!.

I would like to emphasize that we checked OSM address ranges against StatCan 
road segment by buffering left and right, if there is not enough address we 
extract from StatCan and complete OSM address ranges.

New detected address ranges are displayed onto 10 meter shifted line of OSM 
road segment.

We are going to check again for short address ranges and replace with node 
address!

Thanks for your support

Mojgan



Mojgan (Amaneh) Jadidi, Ph.D.
Intern, Applied Research & Corporate Monitoring
Planning & Policy | Metrolinx | 97 Front Street West, Toronto, ON, M5J 1E6 | T: 
416-202-5844

Postdoctoral Research Fellow
GeoICT Lab | York University | 4700 Keele St, Toronto, ON, M3J 1P3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Talk-ca: Bulk Import of Address Range in GTHA from Metrolinx, Second attemps

[Begin Daniel]

Hi Mojgan, 
Here are few comments/questions I wish to add to Stewart comments.

1 - Stewart is right about questioning the StatsCan license...
Why don’t you use GeoBase data instead? As far as I remember, their license is 
compatible with OSM and the Canvec road network (streets and address ranges) 
was generated directly from GeoBase data!

2 - Stewart is also right about government data accuracy.  You should never 
assume that their data (even from GeoBase) are better than OSM. However, I 
understand from previous emails that you are validating roads location by using 
Bing/other imagery, which is good! Just make sure imagery fits on available GPS 
tracks (especially if there are many of them).

3- Made properly, it will benefit to the community.

Best,
Daniel
 

-Original Message-
From: Stewart C. Russell [mailto:scr...@gmail.com] 
Sent: February-09-16 07:16
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Talk-ca: Bulk Import of Address Range in GTHA from 
Metrolinx, Second attemps

Hi Mojgan,

Thanks for sticking with us! And also for including the sample data as an 
attachment.

One observation: Statistics Canada does not use the Open Government Canada 
Licence (or even a derivation of it), but its own:
http://www.statcan.gc.ca/eng/reference/licence-eng

Although OSM has used previous road network information before, it appears (to 
me) that this StatsCan licence is different from the one reviewed for the 2009 
import. It has some prescriptive terms that may make its use incompatible with 
OSM. For instance:

[you shall] not merge or link the Information with any other
databases for the purpose of attempting to identify an
individual person, business or organization

I read this that you can't use StatsCan data as part of a larger geocoding 
database, which is one of OSM's uses.

I see that the Triplinx source has been added to the OSM Contributors page, too.

> At a high level, our process of identifying gaps in the address ranges 
> is summarized below:
> 
> · For each side of each StatCan road segment with a valid
> address range (start value and end value exist and are different):

Can you confirm, please: you're checking StatsCan address ranges against
**OSM** street segments? StatsCan (and any government data) cannot 
automatically be assumed to be more correct than OSM data, and we sometimes 
have to adjust imported data to match air photos or foot surveys.

For consistency, address range segments need to be parallel to OSM street 
segments.

In addition, please consider:

* not adding very short address ranges. There were a few in my neighbourhood 
that appeared to be only two houses long. Address points would be better for 
those.

* that every set of address range end nodes has an address range way associated 
with it. Again, there were several sets of range nodes with no range ways 
associated with them near me.

> *Benefit To The Community:*
> 
> … From our perspective, adding address data for areas/streets that 
> don’t have this data is a step in the right direction.

I'd absolutely agree, and apologize if I appeared to suggest otherwise.

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] Talk-ca Digest, Vol 96, Issue 1

[Begin Daniel]

Initial misunderstandings, emails round trips with the community… standard 
communication process!

I do not know how others a seeing it, but reading about the process you use, I 
do not see anything like a wild bulk import. At least, it is very similar to 
the process I used when importing Canvec datasets.

Daniel

From: Mojgan Jadidi [mailto:mojgan.jad...@gmail.com]
Sent: February-02-16 09:33
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Talk-ca Digest, Vol 96, Issue 1

Hi all,
Please accept my apology for this misunderstanding, I thought our presence for 
last OSM meeting and flowing emails in Talk-ca and with John were part of 
communication and discussion, we launched our wikipage two weeks ago, and we 
did not receive any feedback, so we thought to start import via JOSM.

as we expalined in our wikipage, we created the algorithm to detect the missing 
information, and then we check the quality of this information on JOSM on the 
top of OpenStreetMap, Bing Areal imagery, GeoBase Road network and some local 
municpal open data. the data is created initially through StatCan, however, we 
noticed the low quality of StatCan road segment geometry, so we deal with this 
issue by using complement dataset such as OpenStreetMap, Bing Areal imagery, 
GeoBase Road network and some local municpal open data. all created nodes and 
ways are carefully inspected visually using above dataset for more that 6 weeks.

Our final verification will be on the OSM server (on-line) to avoid or detect 
any issues. Our aim is having high quality address information in OSM for sake 
of community. we were very prudent from the first step to have a high quality 
source of information.

I hope that the community will accept our contribution and enjoy to use the 
data.

Best regards,

Mojgan


Mojgan (Amaneh) Jadidi, Ph.D.
Postdoctoral Research Fellow
GeoICT Lab
York University
Toronto

ca.linkedin.com/pub/mojgan-amaneh-jadidi/10/825/969/

On 2 February 2016 at 07:00, 
> 
wrote:
Send Talk-ca mailing list submissions to
talk-ca@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openstreetmap.org/listinfo/talk-ca
or, via email, send a message with subject or body 'help' to

talk-ca-requ...@openstreetmap.org

You can reach the person managing the list at
talk-ca-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Talk-ca digest..."


Today's Topics:

   1. Triplinx import (Stewart Russell)
   2. Re: Triplinx import (john whelan)
   3. Re: Triplinx import (Stewart Russell)


--

Message: 1
Date: Mon, 1 Feb 2016 18:36:01 -0500
From: Stewart Russell >
To: talk-ca >
Subject: [Talk-ca] Triplinx import
Message-ID:

Re: [Talk-ca] Highway recoding

[Begin Daniel]

Bonjour Ken,
You wrote “this level of confusion just encourages me to stop contributing” …

First, do not stop to contribute! There is so much fun to map about everything 
in your neighbourhood, on thematic content (biking trails, national parks … and 
so on)!

Secondly, the annual report you cite could be used to define our road network 
with only a few road classes, since many people (including me) consider that 
OSM road classification sometime overkill (while there are little options to 
map some other topics!-)  …

The “problem” - which is actually the solution - is that people from around the 
world have decided to use OSM and mapped the world using another road 
classification schema for more than a decade. Furthermore, if OSM users start 
referring to their own national agencies to define the OSM content, it is just 
going to be worst!

The Canada:British Columbia guidelines page is very close to the classification 
that was discussed and agreed with the community 7-8 years ago when we were 
working on NRN schema to translate it into OSM definitions (not the contrary). 
It is just recently that some users started to retag the whole Canadian network 
according to their view, without consulting first the community (contrarily to 
what you did).

This tread is about clarifying the definitions and make them clear in the wiki, 
everywhere it may concern the Canada. So, I am getting back with the above 
definitions that are using both wiki’s definitions and current thread 
discussions:

Tag: highway=motorway to identify the highest-performance roads within a 
territory. Typically, these controlled-access highways have a minimum of two 
lanes in each direction that are separated by a barrier…

Tag: highway=trunk for high performance roads that don't meet the requirement 
for motorway. In Canada, these roads must have some of the controlled-access 
features found on a motorway.

Tag: highway=primary for major highway linking large towns … The traffic for 
both directions is usually not separated by a central barrier. In Canada, these 
roads usually have none of the controlled-access features found on trunk and 
motorway.

Again, hope it will help the discussion ☺
Daniel

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

Re: [Talk-ca] Unusual activity?

[Begin Daniel]

Thank Andrew,
I should have confused Carleton Place with another area :-)
Daniel

From: Adam Martin [mailto:s.adam.mar...@gmail.com]
Sent: November-23-15 14:26
To: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Unusual activity?

Agreed Andrew. Drawing in the land use ourselves takes more time, but is far 
superior in terms of quality.

On Mon, Nov 23, 2015 at 3:51 PM, Andrew MacKinnon 
> wrote:
On Mon, Nov 23, 2015 at 1:58 PM, Adam Martin 
> wrote:
> There does appear to be a new gap in that area. Perhaps someone is working
> on it in JOSM and is going to be re-making the landuse polygons in the area.

The area around Carleton Place has looked like that for a long time.
Canvec landuse was never imported there. If someone wants to fix this
then go ahead but I consider repairing broken Canvec data to be a low
priority right now.

___
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] Unusual activity?

[Begin Daniel]

Hi all, I am a bit surprise when looking in this area...
https://www.openstreetmap.org/#map=11/45.1622/-76.2266

I am on the impression it used to look like the surrounding areas (Canvec 
imports and other stuffs). No suspicious activity around there like massive 
data deletion?

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

[Talk-ca] Copyright in data

[Begin Daniel]

Bonjour all,here is a link here that might be interesting for those of you that 
are interested in legal matter concerning 
datahttp://www.teresascassa.ca/index.php?option=com_k2view=itemid=124:federal-court-of-appeal-reminds-government-there-is-no-copyright-in-data
Daniel___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec 7 and lanes=-1 / surface=unpaved

[Begin Daniel]

Hi Richard
AFAIK the lane=* has never been used in Canvec. I know that the surface=unpaved 
has been used in the Canvec product as unknown value but only in Quebec. Never 
in other provinces.
Cheers
Daniel

 Date: Wed, 18 Jan 2012 16:50:37 -0500
 From: rich...@weait.com
 To: harald.kli...@mail.mcgill.ca
 CC: talk-ca@openstreetmap.org
 Subject: Re: [Talk-ca] Canvec 7 and lanes=-1 / surface=unpaved
 
 On Wed, Jan 18, 2012 at 4:16 PM, Harald Kliems
 harald.kli...@mail.mcgill.ca wrote:
  Hi everyone,
 
  can someone please tell me what's up with the lanes=-1 and surface=unpaved 
  tags on most roads imported from Canvec 7? I didn't find any information on 
  the Canvec wiki page. Do those tags stand for number of lanes/surface 
  unknown? Wouldn't it then be better to remove them with a bot (at least 
  the lane tags; with the surface ones it'll be tricky to distinguish between 
  actually unpaved roads and import errors). Sorry if this is an old, already 
  resolved issue -- I just couldn't find any information about it and come 
  across it all the time.
 
 I think v8 is current and I haven't noticed that issue.
 
 ___
 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] ACQTECH vs. Valdate vs. OSM User imput for CanVec HD

[Begin Daniel]

Hi all!
 
What I've been told (safe source) about canvec/geobase data origine and 
accuracy...
 
About 5% of the available datasets (usually populated area) have been produced 
digitally and have an accuracy better then 25m. 
So, almost every thing you'll find in canvec have been scanned from 50K paper 
map.  The paper map where produced using 50K aerial photographies and their 
accuracies were between 25 and 100m (or worst in some case)! 
 
BUT, over the last years
 
- All the road network has been acquired using high accuracy GPS (90% better 
than 10m).
- Every datasets that had an accuracy worst than 30m have been geometricaly 
corrected.  
 
Then, the resulting canvec (Federal) datasets have an accurate road network, 
and the rest of the content should have an accuracy between 10 and 30m.
 
However, if you are standing on the bed of a stream/river with your GPS unit 
(and having a good satellite visibility), I would say you're probably more 
accurate that the available data!

 

Anyway, I would propose that everyone uploads their GPS traces even if some 
exists for the same way because it might helps to see what geometry is right.   
 
Daniel
 
 






Date: Thu, 12 Mar 2009 13:29:10 -0400
From: kevinfarru...@gmail.com
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] ACQTECH vs. Valdate vs. OSM User imput for CanVec HD




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