Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[Pierre Béland via Talk-ca]

Mon problème est dés le téléchargement. Cela m'indique que google ne peut 
effectuer l'analyse d'antivirus et m'offre de télécharger quand même. De là, 
message d'erreur.Voici le message avec Chrome
Ce site ne peut pas fournir de connexion sécurisée

doc-08-3g-docs.googleusercontent.com a envoyé une réponse incorrecte.
   
   - Essayez d'exécuter les diagnostics réseau de Windows.
ERR_SSL_PROTOCOL_ERROR
 
Pierre 
 

Le samedi 19 janvier 2019 23 h 10 min 04 s HNE, James  
a écrit :  
 
 tar.xz c'est un fichier compressé contenant un fichier geojson(il se ouvre 
bien avec 7zip sur windows, ou n'importe quel program d'archive sur mac ou 
Linux), qui est servie via la Task Manager. Ce n'est pas la version originale 
de Stats Can, tu as raison, c'sst la version minifié sans les extras tag de 
merde qui sont aucunement utile à OSM.
Je travaille sur les fichiers, car quelqu'un a dit les données était de la 
bouse de vache.
On Sat., Jan. 19, 2019, 11:02 p.m. Pierre Béland  a 
écrit : 

Is there no one that will analyse the data I've posted here? 
https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
 or are we just email thread warriors?


  ___
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

[James]

tar.xz c'est un fichier compressé contenant un fichier geojson(il se ouvre
bien avec 7zip sur windows, ou n'importe quel program d'archive sur mac ou
Linux), qui est servie via la Task Manager. Ce n'est pas la version
originale de Stats Can, tu as raison, c'sst la version minifié sans les
extras tag de merde qui sont aucunement utile à OSM.

Je travaille sur les fichiers, car quelqu'un a dit les données était de la
bouse de vache.

On Sat., Jan. 19, 2019, 11:02 p.m. Pierre Béland  James,
>
> Je pense que nous travaillons sur deux aspects différents. Tu te concentre
> sur la production / correction des fichiers d'import.
>
> A ma connaissance, tu n'a pas décrit le contenu du fichier
> ontario-simplified.tar.xz.  Je suppose que ce sont les données d'import
> originales où tu apportes divers correctifs.
>
> De mon côté, je propose d'analyser le produit final dans la base OSM et
> mesurer pour les données déja téléchargées quelle proportion des bâtiments
> est avec angles droits (orthogonal), et les superspositions.  Cela
> permettrait simplement de comparer ces données avec ce que l'on retrouve
> ailleurs et rassurer sur la qualité globale de l'import par les différents
> contributeurs.
>
> Normalement, on ne devrait pas retrouver plus de 5% des bâtiments avec
> formes irrégulières,  sinon il faut regarder de plus près et expliquer
> pourquoi.  Mes analyses au cours des derniers 6 mois, incluant révision de
> Butembo en RDC montrent qu'avec une bonne révision on repère beaucoup de
> bâtiments qui ne correspondent pas à ce que l'on observe sur l'imagerie.
>
>
> Je n'ai pas réussi à télécharger le fichier  ontario-simplified.tar.xz à
> partir de Google drive,  ni avec Chrome, ni avec Firefox ni à l'aide d'un
> script wget. Je ne sais si windows 10 peut ajouter des restrictions que
> d'autres OS n'ont pas.
>
> Pierre
>
>
> Le samedi 19 janvier 2019 17 h 01 min 22 s HNE, James 
> a écrit :
>
> Is there no one that will analyse the data I've posted here? 
> https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
> or are we just email thread warriors?
>
>
___
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

[Pierre Béland via Talk-ca]

James,

Je pense que nous travaillons sur deux aspects différents. Tu te concentre sur 
la production / correction des fichiers d'import.
A ma connaissance, tu n'a pas décrit le contenu dufichier 
ontario-simplified.tar.xz.  Je suppose que ce sont les données d'import 
originales où tu apportes divers correctifs.
De mon côté, je propose d'analyser le produit final dans la base OSM et mesurer 
pour les données déja téléchargées quelle proportion des bâtiments est avec 
angles droits (orthogonal), et les superspositions.  Cela permettrait 
simplement de comparer ces données avec ce que l'on retrouve ailleurs et 
rassurer sur la qualité globale de l'import par les différents contributeurs. 

Normalement, on ne devrait pas retrouver plus de 5% des bâtiments avec formes 
irrégulières,  sinon il faut regarder de plus près et expliquer pourquoi.  Mes 
analyses au cours des derniers 6 mois, incluant révision de Butembo en RDC 
montrent qu'avec une bonne révision on repère beaucoup de bâtiments qui ne 
correspondent pas à ce que l'on observe sur l'imagerie.

Je n'ai pas réussi à télécharger le fichier  ontario-simplified.tar.xz à partir 
de Google drive,  ni avec Chrome, ni avec Firefox ni à l'aide d'un script wget. 
Je ne sais si windows 10 peut ajouter des restrictions que d'autres OS n'ont 
pas.

Pierre 


Le samedi 19 janvier 2019 17 h 01 min 22 s HNE, James  a 
écrit : 

Is there no one that will analyse the data I've posted here? 
https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
 or are we just email thread warriors?

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

Re: [Talk-ca] OpenStreetMap, education and the buildings

[Pierre Béland via Talk-ca]

Effectivement James,
Comme ailleurs en Europe, les communautés OSM sont beaucoup plus organisées.
La communauté OSM-France a mis en place des serveurs qui permettent l'accès à 
la carte OSM. On y retrouve aussi Osmose, uMap et l'hébergement du style 
humanitaire.  Au SOTM-Fr à chaque année,  quelque 100 personnes de tous 
horizons convergent pour y participer. Aussi, beaucoup de projets, notamment 
avec les organisations locales et autres. Et depuis longtemps, ils organisent 
localement des journées OSM avec écoles, municipalités et autres intervenants.

Ils ont donc la capacité de gérer de tels projets, de se coordonner avec les 
établissement scolaires. Ce sera intéressant de voir ce qui sera réalisé dans 
le monde scolaire.
 
Pierre 
 

Le samedi 19 janvier 2019 20 h 47 min 15 s HNE, James  
a écrit :  
 
 That's french: France. Not french: Québec
On Sat., Jan. 19, 2019, 8:44 p.m. John Whelan From weeklyosm:


Education
   
   - The new curriculum (pdf) for French high schools states that all students 
should be introduced to geospatial data usage. One of the expected abilities in 
that domain is the ability to “contribute to OpenStreetMap in a collaborative 
way”.
-- 

What it means is we can expect to see more interest from schools in Canada.  
Adding tags to buildings is fairly simple and less error prone than some 
activities. 

Using streetcomplete I think would work even without buildings.

Thoughts please.

Thanks John





Sent from Postbox___
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] OpenStreetMap, education and the buildings

[John Whelan]

Agreed but its part of a trend and perhaps needs a bit of planning.

Cheerio John

James wrote on 2019-01-19 8:46 PM:

That's french: France. Not french: Québec

On Sat., Jan. 19, 2019, 8:44 p.m. John Whelan  wrote:



From weeklyosm:


Education

  * The new curriculum


(pdf) for French high schools states that all students should
be introduced to geospatial data usage. One of the expected
abilities in that domain is the ability to “contribute to
OpenStreetMap in a collaborative way”.

-- 


What it means is we can expect to see more interest from schools
in Canada. Adding tags to buildings is fairly simple and less
error prone than some activities.

Using streetcomplete I think would work even without buildings.

Thoughts please.

Thanks John





Sent from Postbox


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


--
Sent from Postbox 

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

Re: [Talk-ca] OpenStreetMap, education and the buildings

[James]

That's french: France. Not french: Québec

On Sat., Jan. 19, 2019, 8:44 p.m. John Whelan  From weeklyosm:
> Education
>
>- The new curriculum
>
> 
>(pdf) for French high schools states that all students should be introduced
>to geospatial data usage. One of the expected abilities in that domain is
>the ability to “contribute to OpenStreetMap in a collaborative way”.
>
> --
>
> What it means is we can expect to see more interest from schools in
> Canada.  Adding tags to buildings is fairly simple and less error prone
> than some activities.
>
> Using streetcomplete I think would work even without buildings.
>
> Thoughts please.
>
> Thanks John
>
>
>
>
>
> Sent from Postbox
> 
> ___
> 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] OpenStreetMap, education and the buildings

[John Whelan]

From weeklyosm:


   Education

 * The new curriculum
   

   (pdf) for French high schools states that all students should be
   introduced to geospatial data usage. One of the expected abilities
   in that domain is the ability to “contribute to OpenStreetMap in a
   collaborative way”.

--

What it means is we can expect to see more interest from schools in 
Canada. Adding tags to buildings is fairly simple and less error prone 
than some activities.


Using streetcomplete I think would work even without buildings.

Thoughts please.

Thanks John





Sent from Postbox 

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

[Talk-ca] weeklyOSM #443 2019-01-08-2019-01-14

[weeklyteam]

The weekly round-up of OSM news, issue # 443,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11350/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canada building import - Simplification discussion

[James]

Original(1.4GB file size):
9.263 Average points per feature
Points:20346517
Features:2196329

Simplified (20cm) (1.2GB file size):
8.425 Average points per feature
Points:18504036
Features:2196329

Simplified (40cm) (1.1GB file size):
8.07
Points:17741477
Features:2196329

For better statistics on how it affects file size for ontario (which is the
biggest dataset by the way)
The previous link I provided was for the 20cm simplification, I can provide
a link to the 40cm simplification file if needed.
I don't think simplifying about 50cm would be safe/smart as that would be
getting into satellite imagery quality vs what the cities use (plane
overhead gathering high-res imagery)

On Sun, Jan 20, 2019 at 12:44 AM Nate Wessel  wrote:

> I'm changing the subject line to try and retain some clarity for the
> mailing list.
>
> James, thanks for the stats! I'm surprised this didn't remove more points.
>
> Steve, I mentioned earlier that 20cm is where I happened to draw the line
> for the data we imported in Hamilton County, Ohio and I'm not totally sure
> even that was ideal. A bit more than half of the buildings we've been
> importing there have one (damned) extra node which I've been trying to
> remove manually. I may have been a bit too conservative there, as I didn't
> want to lose any part of the geometry. Sometimes there are tiny bay windows
> and the like.
>
> I'm wondering if the scope of this data warrants some analysis of how
> simplification (and perhaps data quality generally) varies geographically.
> It seems quite likely that every municipality would have it's own quirks,
> and we might want to treat some places differently.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/19/19 7:24 PM, OSM Volunteer stevea wrote:
>
> On Jan 19, 2019, at 3:47 PM, James  
>  wrote:
> Resending because these emails are getting over 40KB in size and talk list is 
> spazzing out:
> Original:
> 9.263 Average points per feature
> Points:20346517
> Features:2196329
>
> Simplified (20cm): 8.425 Average points per feature
> Points:18504036
> Features:2196329
>
> Choosing 20cm or higher or lower is where the "improvement?" line gets drawn.
>
> In round numbers of nodes, call this a "10% reduction."  The question is, are 
> the results "improvement?"  If so, it seems worth doing.  (Only one person's 
> opinion, of course).
>
> Steve
>
> ___
> 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

[john whelan]

So my interpretation is we save about 9% by simplifying?

However does it mean we probably do need to verify the before and after
manually?

Would someone care to comment on if we would need to manually look at the
before and after and if 9% savings would be significant?

My personal feeling would be at 50% saving it would be well worthwhile but
at a lower figure I'm not sure where the cut off would be.

Thanks John

On Sat, Jan 19, 2019, 6:48 PM James  Resending because these emails are getting over 40KB in size and talk list
> is spazzing out:
> Original:
> 9.263 Average points per feature
> Points:20346517
> Features:2196329
>
> Simplified (20cm): 8.425 Average points per feature
> Points:18504036
> Features:2196329
> ___
> 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] Canada building import - Simplification discussion

[Nate Wessel]

I'm changing the subject line to try and retain some clarity for the 
mailing list.


James, thanks for the stats! I'm surprised this didn't remove more points.

Steve, I mentioned earlier that 20cm is where I happened to draw the 
line for the data we imported in Hamilton County, Ohio and I'm not 
totally sure even that was ideal. A bit more than half of the buildings 
we've been importing there have one (damned) extra node which I've been 
trying to remove manually. I may have been a bit too conservative there, 
as I didn't want to lose any part of the geometry. Sometimes there are 
tiny bay windows and the like.


I'm wondering if the scope of this data warrants some analysis of how 
simplification (and perhaps data quality generally) varies 
geographically. It seems quite likely that every municipality would have 
it's own quirks, and we might want to treat some places differently.


Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/19/19 7:24 PM, OSM Volunteer stevea wrote:

On Jan 19, 2019, at 3:47 PM, James  wrote:
Resending because these emails are getting over 40KB in size and talk list is 
spazzing out:
Original:
9.263 Average points per feature
Points:20346517
Features:2196329

Simplified (20cm): 8.425 Average points per feature
Points:18504036
Features:2196329

Choosing 20cm or higher or lower is where the "improvement?" line gets drawn.

In round numbers of nodes, call this a "10% reduction."  The question is, are the results 
"improvement?"  If so, it seems worth doing.  (Only one person's opinion, of course).

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

[James]

Resending because these emails are getting over 40KB in size and talk list
is spazzing out:
Original:
9.263 Average points per feature
Points:20346517
Features:2196329

Simplified (20cm): 8.425 Average points per feature
Points:18504036
Features:2196329
___
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

[john whelan]

It appears the original discussion on talk-ca was missed by many.

There appears to be an issue of local buy-in but I think for the moment we
should first concentrate on the problems we expect to see.

The building outlines we imported in Ottawa predated the Bing imagery I
suspect.

So first off what should be done with buildings in the import that are not
on ESRI or Bing?  Assuming they are being imported by an armchair mapper.

My suggestion is they be ignored.  Realistically we aren't going to capture
every building in Canada but it should give us a reasonable start.

For buildings that already exist I see two possibilities.  First is do not
import, the second import but copy over the history i.e. merge.

I have no strong feelings either way.

For buildings that are imported my suggestion is they should be tagged
building=yes unless there is local knowledge or mapilary or openstreetcam
imagery to support something different.

Should the import be preprocessed to square the buildings or remove small
blobs?

I hear two points of view, one says it should be the other says bring it in
as it is.

My personal gut feel is bring it in as is.  However I don't have strong
views on this.

I'm hearing the import plan should have more detailed instructions.  I
think some were placed on the task manager.

Have I missed anything?

Can we try for consensus or what I have listed?

I suggest we put aside what is local buy in and how we obtain it for the
moment.

Thanks John

On Sat, Jan 19, 2019, 5:31 PM 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
>
___
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] 2020 building import wiki comment by Nate Wessel

[OSM Volunteer stevea]

Yeah, even going to 8 GB (-Xmx8192m on my java launch command line) I hang 
about halfway through opening "Loading json file."  I'll try 16 GB (whew!) and 
QGIS next.

Steve

> On Jan 19, 2019, at 2:17 PM, James  wrote:
> 
> use qgis or launch josm with java in 64bit mode(d64) with memory options 
> (Xms, Xmx), or it will crap out at 3.5GB
> 
> On Sat., Jan. 19, 2019, 5:13 p.m. OSM Volunteer stevea 
>  On Jan 19, 2019, at 2:01 PM, James  wrote:
> > Is there no one that will analyse the data I've posted here? 
> > https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
> >  or are we just email thread warriors?
> 
> Well, slow down there, cowboy, it is gigabytes of data and I've been busy 
> replying to talk-ca, though my CPU is hot decompressing and opening your file 
> right now.  Though even with JOSM getting assigned multiple gigabytes of heap 
> space (and I've got plenty dozens of GB of RAM), I'm still getting 
> out-of-memory errors on trying to bite-and-chew this monster.
> 
> Maybe some of ARE email thread warriors, but I am not "just" an email thread 
> warrior.
> 
> SteveA
> California


___
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

[James]

use qgis or launch josm with java in 64bit mode(d64) with memory options
(Xms, Xmx), or it will crap out at 3.5GB

On Sat., Jan. 19, 2019, 5:13 p.m. OSM Volunteer stevea <
stevea...@softworkers.com wrote:

> On Jan 19, 2019, at 2:01 PM, James  wrote:
> > Is there no one that will analyse the data I've posted here?
> https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
> or are we just email thread warriors?
>
> Well, slow down there, cowboy, it is gigabytes of data and I've been busy
> replying to talk-ca, though my CPU is hot decompressing and opening your
> file right now.  Though even with JOSM getting assigned multiple gigabytes
> of heap space (and I've got plenty dozens of GB of RAM), I'm still getting
> out-of-memory errors on trying to bite-and-chew this monster.
>
> Maybe some of ARE email thread warriors, but I am not "just" an email
> thread warrior.
>
> SteveA
> California
___
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

[Nate Wessel]

Hi James,

I for one will be happy to talk about the technical issues of 
simplification... though I think at the moment it seems to be taking a 
backseat here to bigger issues like building consensus around the 
validity of this import.


Since this is a more technical issue, can I suggest that you share your 
data (original and simplified) along with a description of the 
methodology you used and any relevant stats on the wiki page? I'll be 
curious to see how much shapes have changed vs. how many points were 
removed. Perhaps Some measure of self-intersection between the 
simplified and unsimplified shapes, compared with reductions in the 
average number of nodes per shape? That's just the first thing that 
comes to mind - there may be better ways to assess the quality, 
especially as it varies between municipalities.


Someone also raised a concern about orthogonality (is that a word?) 
which will need to be measured in this context somehow as well.


Thanks,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/19/19 5:01 PM, James wrote:
Is there no one that will analyse the data I've posted here? 
https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing 
or are we just email thread warriors?


On Sat., Jan. 19, 2019, 4:29 p.m. Pierre Béland via Talk-ca 
mailto:talk-ca@openstreetmap.org> wrote:


Voici une compilation statistique à partir des changesets de OSM
pour la grande région de Toronto
(bbox=-80.8951,42.9142,-78.1046,44.3297). Depuis

Pour respecter la politique de confidentialité de OSM, les
contributeurs ne sont identifiés que selon leur uid.

Depuis décembre, on compte 6 contributeurs, 889 changesets et
6,621,124 objets édités (noeuds, chemins ou relations)

1 immeuble = 5 objets minimum
Le fichier de changeset ne fournit que le nombre d'objets édités
(var num_changes). On ne peut donc à cette étape-ci que
grossièrement estimer le nombre d'immeubles, sans doute plus de 1
million déjà. A partir de Overpass, on ne peut facilement extraire
les données. Je vais télécharger dans PostGIS un fichier récent de
l'Ontario et sélectionner les données éditées depuis le 24
décembre (premier jour avec édition )  de ces 6 contributeurs. 
Mon script Qualité permettra également d'analyser la géométrie des
bâtiments.

lexique
changeset         nombre de changesets (sessions d'édition)
num_changes    nombre d'objets édités dans la session
avg_changes     moyenne, objets édités par changeset

Tableau 1 - Objets édités par contributeur avec moyenne par changeset

uid changesets  num_changes avg_changes % cum
9266764 457 3,439,242   7,526   52.7%
215433  197 1,619,540   8,221   77.6%
5214232 151 815,541 5,401   90.1%
9343732 78  628,032 8,052   99.7%
3016192 3   17,710  5,903   100.0%
1919010 3   1,059   353 100.0%

889 6,521,124   7,335   



Tableau 2 - Objets édités par contributeur - jour avec moyenne par
changeset
uid jourchangesets  num_changes avg_changes
5214232 2018-12-28  3   10,324  3,441
5214232 2019-01-14  11  58,402  5,309
5214232 2019-01-17  9   57,738  6,415
9343732 2019-01-16  7   63,490  9,070
215433  2018-12-29  8   70,562  8,820
5214232 2019-01-16  25  176,942 7,078
5214232 2018-12-23  5   29,279  5,856
9343732 2019-01-14  5   39,000  7,800
5214232 2019-01-12  10  48,329  4,833
5214232 2018-12-24  9   54,888  6,099
215433  2019-01-08  13  77,332  5,949
9266764 2019-01-08  20  156,232 7,812
9266764 2019-01-01  9   67,167  7,463
9266764 2019-01-07  19  154,837 8,149
215433  2019-01-02  30  280,756 9,359
9266764 2018-12-24  11  66,162  6,015
5214232 2019-01-11  2   6,219   3,110
9343732 2019-01-15  10  75,020  7,502
9343732 2019-01-11  11  82,844  7,531
215433  2018-12-30  20  177,602 8,880
9266764 2018-12-31  30  195,300 6,510
9343732 2019-01-12  14  111,821 7,987
215433  2019-01-03  25  200,002 8,000
9266764 2019-01-10  33  260,886 7,906
215433  2019-01-09  17  138,489 8,146
215433  2018-12-31  21  169,903 8,091
5214232 2019-01-09  9   41,664  4,629
9266764 2019-01-13  32  266,247 8,320
9266764 2018-12-29  36  274,357 7,621
9343732 2019-01-10  14  112,606 

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[OSM Volunteer stevea]

On Jan 19, 2019, at 2:01 PM, James  wrote:
> Is there no one that will analyse the data I've posted here? 
> https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
>  or are we just email thread warriors?

Well, slow down there, cowboy, it is gigabytes of data and I've been busy 
replying to talk-ca, though my CPU is hot decompressing and opening your file 
right now.  Though even with JOSM getting assigned multiple gigabytes of heap 
space (and I've got plenty dozens of GB of RAM), I'm still getting 
out-of-memory errors on trying to bite-and-chew this monster.

Maybe some of ARE email thread warriors, but I am not "just" an email thread 
warrior.

SteveA
California
___
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

[James]

Is there no one that will analyse the data I've posted here?
https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
or are we just email thread warriors?

On Sat., Jan. 19, 2019, 4:29 p.m. Pierre Béland via Talk-ca <
talk-ca@openstreetmap.org wrote:

> Voici une compilation statistique à partir des changesets de OSM pour la
> grande région de Toronto (bbox=-80.8951,42.9142,-78.1046,44.3297).
> Depuis
>
> Pour respecter la politique de confidentialité de OSM, les contributeurs
> ne sont identifiés que selon leur uid.
>
> Depuis décembre, on compte 6 contributeurs, 889 changesets et 6,621,124
> objets édités (noeuds, chemins ou relations)
>
> 1 immeuble = 5 objets minimum
> Le fichier de changeset ne fournit que le nombre d'objets édités (var
> num_changes). On ne peut donc à cette étape-ci que grossièrement estimer le
> nombre d'immeubles, sans doute plus de 1 million déjà. A partir de
> Overpass, on ne peut facilement extraire les données. Je vais télécharger
> dans PostGIS un fichier récent de l'Ontario et sélectionner les données
> éditées depuis le 24 décembre (premier jour avec édition )  de ces 6
> contributeurs.  Mon script Qualité permettra également d'analyser la
> géométrie des bâtiments.
>
> lexique
> changeset nombre de changesets (sessions d'édition)
> num_changesnombre d'objets édités dans la session
> avg_changes moyenne, objets édités par changeset
>
> Tableau 1 - Objets édités par contributeur avec moyenne par changeset
>
> uid changesets num_changes avg_changes % cum
> 9266764 457 3,439,242 7,526 52.7%
> 215433 197 1,619,540 8,221 77.6%
> 5214232 151 815,541 5,401 90.1%
> 9343732 78 628,032 8,052 99.7%
> 3016192 3 17,710 5,903 100.0%
> 1919010 3 1,059 353 100.0%
>
> 889 6,521,124 7,335
>
>
> Tableau 2 - Objets édités par contributeur - jour avec moyenne par
> changeset
> uid jour changesets num_changes avg_changes
> 5214232 2018-12-28 3 10,324 3,441
> 5214232 2019-01-14 11 58,402 5,309
> 5214232 2019-01-17 9 57,738 6,415
> 9343732 2019-01-16 7 63,490 9,070
> 215433 2018-12-29 8 70,562 8,820
> 5214232 2019-01-16 25 176,942 7,078
> 5214232 2018-12-23 5 29,279 5,856
> 9343732 2019-01-14 5 39,000 7,800
> 5214232 2019-01-12 10 48,329 4,833
> 5214232 2018-12-24 9 54,888 6,099
> 215433 2019-01-08 13 77,332 5,949
> 9266764 2019-01-08 20 156,232 7,812
> 9266764 2019-01-01 9 67,167 7,463
> 9266764 2019-01-07 19 154,837 8,149
> 215433 2019-01-02 30 280,756 9,359
> 9266764 2018-12-24 11 66,162 6,015
> 5214232 2019-01-11 2 6,219 3,110
> 9343732 2019-01-15 10 75,020 7,502
> 9343732 2019-01-11 11 82,844 7,531
> 215433 2018-12-30 20 177,602 8,880
> 9266764 2018-12-31 30 195,300 6,510
> 9343732 2019-01-12 14 111,821 7,987
> 215433 2019-01-03 25 200,002 8,000
> 9266764 2019-01-10 33 260,886 7,906
> 215433 2019-01-09 17 138,489 8,146
> 215433 2018-12-31 21 169,903 8,091
> 5214232 2019-01-09 9 41,664 4,629
> 9266764 2019-01-13 32 266,247 8,320
> 9266764 2018-12-29 36 274,357 7,621
> 9343732 2019-01-10 14 112,606 8,043
> 1919010 2019-01-17 2 973 487
> 9266764 2018-12-26 29 216,701 7,472
> 215433 2019-01-07 12 93,825 7,819
> 5214232 2019-01-10 2 718 359
> 9266764 2019-01-09 25 216,885 8,675
> 5214232 2019-01-08 27 119,761 4,436
> 5214232 2018-12-25 2 10,528 5,264
> 9266764 2019-01-06 18 142,007 7,889
> 215433 2019-01-01 6 58,083 9,681
> 9266764 2019-01-04 7 39,155 5,594
> 1919010 2019-01-16 1 86 86
> 9266764 2019-01-11 22 174,419 7,928
> 9266764 2018-12-25 29 188,931 6,515
> 9266764 2018-12-27 10 67,593 6,759
> 3016192 2018-12-20 3 17,710 5,903
> 215433 2019-01-04 15 128,047 8,536
> 9266764 2018-12-30 14 108,068 7,719
> 9266764 2019-01-15 21 150,419 7,163
> 5214232 2019-01-15 19 116,812 6,148
> 9266764 2019-01-14 17 135,021 7,942
> 9343732 2019-01-13 17 143,251 8,427
> 9266764 2019-01-12 16 120,488 7,531
> 215433 2019-01-06 13 103,233 7,941
> 5214232 2019-01-13 11 57,670 5,243
> 5214232 2019-01-07 4 7,256 1,814
> 215433 2019-01-05 13 99,108 7,624
> 9266764 2019-01-05 4 25,286 6,322
> 9266764 2019-01-16 24 204,397 8,517
> 215433 2019-01-17 2 18,589 9,295
> 215433 2018-12-27 2 4,009 2,005
> 9266764 2019-01-02 13 71,064 5,466
> 9266764 2019-01-03 18 137,620 7,646
> 5214232 2018-12-27 3 19,011 6,337
>
>
> 889 6,521,124 7,335
>
>
> 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] 2020 building import

[OSM Volunteer stevea]

On Jan 19, 2019, at 1:22 PM, john whelan  wrote:
> As a point of information the 2020 web page I think was started by Julia and 
> very heavily edited by Stevea.

Sure I did, because it seriously lacked in the technical direction anybody 
would need to "map going forward" in the project/initiative as described.  What 
tags, what tools, what's the finish line?  It was hugely vague, essentially not 
a wiki that "nuts and bolts" OSM editors who wanted to make real contributions 
would be able to refer to and get concrete answers to their "how do I DO this?" 
questions.  And that's what wikis normally do, not "catch imagination."

> I think we are now agreed that the 2020 project with its idea of mapping 
> buildings in iD is not optimal.

This distinction of "don't use iD, it sucks at allowing good building data to 
enter (except for tags, maybe)" is somewhat new to me.  I don't doubt it 
happened, but it almost seems a "red herring distinction" (distraction?) at 
this point in time.  And if "don't use a particular editor" is the bottom-line 
result from all the effort that came from writing that wiki, that's not a lot 
of bang for the buck.

> However Julia's style did make its mark with many students and educators and 
> caught their imagination.

Fine, glad to hear it.  However, please don't pretend that wiki is the document 
that "roll up our sleeves" volunteers go-to to discover "HOW?" as the be-all 
and end-all of answers to our questions (most quite specific and somewhat 
technical, though truth be told, not truly difficult, simply trying to draw a 
line from "can't do it" to "ah, now I see how").  OSM volunteers need guidance 
and answers to their questions, especially in huge, nationwide endeavors.  Plan!

Answering "how do I do this in OSM" questions is what wikis in OSM are pretty 
good at doing, usually.  While Julia's might have a style that appeals to 
students (and that's "not nothing") it was essentially "non wiki-like" in what 
wikis usually do.  The remedy?  Fix the existing wiki (that re-write, despite 
my best efforts, did not produce the desired results, or did so in odd and 
ineffective directions) OR write wholesale new wikis which DO get the job done. 
 Largely, the Import Plan (the "current wiki" of this project) still doesn't 
fully do that (and an Import Plan is not a WikiProject), but "necessary steps 
to get the job done" are at least "out there somewhere," and hopefully will get 
better.  (Look, Yaro "discovered" methods to move the ball forward, so it's 
possible).  Anybody up for writing a real WikiProject for this endeavor?  (Not 
me).  The project really would benefit by this (and provincial-level wikis, 
too, imo) as well.  We're in early days, let's see what unfolds.  "The snowball 
is rolling downhill" and it's hard to predict what surprises OSM will reveal as 
things pick up mass and speed.

> The import plan is not the 2020 web page, it is something different. The 2020 
> web page has a pointer to it and it is the import plan or the import we are 
> talking about here.

Starting with a fresh WikiProject (and even what it should be named are being 
thrown around, e.g. by Nate in the Talk tab) seems a fairly important direction 
to take.  I've done this with WikiProject United States Bicycle Route System 
(fairly successfully) and WikiProject United States railways.  The latter is a 
tough slog, starting from our 2007 TIGER data import of USA railways (many 
times more massive data than Canada's building import), though since I started 
to talk about this on talk-us in 2013-4, spoke about it at SOTM-US in Seattle 
in 2016 and at end of 2018, we now have almost half the US states (all Western 
states, some Eastern) with a wiki describing the state of their rail (both 
freight and passenger) and color-coded tables which describe how far along we 
are with TIGER Review.  Replicate that, Canada, please, in your own way, at 
your own pace.  Such massive, nationwide projects CAN be done, and while I'm 
not saying I did this single-handedly, I'm living proof that a dedicated leader 
can take it far, far forward.   So, GO!  You, I, many can bang out a decent 
(skeletal, at first, they always are) wiki in two hours to a weekend, so get 
busy.

> The decision was taken by the small group who are putting this lot together, 
> to keep the 2020 as part of the name in order to link the two together.  A 
> large part of the 2020 project was enriching the building outline data and 
> that I think was and still is important.

Great.

> What would be interesting is to hear from Canadian mappers what their current 
> thoughts are.  The earlier talk-ca comments are still in talk-ca but remember 
> some time has passed since they were made.  Certainly Nate for one was not 
> around in talk-ca when the matter was discussed.

You asked for "Thoughts?" and you got mine.  Yes, let's hear from Canadians, 
please.

SteveA
California

P.S.  Merci à Pierre pour son récent post de Toronto stats

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[Pierre Béland via Talk-ca]

Voici une compilation statistique à partir des changesets de OSM pour la grande 
région de Toronto (bbox=-80.8951,42.9142,-78.1046,44.3297).  Depuis 
Pour respecter la politique de confidentialité de OSM, les contributeurs ne 
sont identifiés que selon leur uid.
Depuis décembre, on compte 6 contributeurs, 889 changesets et 6,621,124 objets 
édités (noeuds, chemins ou relations) 
1 immeuble = 5 objets minimumLe fichier de changeset ne fournit que le nombre 
d'objets édités (var num_changes). On ne peut donc à cette étape-ci que 
grossièrement estimer le nombre d'immeubles, sans doute plus de 1 million déjà. 
A partir de Overpass, on ne peut facilement extraire les données. Je vais 
télécharger dans PostGIS un fichier récent de l'Ontario et sélectionner les 
données éditées depuis le 24 décembre (premier jour avec édition )  de ces 6 
contributeurs.  Mon script Qualité permettra également d'analyser la géométrie 
des bâtiments.
lexique
changeset         nombre de changesets (sessions d'édition)num_changes    
nombre d'objets édités dans la sessionavg_changes     moyenne, objets édités 
par changeset
Tableau 1 - Objets édités par contributeur avec moyenne par changeset

| uid | changesets | num_changes | avg_changes | % cum |
| 9266764 | 457 | 3,439,242 | 7,526 | 52.7% |
| 215433 | 197 | 1,619,540 | 8,221 | 77.6% |
| 5214232 | 151 | 815,541 | 5,401 | 90.1% |
| 9343732 | 78 | 628,032 | 8,052 | 99.7% |
| 3016192 | 3 | 17,710 | 5,903 | 100.0% |
| 1919010 | 3 | 1,059 | 353 | 100.0% |
| 
 | 889 | 6,521,124 | 7,335 | 
 |



Tableau 2 - Objets édités par contributeur - jour avec moyenne par changeset

| uid | jour | changesets | num_changes | avg_changes |
| 5214232 | 2018-12-28 | 3 | 10,324 | 3,441 |
| 5214232 | 2019-01-14 | 11 | 58,402 | 5,309 |
| 5214232 | 2019-01-17 | 9 | 57,738 | 6,415 |
| 9343732 | 2019-01-16 | 7 | 63,490 | 9,070 |
| 215433 | 2018-12-29 | 8 | 70,562 | 8,820 |
| 5214232 | 2019-01-16 | 25 | 176,942 | 7,078 |
| 5214232 | 2018-12-23 | 5 | 29,279 | 5,856 |
| 9343732 | 2019-01-14 | 5 | 39,000 | 7,800 |
| 5214232 | 2019-01-12 | 10 | 48,329 | 4,833 |
| 5214232 | 2018-12-24 | 9 | 54,888 | 6,099 |
| 215433 | 2019-01-08 | 13 | 77,332 | 5,949 |
| 9266764 | 2019-01-08 | 20 | 156,232 | 7,812 |
| 9266764 | 2019-01-01 | 9 | 67,167 | 7,463 |
| 9266764 | 2019-01-07 | 19 | 154,837 | 8,149 |
| 215433 | 2019-01-02 | 30 | 280,756 | 9,359 |
| 9266764 | 2018-12-24 | 11 | 66,162 | 6,015 |
| 5214232 | 2019-01-11 | 2 | 6,219 | 3,110 |
| 9343732 | 2019-01-15 | 10 | 75,020 | 7,502 |
| 9343732 | 2019-01-11 | 11 | 82,844 | 7,531 |
| 215433 | 2018-12-30 | 20 | 177,602 | 8,880 |
| 9266764 | 2018-12-31 | 30 | 195,300 | 6,510 |
| 9343732 | 2019-01-12 | 14 | 111,821 | 7,987 |
| 215433 | 2019-01-03 | 25 | 200,002 | 8,000 |
| 9266764 | 2019-01-10 | 33 | 260,886 | 7,906 |
| 215433 | 2019-01-09 | 17 | 138,489 | 8,146 |
| 215433 | 2018-12-31 | 21 | 169,903 | 8,091 |
| 5214232 | 2019-01-09 | 9 | 41,664 | 4,629 |
| 9266764 | 2019-01-13 | 32 | 266,247 | 8,320 |
| 9266764 | 2018-12-29 | 36 | 274,357 | 7,621 |
| 9343732 | 2019-01-10 | 14 | 112,606 | 8,043 |
| 1919010 | 2019-01-17 | 2 | 973 | 487 |
| 9266764 | 2018-12-26 | 29 | 216,701 | 7,472 |
| 215433 | 2019-01-07 | 12 | 93,825 | 7,819 |
| 5214232 | 2019-01-10 | 2 | 718 | 359 |
| 9266764 | 2019-01-09 | 25 | 216,885 | 8,675 |
| 5214232 | 2019-01-08 | 27 | 119,761 | 4,436 |
| 5214232 | 2018-12-25 | 2 | 10,528 | 5,264 |
| 9266764 | 2019-01-06 | 18 | 142,007 | 7,889 |
| 215433 | 2019-01-01 | 6 | 58,083 | 9,681 |
| 9266764 | 2019-01-04 | 7 | 39,155 | 5,594 |
| 1919010 | 2019-01-16 | 1 | 86 | 86 |
| 9266764 | 2019-01-11 | 22 | 174,419 | 7,928 |
| 9266764 | 2018-12-25 | 29 | 188,931 | 6,515 |
| 9266764 | 2018-12-27 | 10 | 67,593 | 6,759 |
| 3016192 | 2018-12-20 | 3 | 17,710 | 5,903 |
| 215433 | 2019-01-04 | 15 | 128,047 | 8,536 |
| 9266764 | 2018-12-30 | 14 | 108,068 | 7,719 |
| 9266764 | 2019-01-15 | 21 | 150,419 | 7,163 |
| 5214232 | 2019-01-15 | 19 | 116,812 | 6,148 |
| 9266764 | 2019-01-14 | 17 | 135,021 | 7,942 |
| 9343732 | 2019-01-13 | 17 | 143,251 | 8,427 |
| 9266764 | 2019-01-12 | 16 | 120,488 | 7,531 |
| 215433 | 2019-01-06 | 13 | 103,233 | 7,941 |
| 5214232 | 2019-01-13 | 11 | 57,670 | 5,243 |
| 5214232 | 2019-01-07 | 4 | 7,256 | 1,814 |
| 215433 | 2019-01-05 | 13 | 99,108 | 7,624 |
| 9266764 | 2019-01-05 | 4 | 25,286 | 6,322 |
| 9266764 | 2019-01-16 | 24 | 204,397 | 8,517 |
| 215433 | 2019-01-17 | 2 | 18,589 | 9,295 |
| 215433 | 2018-12-27 | 2 | 4,009 | 2,005 |
| 9266764 | 2019-01-02 | 13 | 71,064 | 5,466 |
| 9266764 | 2019-01-03 | 18 | 137,620 | 7,646 |
| 5214232 | 2018-12-27 | 3 | 19,011 | 6,337 |
| 
 | 
 | 889 | 6,521,124 | 7,335 |



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

[Talk-ca] 2020 building import

[john whelan]

As a point of information the 2020 web page I think was started by Julia
and very heavily edited by Stevea.  I think we are now agreed that the 2020
project with its idea of mapping buildings in iD is not optimal.  However
Julia's style did make its mark with many students and educators and caught
their imagination.

The import plan is not the 2020 web page, it is something different. The
2020 web page has a pointer to it and it is the import plan or the import
we are talking about here.

The decision was taken by the small group who are putting this lot
together, to keep the 2020 as part of the name in order to link the two
together.  A large part of the 2020 project was enriching the building
outline data and that I think was and still is important.

What would be interesting is to hear from Canadian mappers what their
current thoughts are.  The earlier talk-ca comments are still in talk-ca
but remember some time has passed since they were made.  Certainly Nate for
one was not around in talk-ca when the matter was discussed.

Cheerio John

On Sat, 19 Jan 2019 at 15:40, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> On Jan 19, 2019, at 10:48 AM, john whelan  wrote:
> > There was an earlier discussion on talk-ca about how to handle this
> project.
>
> There were MANY.  Speaking for myself only, I urged a very cautious,
> go-slow approach, to edit the data into "improvement / harmony-with-OSM" as
> much as possible BEFORE they upload to be imported, (or document in the
> wiki HOW this was to happen), to use talk-ca, Tasking Manager and
> especially to develop and use a freshly-rewritten (and undergoing
> continuous improvement) wiki (this part was a/the major failing, imo) to
> communicate.  But that is looking in the rear-view mirror, and I don't like
> to hear "told you so," let alone say it.
>
> > It is similar to CANVEC in the original data sources are municipal data
> CANVEC uses a few other sources as well and it is released under exactly
> the same license but by a different federal government department.
>
> CANVEC data are roundly criticized.  And it doesn't matter where those
> data came from (CANVEC), nor where the present data come from (Stats
> Canada).  They are now "in the wild" and from an OSM perspective (what
> matters here and now), their source is essentially meaningless, except for
> historical context.
>
> > There are 3,700 municipalities in Canada. How do you deal with that?
>
> With good planning, using the tenets of OSM (e.g. the Import process,
> gaining consensus, good communication and appropriate tools like wiki,
> Tasking Manager and JOSM plug-ins where they make sense).  You DON'T try to
> short-circuit that by wholesale re-writing a re-write of the seed project
> wiki (now well-vetted, as if it were it were, and I tried, would have
> widely been seen as lacking), posting notice on talk-ca and waiting two
> weeks independent of their being very little feedback on so gigantic a
> process (a massive red flag).  In short, this was a huge "failure of
> consensus."  Look at the posts now which say "I woke up to a mess."  That
> simply shouldn't happen.
>
> > A suggestion was made on talk-ca we have one import plan that way it
> would at least be consistent and that's what we did.
>
> This import plan, coming from the BC2020 wiki, which as written by Julia
> left a LOT to be desired as to technical specifics. I characterized this as
> "cheerleading and buzzword-compliant," sorry Julia, but it was and hence
> was ineffective as a wiki for its intended purposes, which is to answer
> questions of those who need technical guidance in an endeavor to have their
> "how?" questions appropriately answered.  That's what wikis do, they are
> good at it, OSM expects this, so when a wiki fails to deliver, the project
> experiences failures.  That absolutely should not surprise.
>
> > Mentally I'd split the project into getting an import plan that met all
> the requirements and the actual importing.
>
> Um, yeah.
>
> > To me the importing would be done by local mappers or mappers with a
> local connection after a local discussion which is what happened in
> Kingston.  For locations that did not have such mappers then over time they
> could be tackled at a distance. One comment I recall was this was more of a
> marathon and to be honest we expected it to take place over a fair length
> of time.  A lot of buildings have gone in much faster than I expected.
>
> So, plan for that.  Manage that.  If it isn't happening, make it happen
> with outreach and OSM's usual tactics of "developing community."  OSM has
> been doing this for over 15 years (and gets better at it), but it isn't "a
> hope and a prayer," it is continual engagement, effort (technical and
> social) and mid-course correction when necessary, all while keeping a
> hawkish eye on the finish line.
>
> > For the pilot project with Ottawa the local Ottawa mappers were heavily
> involved.  We learnt a fair bit on the way and 

Re: [Talk-ca] (no subject)

[OSM Volunteer stevea]

On Jan 19, 2019, at 10:48 AM, john whelan  wrote:
> There was an earlier discussion on talk-ca about how to handle this project.

There were MANY.  Speaking for myself only, I urged a very cautious, go-slow 
approach, to edit the data into "improvement / harmony-with-OSM" as much as 
possible BEFORE they upload to be imported, (or document in the wiki HOW this 
was to happen), to use talk-ca, Tasking Manager and especially to develop and 
use a freshly-rewritten (and undergoing continuous improvement) wiki (this part 
was a/the major failing, imo) to communicate.  But that is looking in the 
rear-view mirror, and I don't like to hear "told you so," let alone say it.

> It is similar to CANVEC in the original data sources are municipal data 
> CANVEC uses a few other sources as well and it is released under exactly the 
> same license but by a different federal government department.

CANVEC data are roundly criticized.  And it doesn't matter where those data 
came from (CANVEC), nor where the present data come from (Stats Canada).  They 
are now "in the wild" and from an OSM perspective (what matters here and now), 
their source is essentially meaningless, except for historical context.

> There are 3,700 municipalities in Canada. How do you deal with that?

With good planning, using the tenets of OSM (e.g. the Import process, gaining 
consensus, good communication and appropriate tools like wiki, Tasking Manager 
and JOSM plug-ins where they make sense).  You DON'T try to short-circuit that 
by wholesale re-writing a re-write of the seed project wiki (now well-vetted, 
as if it were it were, and I tried, would have widely been seen as lacking), 
posting notice on talk-ca and waiting two weeks independent of their being very 
little feedback on so gigantic a process (a massive red flag).  In short, this 
was a huge "failure of consensus."  Look at the posts now which say "I woke up 
to a mess."  That simply shouldn't happen.

> A suggestion was made on talk-ca we have one import plan that way it would at 
> least be consistent and that's what we did.

This import plan, coming from the BC2020 wiki, which as written by Julia left a 
LOT to be desired as to technical specifics. I characterized this as 
"cheerleading and buzzword-compliant," sorry Julia, but it was and hence was 
ineffective as a wiki for its intended purposes, which is to answer questions 
of those who need technical guidance in an endeavor to have their "how?" 
questions appropriately answered.  That's what wikis do, they are good at it, 
OSM expects this, so when a wiki fails to deliver, the project experiences 
failures.  That absolutely should not surprise.

> Mentally I'd split the project into getting an import plan that met all the 
> requirements and the actual importing.

Um, yeah.

> To me the importing would be done by local mappers or mappers with a local 
> connection after a local discussion which is what happened in Kingston.  For 
> locations that did not have such mappers then over time they could be tackled 
> at a distance. One comment I recall was this was more of a marathon and to be 
> honest we expected it to take place over a fair length of time.  A lot of 
> buildings have gone in much faster than I expected.

So, plan for that.  Manage that.  If it isn't happening, make it happen with 
outreach and OSM's usual tactics of "developing community."  OSM has been doing 
this for over 15 years (and gets better at it), but it isn't "a hope and a 
prayer," it is continual engagement, effort (technical and social) and 
mid-course correction when necessary, all while keeping a hawkish eye on the 
finish line.

> For the pilot project with Ottawa the local Ottawa mappers were heavily 
> involved.  We learnt a fair bit on the way and that's why we basically cloned 
> the Ottawa import plan.  We noticed a lot of additional tags being added to 
> the building=yes and that to be was a good thing in that it drew more people 
> into OSM. I'm much more interested in those additional tags than anything 
> else.

Crowdsourced projects often yield unexpected positive results.  This is what 
our project means when we say our data get used "in creative, productive, or 
unexpected ways."  It happens (a lot), this is one of the best things about OSM.

> As far as I am aware there is no list of local OSM communities in Canada and 
> to be honest many mappers simply map and do not gather once a month at OSM 
> meetings.

So?  We don't need no stinkin' meetings, though all are welcome at meetings.

> I don't think we do an import plan every time we bring something across from 
> CANVEC.

Shame on whoever does this, it is wrong (from OSM's perspective, and this is 
OSM).

> Unfortunately there really is a demand for this sort of information.  The 
> initial 2020 meeting that took place at Stats Canada during the HOT summit in 
> Ottawa had many people from government departments who were very interested 
> in the data and especially what I call 

[Talk-ca] (no subject)

[john whelan]

 There was an earlier discussion on talk-ca about how to handle this
project.

It is similar to CANVEC in the original data sources are municipal data
CANVEC uses a few other sources as well and it is released under exactly
the same license but by a different federal government department.

There are 3,700 municipalities in Canada. How do you deal with that?  A
suggestion was made on talk-ca we have one import plan that way it would at
least be consistent and that's what we did.

Mentally I'd split the project into getting an import plan that met all the
requirements and the actual importing.  To me the importing would be done
by local mappers or mappers with a local connection after a local
discussion which is what happened in Kingston.  For locations that did not
have such mappers then over time they could be tackled at a distance. One
comment I recall was this was more of a marathon and to be honest we
expected it to take place over a fair length of time.  A lot of buildings
have gone in much faster than I expected.

For the pilot project with Ottawa the local Ottawa mappers were heavily
involved.  We learnt a fair bit on the way and that's why we basically
cloned the Ottawa import plan.  We noticed a lot of additional tags being
added to the building=yes and that to be was a good thing in that it drew
more people into OSM. I'm much more interested in those additional tags
than anything else.

As far as I am aware there is no list of local OSM communities in Canada
and to be honest many mappers simply map and do not gather once a month at
OSM meetings.

I don't think we do an import plan every time we bring something across
from CANVEC.

Unfortunately there really is a demand for this sort of information.  The
initial 2020 meeting that took place at Stats Canada during the HOT summit
in Ottawa had many people from government departments who were very
interested in the data and especially what I call enriched data, ie
buildings with addresses and other tags.  Smaller school boards have
expressed an interest in routing school buses using this sort of data.
There is an app for the blind that guides you to the building but the
building and address have to be on the map.

Should we care what end users are interested in?  I think that is a
separate discussion.

There always has been a range of views within OpenStreetMap.  I have
certainly been taken to task for changing a tag from traffic_lights to
traffic_signals.  "I mapped it and I tagged it traffic_lights and it should
remain that way."  Toronto was almost certainly going to be troublesome.  I
recall someone saying once if you gather five book classifiers together
they will find six ways to classify a book. The Ottawa community is
reasonably small and many meet up from time to time.  In a city such as
Toronto my expectation would be a much wider range of opinions. This makes
it very difficult to identify if something is approved or not. It also
means that my expectation that the importing mapper will use a bit of
common sense and we shouldn't need to spell out things like "replace
geometry tool" other mappers will have other expectations.

My understanding of importing or drawing a building outline from imagery is
it gets tagged building=yes and you can do no better from imagery.
Occasionally you might see a building in a residential area that has two
drives, I might just tag that semi.

Then we throw in the 2020 project. Stats initial idea was to simply have
every building mapped in Canada with iD and mapathons were a wonderful
idea.  Technically it is possible to accurately map a building from imagery
with iD I've seen it done.  You may wish to talk to Pierre about data
quality from those mapathons.

I had talked to Stats about getting the building outlines released under a
suitable license.  It only took a year to persuade the City of Ottawa to
change their Open Data license to one that worked with OpenStreetMap.

Stats came back some time later by releasing some building outline data
under the federal government Open Data license and that's where this bit
started.

The 2020 project has a lot of interest from GIS departments, High Schools
are thinking of how to get involved with their students.  Adding tags is a
lot safer and less error prone than drawing buildings in iD.  Education is
one area that Stats gets brownie points for so they like to promote it.

Microsoft has been running the same algorithms on Canada as it has in the
US.  We can expect their building outlines to be released shortly.

Data quality, by the time its been converted from one format to another and
comes form a variety of systems some municipal data will be better than
others. The data I've looked at looks reasonable however my expectations
and your expectations maybe different.

You might like to add a step or two into the wiki.

We could do a table in the wiki with a list of communities that feel
comfortable with the import. That might be troublesome, two high school
students 

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[Andrew Lester]

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

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

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

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

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

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

Andrew Lester 
Victoria, BC 


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

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

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

Cheerio John 

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




John, 


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


You're saying there was no wiki 

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

[Blake Girardot]

Hi,

Tangentially, I often remap areas with poor mapping and use the
replace geometry tool. I estimate it adds about 5% time to the over
all remapping effort, which is totally acceptable for the benefits of
careful redoing and saving of object history and I encourage folks to
use that way where there is good hand crafted existing data where an
import or improvement is going on.

Here is a tutorial video that shows how I work with it and if done
right, why remapping and replace geometry are only about 5% more
effort than deleting and re mapping from scratch. It also directly
applies to the import conflation process and I use it anytime I am
involved in that type of workflow.

https://youtu.be/Kv5AOmX8M9g

Respectfully,
Blake

On Fri, Jan 18, 2019 at 11:14 PM Nate Wessel  wrote:
>
> Hi Yaro,
>
> Thanks for marking this as on-hold in the tasking manager. I know I came in 
> like a wrecking ball and I really appreciate y'all holding things up while we 
> discuss.
>
> I'd be happy to validate data and help import the rest of central Toronto 
> once we're up and running again! I use the data in this area a lot in my 
> work... so I have a vested interest in keeping it at it's best :-)
>
> As to the conflation issue, one of the things we're doing in the other import 
> I'm working on is that we've essentially split it into two parts. First we're 
> importing buildings that don't conflict with OSM at all - this is the easy 
> part - and only later will we go in a bit more surgically and try to add tags 
> to existing ways and replace geometries with better data. We haven't started 
> that part yet, though I imagine it will be a real slog. IMO, it seems like a 
> lot to ask that editors do both things at once as these are really very 
> different tasks, especially given the size of the tasks here.
>
> I wonder if you'd have any interest in a similar separation of tasks for this 
> import? I think one of the benefits is that less experienced mappers can get 
> their hands dirty on the easier new-data-import part, without having to be 
> expert on which geometry is better, how to preserve way histories and tags, 
> etc. Like I said, we haven't started this part yet in the other import, but 
> even I find the prospect a little daunting!
>
> Best,
>
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com
>
> On 1/18/19 2:15 PM, Yaro Shkvorets wrote:
>
> Nate,
> I'll change the project name to reflect that the import is on hold. As a 
> local mapper, if you want to take a lead on the Toronto import that'd be 
> great.
> I did review some of DannyMcD's edits last night 
> (Mississauga-Brampton-Vaughan) and to be honest was rather disappointed with 
> the quality. It appears Danny chose to import only new buildings (i.e. 
> residential homes mostly), leaving most of the existing hand-traced 
> non-residential building outlines in OSM untouched. That's unfortunate, the 
> dataset offers some really good data and leaving half of it behind makes it 
> more difficult to revisit in the future.
> In my edits (Markham-Scarborough-East York) I was aiming to replace as many 
> existing geometries with outlines from the import as possible. I think that's 
> what we should be trying to do going forward.
> Looking forward to your comments and discussion.
>
>
>
> On Fri, Jan 18, 2019 at 1:07 PM Nate Wessel  wrote:
>>
>> Hi all,
>>
>> I've just joined the talk-ca list, so please accept my apologies for not 
>> addressing this list earlier. I'm happy to take this thread off the imports 
>> list for now and onto talk-ca until things are ready to begin again. The 
>> next person to reply can please feel free to remove that email if they agree.
>>
>> I've just made a note on the draft import plan wiki page noting that the 
>> import has been stopped:
>>
>> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan
>>
>> I would really appreciate it if the person with admin access to the tasking 
>> manager projects could please take those offline for the moment, or perhaps 
>> place them in a validation-only mode if that's possible.
>>
>> Like I said in my last email, which perhaps didn't make it to the talk-ca 
>> list 
>> (https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html) 
>> I'm now proposing that we leave the data that has already been imported and 
>> enter a phase of thorough validation on that data.
>>
>> My plan, over the next several days, is to do a general survey of the 
>> quality of the data that has been imported so far and make a list of 
>> systematic issues I see that should be addressed before we can consider 
>> moving forward again. I'll add those comments to the conversation in talk-ca 
>> and on the wiki page (link above), as I feel is appropriate. As I said 
>> before, I'm of the mind that this import did not get adequate review or 
>> approval and did not follow all the import guidelines. I 

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[John Whelan]

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


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


Cheerio John

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


John,

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


You're saying there was no wiki describing the plan when this went to 
the imports mailing list - only a link to a similar plan with related 
data. You did not follow the import guidelines and you need to go back 
and read that page line by line and follow the procedures that we have 
in place.

https://wiki.openstreetmap.org/wiki/Import/Guidelines
I'll go ahead and add a mention of this plan to the imports catalogue 
to get us started. I'll also add some sections to the wiki and try to 
leave some indication of where things can be better documented.


You may think I'm quibbling over procedural details, but I think this 
process is really important. If we were talking about importing 
buildings in one neighborhood, I would look the other way, but this is 
all of Canada. This is a huge, huge import and we need to take the 
time to do things right, and especially to document the process so 
people can get involved that aren't already.


Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/18/19 3:48 PM, John Whelan wrote:
The import mailing list was pointed to the correct page of the wiki.  
The initial post was to say this is what we were thinking of and 
there was a comment saying we needed to change the comment line.


>There is no mention of this proposed import on the import catalogue


The import process was reviewed by the person who set up the Ottawa 
import did we miss that step on the Ottawa import as well?  Neither 
was it raised as a concern on the import mailing list. I think this 
is very minor and can be corrected.


We learnt a fair bit on the Ottawa import and my expectation is since 
we are using experienced mappers to do the import conflation would be 
either handled by them or the building not imported. We aren't using 
new mappers in a mapathon here and with experienced mappers then I 
think you have to trust them. The world isn't perfect. Think in terms 
of service level.


>There are 2X more nodes than needed to represent the building 
accurately.


The problem with correcting this is you are introducing 
approximations.  This will vary according to the source and this can 
be simplified or corrected once its in OSM. I think this is a 
different issue of a mechanical edit that needs to be considered 
separately.


If we are concerned with database size then I suggest we change the 
instructions to say put the source comment on the change set rather 
than on the building outline.


Cheerio John


Nate Wessel wrote on 2019-01-18 3:06 PM:


John,

You seem to be playing the long game with this data - it sounds like 
you've been working with this a lot longer than I have, and you've 
put in the time and effort to help make this 
actually-quite-incredible dataset available to us. I don't want to 
stop the import from happening - quite the opposite. I just want to 
make sure that the time is taken to do this right. OSM deserves 
that. Your (our) long awaited victory will be the sweeter for our 
patience now.


There are several specific issues I see where the I's are not 
crossed, nor the t's dotted. I've mentioned several already, so I'll 
try to be brief (I really need to get back to working on my 
dissertation).


1) There was extremely limited discussion on the imports mailing 
list. The initial email did not make clear the scope of the project. 
I read the email and did not think twice at it, thinking it was 
entirely about Ottawa. The link in that email was actually to the 
Ottawa import, and not this one, which seems to have been only in 
draft at the time. 
https://lists.openstreetmap.org/pipermail/imports/2018-November/005812.html
As such, this project has NOT been reviewed by the imports list, 
which is a requirement for proceeding with the import.


2) There is no mention of this proposed import on the import 
catalogue (https://wiki.openstreetmap.org/wiki/Import/Catalogue)
which is required in the imports guidelines. I suspect many other 
guidelines have not been followed.


3) The wiki page describing the import is not adequate to assess the 
quality of the data or of the proposed import. See for example: 
https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan#Risks